Разработка RAG-систем

Что происходит между вопросом и ответом: фрагменты, поиск, уверенность

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

Нарезка на фрагменты и что ломается при плохой нарезке

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

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

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

Три способа отбора и переранжирование

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

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

Порог уверенности и три маршрута

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

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

Порог настраивают: где ошибка дорого стоит, его поднимают и система чаще переспрашивает; где ошибку правят дёшево — опускают. Порог пересматривают, когда меняется состав материалов.

Ссылка на источник

К ответу прикрепляется фрагмент, по которому он собран: документ, раздел, редакция. Ответ открывают и сверяют с оригиналом, общие сведения из интернета в него не попадают. Что видит спрашивающий, описано рядом: как это выглядит со стороны сотрудника компании.

Что попадает в индекс и что возвращается в ответ

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

Опыт с 1С у Dzeta AI подтверждён каталожным поиском у дистрибьютора. Остальные хранилища разбираем на аудите: на пилоте хватает выгрузок.

Живой индекс: обновление и снятие документа

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

На чём это собирается

Каркас конвейера — LangChain и LlamaIndex. Векторы лежат в Qdrant, Weaviate или Chroma, а когда отдельное хранилище незачем — в pgvector рядом с базой. Точный текст ищет Elasticsearch, на короткий запрос HyDE сначала строит вероятный ответ и ищет уже по нему, поверх кандидатов работает переранжирование. Ответ пишет языковая модель — GPT-4o, Claude, YandexGPT, GigaChat или Llama 3 в собственном контуре; поведение самой модели меняют fine-tuning и LoRA.

Как принимают работу: пороги качества задают заранее

Что считать хорошим ответом, договариваются до начала разработки: заказчик и Dzeta AI собирают набор вопросов и задают по нему два порога — на точность ответа и на время ответа. Дальше это условие приёмки: код сдаётся, когда пороги достигнуты. Метрики ниже показывают, из чего складывается точность и где именно конвейер даёт сбой. Документные задачи проверяем на 10⁠–⁠20 документах заказчика.

Названия метрик взяты из RAGAS, открытого фреймворка оценки RAG-систем. Значение любой из них осмысленно только рядом с набором вопросов, на котором снято, поэтому пороги задают на ваших данных.

Смена модели без переделки системы

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

Кейсы Dzeta AI: где этот конвейер уже собран

У Dzeta AI 50+ реализованных проектов в 8 отраслях. Отбор кандидатов, переранжирование и уровни уверенности этой страницы видны в трёх из них.

Оптовый дистрибьютор инженерных систем держит в индексе 389 тысяч позиций: 60 филиалов на едином каталоге, более 300 менеджеров ежедневно. Каждая позиция проиндексирована тремя способами, кандидаты ранжируются заново, три уровня уверенности разводят заявку по маршрутам, каталог синхронизируется с 1С. Отраслевая сторона — как устроен приём заявок у дистрибьютора.

IzzyBooking, международный агрегатор бронирования, сводит к одному виду данные более чем от 100 поставщиков. Запрос обычным языком он разбирает на параметры (даты, бюджет, формат) и ранжирует предложения в реальном времени. Поиск IzzyBooking в 3 раза точнее решений с фильтрами и ключевыми словами; проект собрали за 3 месяца, в производстве он с 2025 года.

Ассистент эксперта в Telegram показывает, как работает граница корпуса: источником служат только материалы, которые эксперт заверил заранее, и придумывать сверх них ассистенту нечем. Из собранных ответов он складывает разбор из 15 блоков. Клиентскую сторону разбирает диалог с клиентом, который система ведёт сама.

Как внедряют RAG-систему: аудит, пилот, приёмка

Начинают с малого: пилот на ограниченном наборе материалов обходится дешевле спора о том, соберётся ли конвейер на ваших данных.

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

Где работает система и кто видит материалы

В контуре заказчика RAG-систему разворачивают на открытых моделях: документы, вопросы и ответы остаются внутри компании, персональные данные её не покидают (152-ФЗ «О персональных данных»), подтверждения пишутся в журнал.

Когда RAG не нужен

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

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