Три причины сбоев в производственных системах RAG: фрагментированный контекст, дрейф и неправильное использование.

Почему демо-версии RAG работают, а производственные системы — нет

Технология генерации с усилением на основе поиска стала стандартной архитектурой для корпоративного искусственного интеллекта. Вспомогательные ассистенты, внутренние инструменты для работы с знаниями, консультанты по соблюдению нормативов, а также продукты умного поиска в банковской, страховой, медицинской, телекоммуникационной, ритейл- и государственной сферах используют её для связи языковых моделей с собственными знаниями компании. Идея кажется простой: извлекать релевантные фрагменты из базы знаний и передавать их модели перед тем, как она ответит. Однако реализовать это в производственных условиях гораздо сложнее, чем может показаться на этапе демонстрации концепции.

Многие команды удаётся запустить прототип, но затем они сталкиваются с новыми проблемами при масштабировании. Ответы, которые получаются, бывают неполными. Качество поиска снижается по мере увеличения объёма данных. Упускается важный контекст, появляются галлюцинации, растёт задержка, и пользователи получают ответы, которые технически верны, но практически бесполезны. Иногда система поиска находит именно те документы, которые нужны, но модель всё равно даёт неверный ответ.

Корпоративные настройки усугубляют всю эту ситуацию, поскольку знания распределены среди тысяч документов, правил, процедур, руководств по эксплуатации и нормативных документов. Одно деловое решение может зависеть от деталей, разбросанных по нескольким разделам хранилища, что делает качество поиска столь же важным, как и способности модели.

Существует распространенное заблуждение, согласно которому лучший RAG означает в первую очередь лучший LLM. Выбор модели действительно важен, но многие проблемы в производственной среде возникают из-за других факторов: разбиение данных на чанки, архитектура поиска, управление контекстом, механизмы ранжирования и оценки. Хорошо спроектированная система поиска в сочетании с эффективной моделью часто превосходит несовершенную систему, использующую самую современную модель. В регулируемых сферах, таких как банковское дело, знание этих способов возникновения сбоев обычно ценнее, чем знание внутренних деталей последних моделей, поскольку успех в производственной среде редко зависит от обновления одной модели. Он определяется тем, насколько хорошо информация извлекается, ранжируется, структурируется и представляется.

Три сценария показывают, как могут возникнуть проблемы:

• Система находит релевантные материалы, но при этом упускает важные нюансы.
• Качество поиска снижается по мере увеличения базы знаний.

Модель отвечает неверно, несмотря на то, что были найдены правильные документы.

Основной урок, который можно извлечь из всех трех примеров, заключается в том, что качественный RAG обеспечивается не только лучшими моделями, но и более эффективным поиском информации, управлением контекстом, оценкой результатов и проектированием системы.

Сценарий первый: релевантный текст, но отсутствие сути

Одной из самых раздражающих ситуаций является когда механизм поиска находит релевантные фрагменты, но ответ остается поверхностным. Он может быть фактически верным, однако не содержать контекста, тонких деталей или бизнес-нюансов, которые человек-эксперт заметил бы сразу. Такая ситуация становится все более распространенной при работе с длинными документами, информация в которых распределена по нескольким разделам.

Представьте хранилище знаний банка, в котором хранятся правила привлечения клиентов. Основные требования расположены в одной главе, обработка исключений — в другой, а требования регуляторов — в отдельном разделе, находящемся в ведении отдела рисков. Клиент спрашивает, достаточно ли определенного документа для открытия счета. Система поиска возвращает соответствующие правила, но упускает регуляторные исключения, описанные в другом месте. Ответ модели верен с точки зрения имеющейся у нее информации, но все равно неполон с точки зрения бизнеса. Это пример системы, которая понимает лишь часть документа и упускает общую картину.

Инженеры часто сразу подозревают модель. Обычной причиной является архитектура поиска.

Фиксированные по размеру фрагменты мешают полному пониманию

Первым делом следует проверить процесс разбиения на чанки. Многие реализации используют чанки фиксированного размера, поскольку их легко создавать, и они хорошо себя проявляют в экспериментах: документы делятся на фрагменты каждые несколько сотен токенов, которые затем хранятся в векторной базе данных. Этот подход прост, но часто нарушает логические связи. Документы не состоят из блоков фиксированного размера — они структурированы вокруг идей, разделов, правил, процедур и бизнес-концепций. Когда граница разделения проходит через одну из этих структур, контекст разрывается. Определение правила может оказаться в одном чанке, а его исключение — в другом. Система поиска загружает определение, но так и не находит исключения, в результате чего модель делает выводы на основе неполных данных.

Способы устранения фрагментированного контекста

