Планирование проекта RAG или ИИ-ассистента: чек-лист

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

Этот чек-лист собирает вопросы, которые мы прорабатываем перед построением системы retrieval-augmented generation (RAG) или ИИ-ассистента на корпоративных данных. Используйте его, чтобы подготовить внутренний проект, сформулировать задание подрядчику или проверить, покрывает ли полученное предложение главное. Не обязательно иметь все ответы в первый день, но нужно знать, какие ещё открыты.

1. Сценарий использования и критерии успеха#

Зафиксируйте это до того, как кто-либо откроет ноутбук или начнёт сравнивать модели.

• Одна главная задача. Назовите единственную задачу, которую ассистент должен сначала делать хорошо — например, отвечать на вопросы агентов поддержки о продуктах или находить пункты в контрактах поставщиков. Дальнейшие сценарии можно добавлять, когда первый измерен; смешивание нескольких на старте размывает и требования, и оценку.
• Пользователи и их контекст. Опишите, кто спрашивает, как часто, на каком языке и на каком устройстве и что они делают с ответом. Внутреннему эксперту, проверяющему источники, нужно не то же самое, что клиенту, действующему по ответу напрямую.
• Реальные вопросы с идеальными ответами. Соберите 20–50 реальных вопросов из тикетов, писем или логов чата и попросите эксперта предметной области написать идеальный ответ и назвать источник, откуда он должен быть взят. Этот набор определяет, что значит «хорошо», и становится зародышем вашего оценочного набора.
• Вне области и отказы. Перечислите, чего ассистент не должен делать: давать юридические, медицинские или финансовые советы, отвечать за пределами своих источников, брать обязательства от имени компании. Решите, что он должен говорить вместо этого и куда направлять пользователя.
• Базовая линия текущего процесса. Зафиксируйте, как задача выполняется сегодня, сколько времени занимает, кто её делает и во сколько обходится. Без базовой линии «ассистент помогает» — мнение, а не результат.

2. Источники данных#

Качество ответов ограничено качеством и доступностью контента, лежащего за ними.

• Инвентаризация источников. Перечислите каждый источник, который должен использовать ассистент: вики, папки SharePoint или Google Drive, тикет-системы, базы данных, PDF, веб-сайты. Для каждого отметьте, как к нему можно получить доступ (API, экспорт, краулинг) и разрешён ли такой доступ.
• Форматы и качество документов. Проверьте наличие сканированных PDF, требующих OCR, сложных таблиц, форм, слайдов и изображений с существенным содержимым. Таблицы и сканы — то место, где наивные конвейеры теряют больше всего информации, поэтому отсэмплируйте их заранее.
• Владение и свежесть. Назначьте владельца каждого источника и запишите, как часто он меняется. Если у контента нет владельца, никто не будет чинить неправильные ответы, которые из него возникают.
• Дубли, версии и языки. Выявите устаревшие копии, черновики и параллельные версии одной и той же политики и решите, какая из них авторитетна. Отметьте языки и документов, и вопросов, потому что межъязыковой поиск нужно тестировать явно.

3. Контроль доступа и приватность#

Урегулируйте это до того, как реальные данные покинут ваши системы.

• Права, перенесённые в поиск. Если пользователи могут видеть только определённые документы, поиск должен фильтровать по правам запрашивающего пользователя, синхронизированным из исходных систем. Инструкции в промпте или доверие модели не раскрывать контент — это не контроль доступа.
• Персональные данные и правовое основание. Выявите персональные данные в документах, вопросах и логах и задокументируйте правовое основание GDPR и цель их обработки. Привлекайте вашего ответственного за защиту данных в начале, а не на запуске.
• Контракт с провайдером и резидентность данных. Заключите соглашение об обработке данных с каждым провайдером модели и инфраструктуры, проверьте их субпроцессоров и подтвердите, что обработка может оставаться в регионе ЕС, если вам это нужно. Получите письменное подтверждение, что ваши данные не используются для обучения моделей провайдера.
• Хранение, логирование и редактирование. Решите, как долго хранятся промпты, найденные фрагменты и ответы, кто может их читать и редактируются ли персональные данные перед логированием. Логи нужны для отладки и оценки, поэтому цель — контролируемое хранение, а не нулевое логирование.

4. Проектиро­вание поиска#

Большинство неправильных ответов в RAG-системах восходит к поиску, а не к модели; для небольшого стабильного корпуса длинный контекст с кешированием промптов может полностью заменить поиск (см. RAG или дообучение).

• Чанкинг по структуре документа. Разбивайте контент по заголовкам, разделам, элементам списков и границам таблиц, а не по фиксированному числу символов. Храните путь заголовков с каждым чанком, чтобы фрагмент сохранял смысл сам по себе.
• Метаданные и фильтры. Храните заголовок, источник, раздел, дату, язык, версию и группы доступа с каждым чанком. Метаданные — это то, что делает возможной фильтрацию по правам, правила «только последняя версия» и полезное цитирование.
• Гибридный поиск и переранжирование. Сочетайте поиск по ключевым словам для точных терминов — кодов продуктов, артикулов, названий — с векторным поиском по эмбеддингам для смысла, затем переранжируйте объединённых кандидатов. Тестируйте каждый шаг на своих примерах вопросов вместо того, чтобы полагаться на настройки по умолчанию.
• Обязательное цитирование. Требуйте, чтобы ассистент цитировал использованные фрагменты со ссылкой на исходный документ и раздел. Цитаты позволяют пользователям проверять ответы, а ревьюерам — видеть, возник ли неверный ответ из-за плохого поиска или плохой генерации.

