Когда языковая модель не знает вашей документации — она не молчит, она придумывает. Именно это произошло с двумя нью-йоркскими адвокатами, которые попросили ChatGPT найти судебные прецеденты через обычный zero-shot-промпт. Модель сгенерировала логичные, детально описанные дела, которых никогда не существовало. Адвокаты не проверили источники и подали галлюцинацию в федеральный суд — итогом стали публичный скандал и штраф. Проблема не в промпте: модель просто не имела доступа к реальной правовой базе.
Чтобы решить эту задачу, не нужно переобучать модель на своих данных — это дорого, долго и в большинстве случаев избыточно. Вместо этого строят RAG-пайплайн (Retrieval-Augmented Generation): пользователь задаёт вопрос, система ищет релевантные фрагменты в базе документов, передаёт их в контекст модели, и та отвечает уже на основе найденного. Технически цепочка выглядит так: исходные документы (PDF, DOCX, страницы Confluence) парсятся и нарезаются на смысловые фрагменты — чанки. Каждый чанк превращается в числовой вектор — эмбеддинг — с помощью специальной модели и сохраняется в векторное хранилище: Qdrant, Weaviate, Milvus или pgvector в PostgreSQL. При запросе вопрос пользователя тоже преобразуется в вектор и ищет ближайшие по смыслу фрагменты. Найденное вместе с вопросом уходит в LLM — облачную или развёрнутую локально.
| Проблема | Причина | Решение |
|---|---|---|
| Ассистент ссылается на документ с другим содержанием | Чанкинг разрезал связный текст посередине параграфа | Нарезка по структуре: заголовкам, разделам, абзацам |
| Поиск не находит нужный документ по русскому запросу | Embedding-модель обучена преимущественно на английском | Использовать BGE-M3, Jina v5-text, Cohere embed-v4 из ruMTEB |
| В топ попадают формально похожие, но нерелевантные фрагменты | Векторный поиск оценивает поверхностное сходство | Добавить реранкинг: черновой поиск 30 кандидатов → отбор 5–10 |
| Неожиданно высокий счёт в продакшене | Стоимость не оценивалась на масштабе реальной базы | Планировать стоимость заранее, до первого счёта |
На демо всё работает идеально: чистая база, понятный вопрос, точный ответ. В продакшене картина другая. Первая типичная проблема — плохой чанкинг. Регламент — связный текст, где смысл абзаца зависит от соседних. Если система разрезала его автоматически посередине параграфа, модель получит обрывок и использует его для ответа. Для пользователя это выглядит как галлюцинация, хотя нужные данные в базе были. Вторая проблема — промахи поиска на русском. Если embedding-модель обучалась преимущественно на английском, запрос «оформить командировку» не найдёт документ «служебная поездка» — для системы это не близкие понятия. Третья — в топ попадают формально похожие, но не нужные документы, и модель добросовестно строит ответ по ним. Четвёртая — стоимость: пилот на 50 документах почти ничего не стоит, продакшен на 50 000 — совсем другая история.
Главные проблемы RAG на практике: неправильный чанкинг, промахи поиска по русскоязычным текстам и неожиданно высокие счета в продакшене.
Каждая из этих проблем решается конкретной инженерной работой. Чанкинг стоит делать по структуре документа — заголовкам, разделам, абзацам — а не просто каждые 500 токенов. Для этого подходят Unstructured, LangChain Document Loaders или Databricks Vector Search с поддержкой структурного и рекурсивного чанкинга. Для русскоязычных и многоязычных баз авторы рекомендуют embedding-модели из MTEB/ruMTEB-лидербордов: BGE-M3, Jina v5-text, Harrier-OSS, Cohere embed-v4, OpenAI text-3-large. Проверить качество поиска можно на выборке из 50–100 реальных запросов: если нужный документ не попадает в топ-5 или топ-10, настройки нужно менять.
Для расширения запросов используют query expansion — небольшая LLM-модель переписывает запрос несколькими способами, добавляя синонимы: «командировка» → «служебная поездка», «бизнес-трип», «перемещение между офисами». В продакшене часто комбинируют векторный поиск, BM25 и query expansion, чтобы покрывать и точные совпадения, и смысловую близость. Дополнительный этап — реранкинг: сначала черновой поиск отбирает 30 кандидатов, затем более точная модель выстраивает их по реальной смысловой близости, и в контекст LLM попадают только 5–10 лучших фрагментов.
Оценивать качество системы стоит не только по тому, нравится ли ответ модели, но и по живым сигналам: где пользователи чаще нажимают «ответ не помог», какие вопросы уходят к живому оператору, какие документы открывают вручную после неудачного ответа. Это прямые индикаторы того, что именно в retrieval что-то сломано — и отправная точка для следующей итерации.
