RAG с локальными LLM: итоги четырёх пилотов за 2024 год

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

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

Четыре пилота вкратце

Все четыре - разные по типу базы знаний и сценарию использования, но схожи по инфраструктуре: GPU-сервер в контуре клиента, модели через llama.cpp или vLLM, векторная БД на выбор команды.

Пилот 1 - техническая документация производственного предприятия. Несколько тысяч PDF: регламенты, инструкции по эксплуатации оборудования, ГОСТы. Вопросы вида «какая периодичность ТО для компрессора X» или «какие допуски по давлению в линии Y».

Пилот 2 - внутренняя база знаний ИТ-службы. Confluence-экспорт: архитектурные решения, инструкции для helpdesk, описания сервисов. Сценарий - уменьшить нагрузку на старших инженеров по типовым вопросам.

Пилот 3 - юридические и нормативные документы. Внутренние политики, договоры, выгрузка актуальных редакций федеральных НПА. Целевые пользователи - юристы и комплаенс-офицеры, которым нужна ссылка на конкретный пункт, а не пересказ.

Пилот 4 - база клиентских обращений и решений. CRM-выгрузки, тикеты, ответы поддержки. Идея - ассистент для службы поддержки, который находит похожие решённые кейсы.

Базы знаний: что даёт хороший контекст

Самый ценный вывод за четыре пилота - качество RAG почти целиком определяется качеством исходных данных, а не моделью. Это банально звучит, но на практике постоянно недооценивается.

Структурированные документы с чёткими разделами работают хорошо. Регламенты с нумерацией пунктов, инструкции с заголовками - чанкинг по структуре (разбивка по заголовкам, а не по фиксированным 512 токенам) даёт заметно более релевантные результаты поиска. В пилоте 1 переход с flat-чанкинга на структурный поднял точность находимых фрагментов примерно на треть.

Живые вики и Confluence - ловушка. Пилот 2 столкнулся с классической проблемой: документация там есть, но она разной степени актуальности. RAG честно находит устаревшую статью трёхлетней давности и отдаёт её как ответ. Пришлось вводить метаданные с датой последнего обновления и фильтрацию при поиске - только документы обновлявшиеся за последние N месяцев попадают в контекст. Без этой фильтрации инструмент активно вредит.

Неструктурированные тикеты - самый тяжёлый случай. Пилот 4 разочаровал больше всего. CRM-записи короткие, неоднородные по стилю, часто без контекста («решили, как обычно» - и это весь ответ). Семантический поиск по ним работает плохо: вектора похожих по форме, но разных по сути обращений оказываются близко. Результат - шум вместо сигнала.

Embedding-модели на русском тексте

Это отдельная история. Большинство хорошо известных embedding-моделей обучены преимущественно на английском. Для технических документов на русском это заметно.

Тестировали несколько вариантов: multilingual-e5-large от Microsoft, e5-mistral-7b-instruct и несколько моделей от сообщества, заточенных под русский. Замеры делали на тестовых наборах вопросов с известными правильными фрагментами.

multilingual-e5-large - наш текущий выбор для смешанного контента. Работает на русском приемлемо, размер разумный (560M параметров), инференс не требует GPU для продакшн-нагрузок нашего масштаба. На чисто русском техническом тексте уступает специализированным моделям, но выигрывает по стабильности.

Специализированные русскоязычные модели дают лучший recall на чисто русском документе. Конкретно смотрели на deepvk/USER-bge-m3 и несколько вариантов на базе BGE - их качество на русском техническом тексте заметно выше. Минус - меньше документации, меньше комьюнити, иногда сюрпризы с поведением на краевых случаях.

Генеративные модели в роли эмбеддеров (e5-mistral-7b-instruct) - интересно, но дорого. Качество эмбеддингов хорошее, однако 7B на инференсе для векторизации - это GPU-ресурсы постоянно, а не только при ответе пользователю. Для пилота с небольшим корпусом (раз векторизовали - и всё) может оправдаться. Для сценария с непрерывным индексированием новых документов - дорого.

Генеративная часть: какие модели использовали

Для генерации ответов все четыре пилота использовали либо Mistral 7B / Mixtral 8x7B, либо Llama 3 (8B или 70B в зависимости от железа клиента). Специфика RAG тут такая: от LLM не требуется генерировать знания из головы - только сформулировать ответ на основе переданного контекста. Это несколько снижает требования к размеру модели.

Mistral 7B справляется с задачей «перескажи контекст и процитируй источник» вполне достойно. На пилоте 3 (юридические документы) перешли на 70B - там важна точность формулировок и модель должна правильно расставлять акценты при суммаризации длинных нормативных фрагментов.

Проблема с галлюцинациями в RAG-сценарии другая, чем в чистом чате: модель иногда додумывает детали, которых нет в переданных чанках, смешивая их с реальным контекстом. Это хуже, чем явная галлюцинация - выглядит правдоподобно. Частично лечится системным промптом («отвечай только на основе предоставленных фрагментов, если ответа нет - так и скажи»), но не полностью.

Что разочаровало

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

Второй момент - метрики качества. RAG сложно измерять автоматически. Можно считать MRR и recall@k на тестовой выборке, но конечный вопрос «пользователь получил правильный ответ» требует ручной оценки. Без этого непонятно, стало ли лучше после очередного изменения чанкинга или хуже.

Где сейчас

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

RAG с локальной LLM работает. Не магически, а как инструмент с известными ограничениями - и в этих ограничениях его нужно использовать.