Почему большинство RAG‑систем не понимают сложные документы: они их разрушают

В последние годы многие организации развернули решения Retrieval‑Augmented Generation (RAG), обещающие мгновенно «демократизировать» корпоративные знания: прост...

📋 Обзор

В последние годы многие организации развернули решения Retrieval‑Augmented Generation (RAG), обещающие мгновенно «демократизировать» корпоративные знания: просто индексируются PDF‑файлы, подключается большой языковой модель, и бот начинает отвечать на вопросы сотрудников. На бумаге это выглядит привлекательно, но в реальных условиях, особенно там, где нужна точная обработка инженерной документации, результаты зачастую disappoint.

Раздел 1

Проблема в том, что большинство RAG‑систем применяют простые схемы разрезки текста на блоки длиной 512–1024 токена и стандартные эмбеддинговые модели, которые не способны уловить контекст увеличенной гранулярности. Когда инженер задаёт вопрос о конкретном участке трансформаторной станции, система приводит «галлюцинацию» – несвязный ответ, сформированный из разрозненных фрагментов, не относящихся к тому, чего действительно интересует пользователь. Эта «пылка» связана с тем, как RAG‑системы обрабатывают документы. Явные структурные метки – таблицы, схемы, диаграммы – часто игнорируются. Даже простые заголовки, такие как «Раздел 4.3.4: Система охлаждения» превращаются в лишний шум, а не в ключ к нужной информации. В результате бот воспринимает документ как набор «текстовых петель», разрезанных подряд, без узнавания взаимосвязей между разделами. На российском рынке ситуация аналогична. В Сбербанке и ЦБ РФ уже используют RAG‑решения для обработки нормативных документов, в частности, о кредитных операциях и изменениях в регуляции. Однако эксперты отмечают, что ответы часто «вырываются» из текста и не совпадают с реальными требованиями. У Газпромовых инженеров, разрабатывающих сетевые схемы, проблемы возникают почти в каждом случае: ответы «отдышивают» от реальных параметров оборудования и вызывают путаницу в проектной документации. Как решать проблему? 1. Улучшение предварительной обработки – выделение и хранение структурных метаданных (таблицы, схемы, графики) в отдельном индексе, чтобы LLM могла обращаться к ним явно. 2. Контекстноинтегрированные embeddings – обучение эмбеддингов под конкретные отрасли, где ключевые словоформы и профессиональная терминология сильно влияют на смысл. 3. Интерактивный диалог – возможность уточнения вопроса и самокоррекции ответа на лету, чтобы бот не «проскальзывал» в недопонимаемые области. 4. Проверка фактологической достоверности – внедрение вспомогательных модулей проверки, которые сопоставляют вывод модели с реально существующими параграфами и данными в документе. Начиная с 2024 года крупные компании уже внедряют более гибкие ядра RAG, в частности, подходы, основанные на Graph Neural Networks и retrieval‑augmented transformers, которые позволяют сохранять целостность документов и улучшать точность ответов. Гибкая архитектура также открывает путь к совместной работе с экспертными системами, где инженерные правила могут дополнить машинное понимание. В конечном итоге, чтобы RAG стал действительно полезным инструментом для технических отделов, нужно перестать рассматривать документы как «плоские» наборы слов, а заставить системы видеть их как живые, взаимосвязанные сущности. Иначе решение, которое обещает сократить время поиска знаний, парадоксально усложняет задачи инженеров – разрушающее их понимание, а не поддерживающее.