Семантическое разбиение на части — это стандартное решение. Вместо разделения по произвольному количеству токенов оно учитывает естественную структуру, такую как заголовки, разделы, абзацы и смену темы, что позволяет сохранить взаимосвязи и значительно улучшить поиск.

Даже в этом случае важная информация часто находится на границе между двумя частями. Если части полностью независимы, поиск может её пропустить. Здесь помогает перекрытие частей: когда соседние части делят некоторый контент, это обеспечивает преемственность между ними, поскольку то, что заканчивает одну часть, одновременно начинает следующую, что снижает вероятность потери релевантного контекста.

По мере усложнения документов оказывается эффективной структура «родитель-дочерний элемент». Малые фрагменты встраиваются и поискивается, поскольку это обеспечивает более высокую точность. Как только находится соответствующий малый фрагмент, система загружает более крупный родительский раздел, в котором он находится, чтобы модель могла увидеть как совпадающую деталь, так и её окружение. Это похоже на поиск нужного абзаца, после чего читается весь раздел, а не лишь несколько отдельных предложений.

Системы производства также показывают, что лучший ответ редко находится в одном фрагменте. Вспомогательная информация часто располагается непосредственно перед или после наиболее подходящего результата, поэтому получение только фрагмента с наивысшим рейтингом может привести к неполному выводу. Расширение процесса поиска за счёт включения соседних фрагментов наряду с основным результатом сохраняет целостность и позволяет модели понять, как связаны отдельные элементы.

Расширение баз знаний повышает требования к качеству поиска. Векторный поиск отлично справляется с поиском семантически похожего контента, но может упускать точные термины, названия продуктов, идентификаторы политик, ссылки на нормативные акты и ключевые слова, специфичные для определенной области. В банковской сфере клиент может упомянуть конкретную нормативную требование, тип счета или категорию операции, для которых необходимо точное совпадение. Гибраидная стратегия, сочетающая семантический поиск с методами на основе ключевых слов, такими как BM25, покрывает оба аспекта: семантический поиск позволяет улавливать смысл, а поиск по ключевым словам — обеспечивает точность, и вместе они позволяют находить больше информации, чем любой из методов в отдельности.

В последнюю очередь происходит переупорядочивание и оптимизация контекста, прежде чем информация попадает в модель. Не каждый извлеченный отрывок заслуживает места в итоговом запросе. Механизмы переупорядочивания выдвигают на передний план наиболее релевантный материал, а оптимизация контекста устраняет избыточность, чтобы максимально эффективно использовать доступное пространство. Цель заключается не просто в извлечении релевантного текста, а в том, чтобы модель получила понимание, которое приобрел бы образованный человек после прочтения соответствующих разделов. Когда процесс извлечения сохраняет связи между концепциями, правилами, исключениями и доказательствами, качество ответов значительно улучшается, а тонкие нюансы, скрытые в длинных документах, больше не теряются.

Кратко

При такой проблеме обратите внимание на слой поиска, расположенный перед моделью. Пересмотрите стратегию разбиения на части, перейдите к семантическому разбиению с перекрытием, добавьте механизм поиска родительских и дочерних элементов, расширьте поиск на соседние части и объедините гибридный поиск с переранжированием. Эти изменения обычно предоставляют модели более богатый и хорошо связанный контекст, что как правило позволяет сохранить нюансы в длинных документах.

Второй сценарий: отлично работает во время разработки, плохо — в производстве

Часто встречается такая ситуация в компаниях: система RAG отлично работает на этапе разработки, но вскоре после запуска начинает возвращать нерелевантные или противоречивые результаты. Демонстрация прошла удачно, тестовые запросы давали точные ответы, процесс поиска казался надежным, и уверенность в его работе была высокой. Затем появляется реальный трафик: пользователи задают разные вопросы, в базу знаний постоянно попадают новые документы, меняются бизнес-процессы, а объем запросов растет. Ответы, которые раньше казались правильными, становятся противоречивыми, неполными или не относящимися к теме.

Изменились ли данные?

Первая проверка заключается в том, изменилась ли структура распределения данных. В средах разработки хранится небольшой, тщательно отобранный и упорядоченный набор данных. В производственной среде могут находиться тысячи или миллионы документов, созданных разными командами в разных форматах и соответствующих разным стандартам. Представьте банк, который начинает с небольшого набора правил по оформлению новых клиентов, а затем расширяет его, включая процедуры соблюдения нормативов, документы для аудита, руководства по борьбе с мошенничеством, руководства по продуктам, переписку с клиентами и уведомления регулирующих органов. Запрос, который раньше выбирал из десяти крайне релевантных документов, теперь должен конкурировать с тысячами частично связанных документов. Механизм поиска может всё ещё возвращать контент с похожим формулировкам, не выделяя самый полезный вариант, и это часто является первым признаком ухудшения качества поиска по мере роста базы знаний.

