RAG или fine-tuning: архитектура AI в продакшене

Начните с ошибки, которую нужно исправить

Ассистент отвечает по устаревшему регламенту, выдаёт JSON в непоследовательном формате и показывает документ из аккаунта другого клиента. Это три разных дефекта. Добавление векторной базы или обучение адаптера не исправит их все.

RAG меняет материалы, предоставляемые модели при инференсе. Fine-tuning изменяет её поведение через обновление параметров или обучаемые адаптеры. Авторизация определяет, какие сведения и действия доступны пользователю. Архитектура для продакшена должна учитывать эти три аспекта независимо.

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

Явно определите источник истины

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

Руководство Microsoft по RAG отделяет опору на закрытые или изменяющиеся данные от адаптации поведения через fine-tuning. В примере поддержки корпус договоров может обслуживать поиск, а сервис заказов остаётся источником текущего состояния заказа. Интервал обновления индекса входит в требования к актуальности: изменение файла не делает документ доступным для поиска мгновенно.

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

Проектируйте поиск так, чтобы сохранять полноту оснований

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

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

{
  "document_id": "contract-482",
  "version": "approved-7",
  "section": "Cancellation / Exceptions",
  "effective_from": "2026-09-01",
  "tenant_id": "customer-17",
  "text": "...",
  "source_location": "page 8, section 4.2"
}

Названия полей приведены для примера. Они позволяют проверять допустимость использования, происхождение и актуальность вне модели. Сгенерированная ссылка должна открывать именно ту версию, на которую опиралось утверждение, с учётом прав читателя.

Объединяйте поисковые сигналы и измеряйте их вклад

Точные идентификаторы, коды товаров и строки ошибок могут требовать лексического совпадения. Семантический поиск помогает, когда пользователь описывает ту же идею другими словами. Гибридный набор кандидатов с последующим переранжированием стоит проверить, но улучшение не гарантировано.

Исследование Contextual Retrieval от Anthropic рассматривает добавление контекста к отдельным фрагментам и сочетание поиска с переранжированием. Его результаты относятся к изученной конфигурации. Воспроизведите сравнение на своём корпусе, прежде чем принимать такую же схему.

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

Длинный контекст не отменяет отбор и контроль версий

Большое входное окно позволяет принять больше материалов, но не доказывает надёжное использование каждой детали. Lost in the Middle показала зависимость качества извлечения информации от её положения в исследованных моделях и задачах. Это повод проверять расположение данных, а не постоянный рейтинг современных моделей.

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

Проверяйте доступ до передачи данных модели

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

Документация Azure AI Search по доступу на уровне документов описывает в том числе фильтры безопасности, задаваемые приложением. Часть встроенных интеграций находится на стадии preview; перед применением в продакшене проверьте актуальный статус поддержки. Архитектурный принцип шире конкретного поискового сервиса.

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

Применяйте fine-tuning к измеренной проблеме поведения

Рассматривайте fine-tuning, если модель систематически неверно применяет стабильную классификацию, плохо выполняет специализированное преобразование или не достигает требуемой последовательности ответов с помощью промптов. Обучающие примеры должны представлять целевую задачу, а примеры оценки — быть исключены из обучения.

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

Комбинированная схема может находить подтверждения в утверждённых договорах и использовать адаптированную модель для нужного формата ответа. Сравнивайте её с базовой системой поиска и неадаптированной моделью. Если сбоит поиск, измерьте эту проблему напрямую, прежде чем приписывать ошибку генератору.

Оценивайте этапы конвейера отдельно

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

• Поиск: содержат ли отобранные материалы полный и применимый ответ?
• Генерация: подтверждены ли утверждения и действительно ли цитируемые фрагменты их обосновывают?
• Поведение: соблюдены ли задача и схема вывода, включая уместный отказ или уточнение?
• Доступ: попало ли неразрешённое содержание в результаты поиска, контекст, кеш или ответ?
• Эксплуатация: каковы задержка p95, отставание индексации и стоимость принятого ответа?

Такое разделение делает отчёты об ошибках пригодными для исправлений. «Неверный ответ» превращается в «поиск вернул устаревшее исключение» или «генератор проигнорировал правильный фрагмент». У следующего изменения появляется конкретная цель.

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