5. Выбор модели и провайдера#

Выбирайте модель, когда у вас уже есть оценочный набор, чтобы решение опиралось на ваши данные, а не на общие бенчмарки.

• Вариант хостинга. Сравните хостинговый API, те же или похожие модели в облачном регионе ЕС и самостоятельно размещённую модель с открытыми весами на вашей инфраструктуре. Каждый вариант сдвигает баланс между качеством ответов, контролем данных, эксплуатационными усилиями и стоимостью.
• Задержка и стоимость запроса. Измерьте сквозное время ответа и стоимость отвеченного вопроса на своих примерах вопросов, включая поиск, переранжирование и входные и выходные токены. Кеширование промптов и меньшие модели для простых шагов могут заметно изменить эти цифры.
• Запасной вариант и привязка к вендору. Спланируйте, что происходит, когда провайдер недоступен или выводит модель из эксплуатации: второй провайдер, деградированный режим или понятное сообщение об ошибке. Держите промпты, оценочный набор и слой поиска нейтральными к провайдеру, чтобы переключение было сменой конфигурации плюс прогон оценки, а не переписыванием.

6. Оценка качества#

Если вы не можете измерить качество, вы не можете его улучшить или защитить решение о запуске.

• Оценочный набор до разработки. Превратите реальные вопросы из раздела 1 в версионируемый оценочный набор с ожидаемыми ответами и ожидаемыми источниками и расширьте его сложными и граничными случаями. Соберите его до первого прототипа, а не после первого демо.
• Качество поиска и ответов. Измеряйте отдельно, были ли найдены правильные фрагменты и корректен ли, полон ли и верен ли этим фрагментам ответ. Проверяйте точность цитирования: процитированный фрагмент должен действительно подтверждать утверждение.
• Тесты отказов и промпт-инъекций. Включите вопросы, которые ассистент должен отклонить, и вопросы, на которые его источники не могут ответить, и проверьте, что он честно это сообщает вместо угадывания. Добавьте документы и вводы, пытающиеся переопределить его инструкции или извлечь данные других пользователей, и убедитесь, что они терпят неудачу.
• Регрессионные прогоны и человеческое ревью. Запускайте полный оценочный набор при каждом изменении промптов, моделей, чанкинга или данных и сравнивайте результаты с предыдущим прогоном. Автоматическая оценка моделью ускоряет процесс, но эксперт предметной области должен регулярно выборочно проверять результаты.

7. Интеграция и эксплуатация#

Ассистент должен где-то жить, и кто-то должен его эксплуатировать после запуска.

• Канал и вход. Решите, где живёт ассистент: виджет на сайте, Slack или Microsoft Teams, внутренний инструмент или существующая тикет-система. Используйте ваш SSO, чтобы идентичность и права приходили из того же места, что и везде.
• Передача человеку и обратная связь. Определите, как пользователь достаёт человека, когда ассистент не может помочь, с передачей контекста разговора. Добавьте простые кнопки обратной связи и направляйте негативную обратную связь в оценочный набор.
• Модель стоимости и мониторинг. Оцените стоимость запроса и стоимость в месяц при ожидаемой и пиковой нагрузке и настройте бюджетные оповещения. Мониторьте задержку, долю ошибок, долю отказов и обратную связь пользователей с редактированием логов, как договорено в разделе 3.
• Переиндексация, владение контентом и инциденты. Автоматизируйте переиндексацию при изменении исходных документов, включая удаления, чтобы ассистент никогда не цитировал отозванный контент. Назначьте, кто чинит проблемы с контентом, и определите процесс реагирования на неправильные, вредоносные или утёкшие ответы, включая способ быстро отключить ассистента.

8. Критерии go/no-go#

Договоритесь о правилах принятия решения до появления результатов, чтобы решение не принималось на основании удачного демо.

• Заранее согласованные пороги. Запишите минимальные уровни корректности ответов и точности цитирования на оценочном наборе, приемлемую задержку и стоимость запроса и нулевую терпимость к ответам, пересекающим границы прав доступа. Сравните результаты с базовой линией из раздела 1.
• Ограниченный по времени пилот с понятным выходом. Проведите пилот с небольшой группой реальных пользователей в течение фиксированного срока с назначенным лицом, принимающим решение. Сужение объёма или остановка — легитимный результат, и он гораздо дешевле, чем узнать об этом после полного развёртывания.

Как мы можем помочь#

Если хотите пройти этот чек-лист вместе с нами, самый прямой путь — наш AI Proof-of-Value Sprint с фиксированным объёмом. За две недели мы вместе с вами определим рамки сценария использования, построим прототип RAG или агента на ваших данных, создадим оценочный набор, подготовим модель стоимости и выдадим go/no-go отчёт, который можно отнести лицам, принимающим решения. Подробности — на странице цен и в разделе услуг AI & Automation.

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