Генерация с дополнением поиска (RAG) — это метод, при котором модель ИИ сначала ищет соответствующие отрывки в ваших собственных документах, а затем пишет ответ, используя эти отрывки в качестве контекста. Перевод пилотного проекта RAG в производство требует чистого инвентаря источников, разумного чанкинга, протестированного уровня поиска, набора для оценки с известными ответами, контроля доступа и мониторинга. Пропуск этапа оценки — самая частая причина, по которой пилоты хорошо выглядят в демо-версиях, но терпят неудачу при работе с реальными пользователями.
RAG стал стандартным способом заставить языковые модели отвечать на основе знаний компании без их переобучения. Служба поддержки, которая читает справочный центр, инструмент продаж, который цитирует текущий прайс-лист, внутренний поиск по документам политики: все это системы RAG. Модель остается общей; знания поступают из поиска во время запроса, поэтому обновление документа обновляет ответ.
Из чего состоит система RAG?
Каждая установка RAG имеет одни и те же базовые части, независимо от того, какой фреймворк вы используете.
- Источники: документы, страницы, продуктовые фиды или таблицы баз данных, на основе которых вы хотите, чтобы система отвечала.
- Ингестия (Ingestion): загрузка, очистка и разбиение этих источников на чанки.
- Эмбеддинги: преобразование чанков в векторы с помощью модели эмбеддингов, чтобы похожие значения располагались близко друг к другу.
- Индекс: векторная база данных или поисковая система, такая как pgvector, Pinecone, Weaviate, Elasticsearch или OpenSearch, часто в сочетании с поиском по ключевым словам.
- Ретривер (Retriever): логика, которая находит лучшие чанки для вопроса, иногда с последующим переранжированием.
- Генератор: языковая модель, которая пишет ответ на основе полученных чанков.
- Уровень приложения: интерфейс, логирование, разрешения и обратная связь.
Фреймворки, такие как LangChain и LlamaIndex, а также управляемые опции в Azure AI Search, Google Vertex AI и Amazon Bedrock, объединяют многие из этих частей.
Фаза 1: контрольный список пилота
Пилот должен ответить на один вопрос: может ли поиск найти правильную информацию для реальных вопросов?
- Выберите один узкий вариант использования с четким владельцем, например, ответы на вопросы о доставке и возврате.
- Соберите от 50 до 100 реальных вопросов из тикетов, чатов или журналов поиска.
- Напишите правильный ответ и исходный документ для каждого. Это станет вашим набором для оценки.
- Инвентаризация источников: перечислите каждый документ, его владельца, частоту обновления и актуальность.
- Удалите устаревшие, дублирующиеся и противоречивые документы перед ингестией.
- Начните с простого чанкинга, например, по заголовку или по несколько сотен слов с некоторым перекрытием.
- Протестируйте только поиск: для каждого вопроса находится ли правильный источник в топе результатов?
- Только после этого подключайте генератор и тестируйте полные ответы.
Как следует чанкить и индексировать контент?
Чанкинг определяет, что может видеть модель. Слишком маленькие чанки теряют контекст; слишком большие чанки размывают релевантность и тратят токены.
Практические правила чанкинга
- Сначала делите по структуре документа: заголовки, разделы, пары FAQ, строки таблиц.
- Прикрепляйте название документа и заголовок раздела к каждому чанку в качестве метаданных.
- Храните URL источника, дату последнего обновления и уровень доступа вместе с каждым чанком.
- Относитесь к таблицам и спецификациям продуктов осторожно; преобразование таблицы в прозу часто портит ее.
Гибридный поиск, сочетающий сопоставление по ключевым словам с векторным сходством, обычно работает лучше, чем каждый из них по отдельности, особенно для кодов продуктов, названий и точных фраз, с которыми эмбеддинги справляются плохо.
Фаза 2: укрепление для производства
Как только поиск заработает, контрольный список переходит к надежности и безопасности.
- Инструкции по обоснованию (Grounding): скажите модели отвечать только на основе предоставленного контекста и говорить, когда ответа нет.
- Цитаты: показывайте ссылку на источник для каждого ответа, чтобы пользователи и проверяющие могли это проверить.
- Контроль доступа: фильтруйте поиск по разрешениям пользователя, чтобы клиент никогда не видел внутренние документы.
- Защита от инъекций промптов: относитесь к полученному тексту как к данным. Документ, содержащий “игнорируй предыдущие инструкции”, не должен менять поведение.
- Персональные данные: исключайте или маскируйте конфиденциальные поля при ингестии.
- Свежесть: планируйте повторную ингестию при изменении источников и удаляйте чанки из удаленных документов.
- Фолбэки (Fallbacks): направляйте вопросы без ответа человеку или в контактную форму.
Как узнать, достаточно ли хороша система?
Измеряйте поиск и генерацию отдельно. Если ответ неверный, вам нужно знать, какая часть не сработала.
- Частота попаданий поиска (Hit rate): доля вопросов оценки, где правильный источник появляется в топе результатов.
- Верность (Faithfulness): доля ответов, полностью подтвержденных полученным контекстом.
- Правильность ответа: доля ответов, совпадающих с эталонным ответом.
- Точность отказа: когда ответа нет в источниках, говорит ли система об этом?
- Задержка и стоимость одного ответа.
Инструменты, такие как Ragas, TruLens и функции оценки на основных облачных платформах, могут автоматизировать часть этого, но пусть люди проверяют выборку при каждом релизе. Установите цель для каждой метрики перед запуском и не выходите в эфир, пока не достигнете ее.
Фаза 3: мониторинг после запуска
- Логируйте каждый вопрос, ID полученных чанков и ответ.
- Собирайте обратную связь с помощью лайков и дизлайков с опциональным комментарием.
- Еженедельно просматривайте вопросы без ответа и с низкой оценкой; они выявляют недостающий контент.
- Перезапускайте набор для оценки после любого изменения чанкинга, модели эмбеддингов, промпта или модели генератора.
- Отслеживайте, какие источники запрашиваются чаще всего; убедитесь, что их владельцы знают, что они критически важны для бизнеса.
Как Alien Road применяет генерацию с дополнением поиска
В типичном проекте Discovery — это в основном работа с контентом. Мы собираем реальные вопросы из почты поддержки клиента, поиска по сайту и отдела продаж, а затем сопоставляем их с существующими страницами и документами. Это обычно выявляет пробелы и противоречия, которые нужно исправить до того, как будет задействован ИИ.
Настройка следует контрольному списку выше: очищенные источники, структурный чанкинг с метаданными, гибридный поиск и обоснованный промпт с цитатами. Разрешения разрабатываются с IT-контактом клиента, а набор для оценки согласовывается с владельцем бизнеса, чтобы все использовали одно и то же определение правильного ответа.
Измерение использует набор для оценки при каждом релизе плюс живую обратную связь после того, как система запущена. Ежемесячные отчеты содержат частоту попаданий поиска, верность, темы вопросов без ответа и обновления контента, которые они вызвали. Те же улучшения контента часто помогают и органическому поиску, потому что более понятные страницы лучше отвечают на вопросы как для людей, так и для поисковых систем.
С чего начать на этой неделе
Экспортируйте последние 100 вопросов клиентов или сотрудников из одного канала. Для каждого найдите страницу или документ, содержащий ответ, и отметьте те, для которых нет хорошего источника. Эта таблица одновременно является вашим набором для оценки и списком пробелов в контенте, и это фундамент любого пилота RAG, который стоит запускать.
Читайте далее: ИИ-оптимизация · ИИ-оптимизация