Оценивайте качество поиска отдельно

Далее оцените процесс извлечения информации отдельно от языковой модели. Распространенной ошибкой является возложение ответственности за плохие результаты на большую языковую модель, когда модуль извлечения информации вообще не предоставил правильный контекст. Показатели вроде Recall@K и Precision@K быстро проясняют ситуацию: если правильный документ отсутствует среди лучших результатов, у модели просто не было шансов. Часто требуется доработка самого процесса извлечения информации.

Одной из частых причин является смещение эмбеддингов. Модель эмбеддингов, которая хорошо справлялась с небольшим набором данных, может начать показывать плохие результаты по мере разнообразия документов, поскольку разные типы, стили написания и специфическая лексика конкретной области со временем снижают её эффективность. База знаний банка может содержать политики от команд по соблюдению норм, руководства от бизнес-команд и технические спецификации от инженеров. Всё это принадлежит одной организации, но язык сильно различается, и если эмбеддинги не учитывают эти различия, качество снижается.

Стратегии разбиения на части также могут устареть. Подход, который сработал для сотен документов, может потерпеть неудачу при обработке сотен тысяч документов, поскольку плохо сформированные части создают шум при поиске по сходству и затрудняют нахождение релевантной информации. Именно поэтому в производственных системах типа RAG необходима постоянная оценка, а не однократная настройка.

Реальные запросы отличаются от тестовых

Схемы запросов заслуживают внимания. Тесты в процессе разработки ориентированы на идеальные вопросы, поскольку инженеры уже знают данные. Реальные пользователи задают нечеткие или неполные вопросы и используют термины, отсутствующие в базе знаний. Сотрудник службы поддержки может искать «правила закрытия премиум-аккаунта», в то время как в официальных документах говорится «процедуры прекращения работы аккаунтов ценных клиентов». Люди сразу видят соответствующую ссылку, но система поиска может ее не обнаружить. Наблюдение за взаимодействием реальных пользователей обычно выявляет слабые места, которые тестирование никогда не покажет.

Посмотрите внутрь процесса обработки

Возможность отслеживания процесса поиска — ещё один ценный инструмент. Для каждого запроса в производственной среде необходимо иметь возможность видеть:

• какие документы были возвращены
• причины их выбора
• оценки сходства
• конечный контекст, отправленный в LLM
• сгенерированный ответ

Без этого отладка превращается в угадывание. С такой возможностью трейсы часто показывают, началась ли проблема с поиска, переупорядочивания результатов, формирования запроса или самой генерации ответа.

По мере роста объёма данных перед векторным поиском можно добавлять дополнительные слои, такие как гибридный поиск, фильтры метаданных, классификация документов, инструменты переупорядочивания или специализированные пайплайны для определённых областей. Например, при поиске информации о ипотеках в банковской сфере следует сначала искать материалы, связанные именно с ипотеками, а уже затем во всей корпоративной базе знаний. Сужение области поиска улучшает как точность, так и качество ответов.

Главный вывод заключается в том, что системы RAG для производственного использования являются динамичными системами, которые развиваются вместе со своими данными. Нельзя предполагать, что решение, которое хорошо работает с первого дня, будет работать так же эффективно через шесть месяцев, поэтому постоянный мониторинг, оценка и переобучение компонентов поиска критически важны для поддержания высокого качества на больших масштабах.

Кратко

Если система хорошо работает на этапе разработки, но плохо — в производственных условиях, сначала необходимо отделить проблемы поиска от проблем генерации контента. Анализируйте показатели поиска, проверяйте полученные документы, оценивайте качество вкладок, изучайте реальные шаблоны запросов и обеспечивайте возможность наблюдения за всем процессом. По мере увеличения объема данных рассмотрите возможность использования гибридного поиска, фильтрации метаданных, переранжирования результатов и поиска специфичного для конкретной области, чтобы результаты оставались релевантными и точными.

Сценарий третий: правильные документы, неверный ответ

Многие инженеры считают, что как только процесс поиска информации работает корректно, задача выполнена. Однако один из самых сложных сценариев в технологии RAG — это обратная ситуация: система находит правильные документы, но модель всё равно даёт неверный ответ. Это особенно раздражает, потому что обычные методы отладки направлены на процесс поиска, хотя сам механизм поиска может выполнять свою функцию идеально. Проблема заключается в том, как модель обрабатывает и анализирует предоставленный контекст.

