Галлюцинации нейросетей: как мы доводим точность ответов RAG-систем до 99.9%

Пять ошибок, которые убивают RAG-проекты

Мы регулярно забираем проекты после неудачных попыток внутренней разработки. Картина повторяется с точностью до деталей:

1. Запуск на грязной базе знаний. Команда векторизует все подряд — включая устаревшие версии регламентов, черновики и личные заметки сотрудников. Модель честно отвечает по мусору. Лечится только Data Cleaning на старте, а не промптами.
2. Нарезка по токенам вместо смысла. Чанки по 500 символов режут таблицу тарифов посередине или отрывают условие от исключения. Retrieval вытаскивает половину правила, LLM додумывает вторую половину. Правильный чанкинг — по смысловым блокам: заголовкам, пунктам, таблицам целиком.
3. Отсутствие метрики качества. Проект считается запущенным, потому что «бот что-то отвечает». Никто не замерял процент корректных ответов на эталонном наборе из 200-300 реальных вопросов. Без тестового набора вы не отличите 85% от 99.9% — и не поймете, когда регрессия.
4. Экономия на верификации. Вторая модель-проверяющий удорожает каждый запрос, и ее часто выкидывают как «оптимизацию». В результате система отвечает мгновенно и уверенно — в том числе тогда, когда должна молчать. Для клиентского канала это прямой репутационный ущерб.
5. Заморозка базы знаний. Регламенты обновляются, а индекс перестраивается раз в квартал руками. Бот отвечает по правилам полугодовой давности. Индексация должна быть автоматической и привязанной к изменению исходных документов.

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

Чеклист готовности базы знаний к запуску RAG

Прежде чем строить графы и подключать слой верификации, проверьте исходный материал. Мы прогоняем этот чеклист на каждом enterprise-проекте, и в 90% случаев минимум четыре пункта оказываются проваленными:

• Актуальность. У каждого документа есть владелец и дата последней ревизии. Регламент двухлетней давности, противоречащий действующему процессу, — это фабрика галлюцинаций.
• Уникальность. Нет дублирующихся версий одного документа. Если в системе лежат три файла «Регламент возвратов v1/v2/final», retrieval будет вытаскивать случайный из них.
• Структура. Документы имеют заголовки, списки и логические блоки. Сплошной скан без текстового слоя режется на бессмысленные куски.
• Терминология. Есть глоссарий: что такое «заказ», «заявка», «лид» в вашей компании. LLM не должна угадывать внутренний жаргон.
• Полнота. База покрывает все сценарии, которые вы отдаете боту. Запускать ассистента на половине регламентов — гарантированные эскалации.
• Права доступа. Определено, какие документы может видеть какой сегмент пользователей. Финансовые данные не должны попадать в ответы клиентскому боту.

Vector Search против GraphRAG: где ломается классика

Чистый векторный поиск находит тексты, похожие на запрос, но не понимает отношений между фактами. Вопрос «можно ли вернуть товар, купленный по акции, если прошло 20 дней?» требует соединить три правила из разных разделов документа. Vector Search отдаст три фрагмента по отдельности, и LLM склеит их как попало — отсюда уверенные, но ложные ответы.

GraphRAG решает это структурно: условия, исключения и сроки связаны ребрами графа, поэтому система достает связный логический контекст целиком. Практическое следствие для CEO — разная экономика доверия. На векторном поиске автоматизация первой линии упирается в потолок 85-90% корректных ответов, дальше начинается ручной контроль. Гибридная архитектура с Knowledge Graph и слоем Self-Correction доводит точность до 99.9%, что позволяет отдать боту до 80% тикетов вообще без человека и окупить проект за ~2 месяца.

Вывод простой: если подрядчик предлагает вам «просто залить PDF в векторную базу» — он экономит на архитектуре за ваш счет.

Есть и третья причина, по которой мы не ограничиваемся векторами: обслуживаемость. В графе знаний видно, почему система дала конкретный ответ — какой узел и какое ребро сработали. Ошибка локализуется за минуты и правится точечно. В векторном пространстве ответ — результат математического сходства тысяч эмбеддингов, и разобраться, «почему бот так сказал», инженер не может в принципе. Для enterprise это разница между управляемой системой и черным ящиком, который нельзя сертифицировать и нельзя показать аудитору.

Сколько стоит внедрение RAG-системы с верификацией?

Стоимость определяется объемом базы знаний и числом интеграций (CRM, тикет-система, телефония), а не количеством пользователей. Проект с аудитом данных, построением графа и validation pipeline стартует от сотен тысяч рублей, при этом окупаемость на наших проектах составляет около 2 месяцев за счет снятия нагрузки с первой линии поддержки. Перед стартом мы считаем ROI на ваших исторических тикетах — цифра фиксируется в договоре до начала работ. Отдельная статья экономии: один агент заменяет отдел из 10 операторов первой линии, отвечая 24/7 без больничных и текучки.

Как быстро запускается MVP такой системы?

Рабочий прототип на ограниченном контуре — 4-6 недель: неделя на аудит и очистку данных, две недели на чанкинг, построение графа и промпты, остальное — на validation pipeline и нагрузочное тестирование на реальных вопросах. Дальше система расширяется итеративно: новые разделы базы знаний подключаются без пересборки ядра. Мы сознательно не предлагаем «запуск за неделю»: прототип без тестового набора и верификации — это демо, а не боевая система.

Что делать, если бот ошибся после запуска?

Каждый заблокированный или некорректный ответ попадает в лог с привязкой к извлеченным источникам — инженер видит, где именно сломалась цепочка: retrieval, генерация или верификация. Исправление занимает часы, а не недели: правится правило нарезки, добавляется документ в граф или ужесточается промпт верификатора. За первые месяцы эксплуатации доля эскалаций падает практически до нуля, потому что система обучается на реальных, а не синтетических запросах.