Представьте себе типичное совещание. Кто-то из руководства возвращается с конференции, садится напротив и говорит: «У них там бот по внутренней документации, надо себе такой же. До конца квартала».

Через четыре месяца у тебя есть Pinecone, OpenAI API, две недели работы над парсингом PDF и чат-бот, который на демо отвечает на пять подобранных вопросов идеально. А на шестой, который задаст любой нормальный сотрудник, отвечает уверенным бредом.

Дальше про то, что именно между этими двумя состояниями происходит. Но без «правильной архитектуры RAG», потому что такой не существует.

Демо работает по причинам, которые в проде не выполняются

Когда инженер собирает PoC, он подсознательно выбирает запросы, на которые знает ответ. И выбирает документы, в которых этот ответ есть в явном виде одним абзацем. Эмбеддинг такого запроса попадает близко к эмбеддингу этого абзаца, top-1 выдаёт нужный чанк, модель его пересказывает. Демо.

В проде у тебя:

• Запросы пользователей, которых ты не видел.

• Документы, в которых ответ размазан по трём разделам, противоречит документу из соседнего отдела и устарел на полтора года.

• Половина «документации» — это PDF со сканами, презентации со скриншотами таблиц и Confluence-страницы, последний редактор которых уже год как уволился.

Дальше идут косяки, которые появляются именно в этом переходе.

Чанкинг — выбор того, как именно ты сломаешься

Любой туториал по RAG начинается с RecursiveCharacterTextSplitter и фразы «возьмём чанки по 500 токенов с overlap 50». На реальных документах это разваливается так.

Политика отпусков, например, это длинная таблица, где строки: «по уходу за ребёнком», «учебный», «без сохранения», и в каждой строке три столбца условий. Splitter режет её посередине. Чанк 1 содержит первые пять строк без шапки. Чанк 2 — оставшиеся семь строк, тоже без шапки. На запрос «сколько дней учебного отпуска» эмбеддинг попадёт в чанк, где этой строки нет, потому что в нём есть слово «учебный» в другом контексте — например, в примечании.

Semantic chunking лучше, но непредсказуем. Один и тот же документ можно поделить так, что в чанке окажется «вопрос» из предыдущего раздела и «ответ» из следующего, и модель радостно соединит несвязанное.

На практике приходится писать кастомный чанкер под каждый тип документа: один для таблиц, другой для длинного нарратива, третий для FAQ. А это уже  инженерная работа на недели.

Эмбеддинги обучены на интернете, а не на ваших внутренних терминах (к сожалению)

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

Я видел кейс, где внутренний продукт назывался «Атлас», и в документации он встречался без поясняющего контекста, потому что «все же знают». Эмбеддинг запроса «как сбросить пароль в Атласе» уверенно тащил статьи про географические карты, потому что в обучающем корпусе модели «Атлас» — это атлас.

Файнтюнить эмбеддинг-модель на корпоративных данных можно, но это отдельный проект с разметкой, валидацией и поддержкой, на демо это никто не делает.

Top-k — это казино

Допустим, retrieval вернул вам пять чанков. Релевантные ли они? Cosine similarity показывает 0.78, 0.76, 0.75, 0.74, 0.73. Один из них реально нужный, остальные — плотный шум, который выглядит похоже.

Дальше модель получает все пять и пытается из этого собрать ответ. Если повезло, она вытащит правильный. Если не повезло, она усреднит, добавит уверенности и выдаст нечто, что звучит правдоподобно и неправда.

Reranker (cross-encoder типа bge-reranker или Cohere Rerank) немного помогает. Он улучшает порядок внутри уже найденного. Если правильного чанка в top-50 не было, то reranker его не вернёт.

И отдельная боль: что делать, когда два чанка противоречат друг другу. Документ от 2022 года и документ от 2026 года в выдаче с похожей релевантностью. Модель не знает, какой свежее. Если в чанке нет даты в явном виде (а её там обычно нет, дата в метаданных, которые ты, скорее всего, не пробросил) — то если повезет, угадает.

PDF — отдельная разновидность ада

