Почему RAG-чатботы отлично работают на демо, но выдают бред в продакшене

RAG-чатбот по внутренней документации выглядит идеально на демо — отвечает на пять подобранных вопросов уверенно и точно. Но как только система попадает в продакшен и реальные сотрудники начинают задавать непредсказуемые вопросы, бот начинает выдавать уверенный бред. Вот история, которая повторяется в компаниях, инвестирующих в LLM: четыре месяца разработки, Pinecone, парсинг PDF, интеграция OpenAI, и в итоге система, которая кажется неработающей.

Демо против реальности

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

Где парсинг начинает ломаться Две недели ушло на парсинг PDF.

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

Проблема hallucination и неполного контекста

Даже если парсинг работает идеально, RAG-система может вывести документы из векторной базы неправильно. Модель видит релевантные куски текста, но контекста недостаточно для полного ответа, или куски противоречат друг другу. Тогда LLM по своей природе «заполняет пробелы» — галлюцинирует информацию, которой в документах нет. На демо вы тестируете на оптимальных случаях, где контекста достаточно. В продакшене пользователи спрашивают о деталях, рассыпанных по разным местам в документах или сформулированных совсем по-другому. Вектор-база не находит релевантные куски, или находит их не в полном объёме. В результате: Парсинг выходит из-под контроля при новых форматах документов Релевантность контекстов не гарантирует правильный ответ модели * Модель галлюцинирует информацию вместо честного «я не знаю»

• Разные фразировки в документах не находятся по одному запросу * Ранжирование релевантности часто не совпадает с нужным результатом ## Между демо и продакшеном На демо вы контролируете входные данные — выбираете вопросы, на которых система работает хорошо. В продакшене произойдёт ровно наоборот: сотрудники будут задавать именно те вопросы, на которые система ответить не может. Они спросят про исключения, про граничные случаи, про детали, которые технически есть в документе, но не в центре внимания парсера.

«На демо работает на 90 процентов.

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

Что это значит Это не значит, что RAG в энтерпрайзе невозможен.

Это значит, что RAG — это не один выходной в разработке и не одна архитектура, которую можно скопировать с GitHub. Это долгий процесс с обработкой исключений, fallback-стратегиями, feedback-петлями от пользователей и постоянным переучиванием на реальных вопросах. RAG работает не потому, что вы выбрали правильный вектор-сторе, а потому что вы согласились, что это длинная дорога.