Представьте ассистента по соблюдению банковских норм, отвечающего на вопросы, связанные с противодействием отмыванию денег. Пользователь спрашивает, может ли клиентский счёт оставаться активным во время ожидания проверки KYC. Механизм поиска возвращает соответствующие документы с правилами, и релевантное правило находится в контексте. Тем не менее ответ гласит, что счёт может оставаться активным бесконечно. Необходимая информация была доступна, но модель не смогла её правильно использовать.

Перегрузка контекстом и ситуация «потерянного посредника»

Одной из причин является перегрузка контекстом. Чем больше документов загружается, тем больше информации должен обработать модель, причем не вся она имеет одинаковую важность; поэтому критически важные детали могут оказаться затерянными среди обширного запроса. Эту проблему часто называют проблемой «потери информации посередине»: модели склонны обращать внимание на материал, расположенный в начале и конце контекста, игнорируя то, что находится посередине. Правильный ответ может буквально находиться в запросе, но всё равно оставаться без внимания.

Решение заключается в том, чтобы отдавать приоритет качеству контекста перед его количеством. Команды часто пытаются повысить точность, собирая больше информации, но больший объем контекста не гарантирует лучших ответов, и несколько высококачественных фрагментов часто превосходят кучу слабо связанных между собой фрагментов. Здесь полезна переориентация ранжирования, поскольку она позволяет вывести наиболее релевантные фрагменты вперед до того, как модель их увидит. Предоставление модели трех высокорелевантных документов с четкими подтверждающими доказательствами может дать лучшие результаты, чем десять умеренно релевантных документов.

Запросы, требующие обоснования

Дизайн запросов также имеет значение. Вместо того чтобы позволять модели отвечать свободно, необходимо указать ей строго опираться на полученный контекст и четко говорить, что информации недостаточно, когда доказательства не позволяют сформулировать ответ. Это значительно сокращает количество некорректных выводов без обоснования.

Генерация на основе цитат также помогает. Когда модели необходимо указать конкретные разделы или идентификаторы документов, гораздо проще проверить, основан ли ответ на полученных доказательствах, что имеет большое значение в регулируемых отраслях, таких как банковское дело, где требуются возможность аудита и объяснимость.

Противоречивые источники

Необходимо проверить, противоречат ли друг другу полученные документы. Крупные организации часто хранят несколько версий политик, процедур и руководств, и если при поиске возвращаются одновременно устаревшие и актуальные версии, модель может не знать, какая из них имеет приоритет. Фильтрация метаданных и версионирование документов становятся крайне важными.

Цель заключается не просто в получении информации. Необходимо обеспечить, чтобы модель могла выявлять, ставить в приоритет и анализировать наиболее релевантные доказательства, содержащиеся в ней. Система RAG работает эффективно только тогда, когда поиск и рассуждения действуют совместно.

Кратко

Когда нужные документы возвращаются, но ответ по-прежнему неверен, стоит проанализировать, как модель использует контекст: перегрузка, эффекты потери информации на промежуточных этапах, противоречивые источники и слабая основа для выводов. Среди решений, которые стоит попробовать, — переранжирование результатов, сокращение объема контекста, использование ответов с указанием источников, фильтры метаданных и запросы, заставляющие модель опираться исключительно на полученные доказательства. Часто проблема заключается не в самом поиске информации, а в том, как используется полученный контекст.

Что общего у этих трех случаев

Создание качественной системы RAG требует гораздо большего, чем простое подключение векторной базы данных к LLM. Прототипы, созданные в рамках демонстрации концепции, часто выглядят впечатляюще, но настоящие проблемы возникают тогда, когда системы вступают в эксплуатацию и должны надежно работать в масштабе. В этих трех ситуациях возникают фрагменты контекста в больших документах, качество поиска снижается по мере роста объемов хранилищ, и даже при наличии правильной информации модель может не суметь ею воспользоваться для логических выводов.

Основная идея заключается в том, что качество извлечения информации имеет столь же важное значение, как и возможности самой модели. Даже самая совершенная большая языковая модель не может компенсировать отсутствие контекста, плохо структурированные фрагменты, слабые стратегии извлечения или нерелевантный материал в запросе; улучшение архитектуры извлечения часто приносит больший эффект, чем замена модели. Для инженеров, архитекторов и технических руководителей различие между системами производственного уровня и эффектными демо-версиями заключается в тщательном проектировании: правильной структуризации данных, надежных процессах извлечения, учете контекста, переранжировании результатов и постоянной оценке. Корпоративный ИИ — это не просто генерация ответов; речь идет о генерации релевантных, обоснованных, объяснимых и постоянно надежных ответов.