RAG на ChromaDB: от прототипа до продакшена

Почему RAG-прототип не доходит до промышленной эксплуатации

RAG-прототип собирается на папке из десятка документов, и на ней поиск по документам выглядит убедительно: вопрос — ответ, рядом ссылка на источник. Демонстрация проходит, решение кажется готовым. Дальше начинается реальный корпус — тысячи страниц, сканы, вложенные таблицы и три версии одного регламента одновременно.

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

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

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

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

Что даёт управляемый RAG-конвейер в эксплуатации

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

Гибридный поиск вместо одного векторного

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

Что видно в эксплуатации

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

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

Режимы поиска: векторный, гибридный, с переранжированием

Режим поиска выбирают не по размеру базы, а по тому, как сформулированы вопросы и как устроены документы. Смысловые запросы — «как оформляется возврат», «что делать при сбое синхронизации» — уверенно закрывает векторный поиск по эмбеддингам. Как только в тексте появляются артикулы, номера пунктов и аббревиатуры, близость по смыслу промахивается: модель не различает «АБ-1200» и «АБ-2100».

На практике режимы не заменяют, а дополняют друг друга: гибрид поднимает несколько десятков кандидатов, переранжирование оставляет 3–5 действительно релевантных фрагментов, которые уходят в контекст модели. В RAG на ChromaDB это настраивается на уровне запроса, поэтому смена режима не требует пересборки индекса — меняется только слой выдачи, а не сами данные.

Как мы внедряем RAG: этапы инженерной работы

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

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

1. Инвентаризация источников. Отмечаем владельца, формат и частоту обновления каждого документа — от этого зависит расписание пересчёта индекса.
2. Схема конвейера. До кода рисуем путь данных: как документ попадает в индекс, как делится на фрагменты, как обновляется и как исчезает устаревший.
3. Настройка поиска. Подбираем модель эмбеддингов, размер фрагмента и гибридную выдачу — вектор вместе с поиском по ключевым словам. Нерелевантные фрагменты отсекаем, иначе модель отвечает по шуму.
4. Генерация и цитирование. Собираем контекст и вводим правило: ответ ссылается на исходный документ, а при низкой уверенности система честно говорит, что данных нет.
5. Проверка на контрольных вопросах. Считаем долю верных ответов и долю выдумок; разбивку на фрагменты и формулировки подсказок меняем, пока метрики не выйдут на цель.
6. Приёмка решения и передача в эксплуатацию. Фиксируем метрики, отдаём команде схему, настройки векторного хранилища на ChromaDB и регламент обновления. Дежурный умеет смотреть логи и качество выдачи.

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

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

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

Такой пакет снимает зависимость от подрядчика: систему можно развивать, проверять и передавать внутри команды, не восстанавливая логику по коду.

Кейс: поиск по базе знаний для службы поддержки

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

На первой линии это давало 4–6 минут на поиск ответа, около 40% ответов уходили без опоры на источник, а спорные случаи эскалировались на вторую линию — там скапливалась треть обращений.

Что сделали

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

Отдельно закрыли откат: версии индекса собираются как артефакты, переключение на предыдущую занимает минуты. Если качество выдачи просело после обновления корпуса — возвращаемся без полной переиндексации базы.

Что получилось

• Время поиска ответа: 4–6 минут → 25–40 секунд.
• Доля ответов с опорой на источник: 40% → 92%.
• Обращения на вторую линию: минус 35%.
• Вопросы, закрытые на первой линии без эскалации: 78%.

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

Чем отличается RAG от дообучения модели

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

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

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

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

Технические сомнения: качество, данные, доступ

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

Как обновляется база знаний?

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

Права доступа соблюдаются?

Фильтр прав применяется до ранжирования: поиск видит только доступные сотруднику фрагменты, поэтому закрытый раздел не может попасть в ответ. В журналах остаётся, какие фрагменты использованы.

Что если понадобится сменить хранилище?

Слой доступа отделён от хранилища: векторы и описания выгружаются, схема метаданных сохраняется. Переезд становится плановой операцией, а не новым проектом.

Можно ли откатить неудачное обновление?

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

Обсудим вашу задачу: с чего начнём работу

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

• Корпус документов в исходных форматах — выгрузка за характерный период, а не одна «показательная» папка: на пяти файлах нельзя проверить, как поиск ведёт себя на дублях и противоречиях между версиями регламента.
• Частота обновления и владелец данных — обновление раз в квартал вручную или постоянный поток из внутренней системы: от этого зависит, делаем мы разовую загрузку или регулярную переиндексацию с удалением устаревшего.
• Права доступа: кто какие разделы имеет право видеть и нужно ли фильтровать выдачу по подразделениям или ролям. Это влияет на схему хранения и на то, где именно применяется фильтр.
• 15–30 реальных вопросов пользователей с ожидаемыми ответами и указанием источника — на этой выборке мы фиксируем критерий приёмки и меряем качество, а не спорим о нём на демо.
• Точки встраивания и ограничения контура: куда поиск отдаёт ответ (чат, внутренний портал, рабочее место оператора), допустим ли выход данных во внешние сервисы или всё должно работать в закрытом контуре.
• Текущие трудности в цифрах: сколько времени уходит на поиск ответа сейчас, какая доля обращений остаётся без ответа, какие ошибки повторяются чаще всего.
• Критерий готовности: доля вопросов, на которые ответ найден и подтверждён ссылкой на документ, и допустимое время ответа.

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