В энтерпрайзе всё в PDF. Внутренние регламенты, инструкции, презентации, отчёты. Парсеры справляются с одноколоночным текстом, но:

• Таблицы. PyMuPDF извлекает таблицу как набор строк по координатам, без понимания структуры. Получаешь «графа1 значение1 графа2 значение2 графа3 значение3», и хорошо если в правильном порядке.

• Двухколоночные документы. Тексты из левой и правой колонок чередуются построчно. Читать это бесполезно, эмбеддить тем более.

• Сканы. Без OCR ты вообще ничего не получишь. С OCR ты получишь шум с ошибками распознавания. Tesseract на русском со старым шрифтом — отдельная история.

• Картинки и диаграммы. Архитектурная схема, в которой описан весь процесс, для RAG не существует. Хорошо, если кто-то расписал её текстом рядом, но обычно — нет.

Решение есть, оно стоит дорого: апишка какого-нибудь GPT для парсинга страниц PDF как изображений с описанием. Считайте бюджет: тысяча страниц документации — сотни долларов на парсинг, а это совсем не разовая операция, ведь документы обновляются.

Permissions — то, о чём никто не думает до прода

Условный сотрудник из отдела продаж пишет: «расскажи про планы по сокращению штата». RAG бодро ищет, находит документ из HR, который этому сотруднику видеть нельзя, и пересказывает.

Row-level security на векторной БД будет не из коробки. Pinecone научился в метадата-фильтры, Weaviate тоже, но логика «у пользователя X есть доступ к группам A, B, C, документ Y относится к группе D — отфильтровать» должна быть реализована на каждом запросе, да и к тому же корректно. Если вы не пробросили ACL в метаданные при индексировании — RAG просто игнорирует разрешения (и вы об этом узнаете в момент инцидента).

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

Multi-hop запросы простой RAG не вытягивает

Запрос: «Кто отвечает за систему биллинга и какой у него рабочий чат». Это два шага: сначала найти владельца биллинга, потом найти его контакты. Векторный поиск делает один шаг.

Запрос: «Сравни условия по овердрафту в тарифе Премиум и Премиум+». Чанк с одним тарифом и чанк с другим тарифом — это две разные точки в векторном пространстве. Один запрос их обоих не вытянет с одинаковым приоритетом.

Лечится агентами и query decomposition: модель разбивает запрос на подзапросы, делает несколько извлечений, потом собирает. Это работает медленнее (дороже, что немаловажно), и каждый из этих шагов может просто сломаться.  

Оценка — отдельная проблема, которую обычно игнорируют

Как понять, что RAG работает? Тестов мало, потому что нет ground truth. RAGAS даёт метрики (faithfulness, answer relevancy, context precision), но они считаются той же LLM, что и отвечает, то есть оценщик и подсудимый одно лицо.

LLM-as-a-judge систематически добра к ответам, которые выглядят уверенно. Если бот сказал «согласно политике компании, отпуск составляет 28 дней» — судья поставит высокую оценку. Тот факт, что в реальной политике 24 дня, судья не проверит.

Единственное, что работает — это реальные пользователи и обратная связь. Кнопки «полезно/нет», ручной разбор плохих ответов раз в неделю, и переиндексация по результатам.

То, что обычно срабатывает

Не серебряная пуля, но несколько вещей, которые в среднем спасают.

Сузить домен. Не делайте «бота по всей документации компании». Делайте бота по политикам HR. Или бота по API одного сервиса. Чем уже домен, тем выше вероятность, что извлечение вернёт правильное.

Гибрид BM25 и векторного поиска. Полнотекстовый поиск не умеет в синонимы, векторный — в точные термины и аббревиатуры. Их объединение через reciprocal rank fusion работает заметно лучше, чем любой по отдельности.

Структурированные данные — не в RAG. Если у вас есть таблица «сотрудник → отдел → телефон», не индексируйте её эмбеддингами. Сделайте text-to-SQL или просто фильтр. RAG нужен там, где данные действительно неструктурированные.

Заставить модель сказать «не знаю». В системном промпте — явная инструкция: если в контексте нет ответа, не придумывай. Это не работает в 100% случаев, но снижает галлюцинации хоть как-то.

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

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