LLM + RAG для корпоративной wiki: переход от пилота к тиражированию

Год назад мы запустили первый пилот RAG-ассистента поверх корпоративной базы знаний. Хотели понять: реально ли это работает за пределами демо, или нас опять ждёт «впечатляет на презентации, умирает в проде». Сейчас у нас три завершённых пилота, один переведён в продуктивный контур, ещё два в процессе. Пишем, что поменялось в голове с прошлого года и на что реально уходит время.

Почему пилот - это не продукт

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

Первые две недели мы занимались не LLM, а Confluence: удаляли дубли, ставили даты на устаревшие статьи, дописывали контекст там, где его не было. Только после этого качество ответов стало приемлемым. Это скучно, это не продаётся в презентациях, но это единственный способ.

Выбор модели: GigaChat API против локального Llama 3.1

В пилотах мы использовали GigaChat API - по требованию клиентов про локализацию данных, не по нашей инициативе. Когда встал вопрос о продуктивном контуре, пришлось честно сравнить два варианта.

GigaChat API снимает инфраструктурную головную боль: не надо держать GPU, не надо следить за обновлениями модели, SLA на доступность берёт на себя Сбер. Для корпоративных клиентов, которым важно, что данные не покидают российский контур - это пока единственная облачная опция без самостоятельного хостинга. Минусы: зависимость от внешнего сервиса в продуктивном контуре и ценообразование, которое при больших объёмах начинает давить на бюджет.

Локальный Llama 3.1 - это другая история. Мы разворачивали 8B-вариант на клиентском железе с A100. Качество ответов на корпоративных текстах оказалось сопоставимым с GigaChat на хорошо задокументированных вопросах, но заметно хуже на «нечётких» - там, где нужно угадать намерение пользователя по криво сформулированному вопросу. Русский язык модель понимает, но местами делает это с акцентом. Зато полный контроль, предсказуемая латентность, никакой зависимости от внешнего API.

В итоге для первого продуктивного клиента оставили GigaChat API - там не было своего GPU-железа, и разворачивать инфраструктуру ради одного сервиса не было смысла. Для второго клиента, где инфраструктура есть и данные критичные, тестируем локальный вариант.

Chunk-стратегия: где мы ошибались

Первые пилоты делали самое очевидное: дели страницу на куски по N символов с перекрытием. Работает, но плохо. Проблема в том, что корпоративная wiki организована вокруг страниц, а страницы бывают очень разными: одна страница - три абзаца про один процесс, другая страница - большая таблица сравнения плюс пять вложенных разделов.

Фиксированный chunk срезает посередине смысловых блоков и теряет контекст. Мы перешли на иерархический подход:

• Первый уровень - страница целиком как метаданные: заголовок, теги, дата обновления, раздел wiki. Это идёт в метаданные каждого chunk-а, чтобы при поиске можно было фильтровать и ранжировать по источнику.
• Второй уровень - смысловые блоки: заголовок раздела плюс его содержимое. Если раздел большой - делим дополнительно, но по абзацам, не по символам.
• Третий уровень - таблицы и структурированные данные обрабатываем отдельно, конвертируем в плоский текст с явными метками строк.

Это увеличило объём работы по парсингу, но recall по точным вопросам вырос ощутимо - меньше случаев, когда ответ есть в базе, но RAG его не находит.

Как оцениваем качество

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

Мы выстроили трёхуровневую оценку:

Автоматическая - на каждом ответе считаем косинусное расстояние между вопросом и найденными chunk-ами, смотрим на топ-N retrieved документов. Если расстояние плохое или retrieved документы явно нерелевантны по метаданным - это сигнал для ревью. Дополнительно - периодически прогоняем тестовый набор вопросов с известными правильными ответами и смотрим на деградацию после каждого изменения базы знаний.

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

Ручное - раз в неделю кто-то из команды просматривает выборку из 20-30 диалогов. Это нельзя автоматизировать, и это самое ценное. Именно ручной просмотр находит системные паттерны ошибок, которые автоматика не ловит.

Что дальше

Первый клиент в продуктивном контуре - производственная компания, около 400 сотрудников, база знаний по процессам и регламентам. Ассистент отвечает на вопросы по внутренним процедурам и эскалирует на HR или IT, если не уверен. Работает уже полтора месяца. Обратная связь от пользователей - нейтральная до умеренно позитивной, что для корпоративного инструмента нормально: люди не в восторге, но пользуются.

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

Про LLM-агентов на IT-операциях мы писали в январе - там же история про хелпдеск, который начинался похожим образом.