Прибыль:
- Проектирование компонентов и потока данных комплексного корпоративного помощника RAG
- Объединение данных из нескольких источников (вики, тикет, PDF, база данных) в одном помощнике
- Принимайте архитектурные решения для масштабируемости, кэширования и задержки.
В предыдущих модулях мы изучали части одну за другой: встраивание, векторную базу данных, фрагментирование, извлечение. Теперь давайте объединим их и создадим комплексную архитектуру помощника, который взаимодействует с данными вашей компании. Цель состоит в том, чтобы сотрудник спросил: «Какова наша политика в отношении отпусков?» Система, в которой люди могут задавать вопросы, ответы основаны на реальных внутренних документах, цитатах и объединяют несколько источников данных. Это подразделение обрабатывает всю архитектуру, поток данных и решения на уровне производства.
Комплексные компоненты
Корпоративный RAG-ассистент состоит из двух отдельных линий. Линия индексации (оффлайн) подготавливает данные; Строка запроса (онлайн) отвечает на вопрос.
Индексация компонентов линии:
- Коннекторы: коннекторы, которые извлекают данные из источников — вики, системы заявок, хранилища файлов, базы данных, электронной почты.
- Нормализация: Преобразование различных форматов (PDF, HTML, DOCX) в чистый текст; очистка верхнего/подвала.
- Разбивка на части + метаданные: Разбивка на части и тегирование (источник, дата, авторитет).
- Встраивание + загрузка: Запись векторов и метаданных в векторную базу данных.
Компоненты конвейера запросов:
- Предварительная обработка запросов: переписывание, децентрализация.
- Поиск: гибридный поиск + фильтр метаданных + повторное ранжирование.
- Создание подсказки: Размещение контекста+вопроса+инструкции в шаблоне.
- Генерация: Обоснованный (контекстный) ответ из модели + источники.
- Постобработка: форматирование цитат, проверка безопасности, протоколирование.
Совет: Физически отделите строку индексирования от строки запроса. Индексирование происходит медленно и периодично (запускается пакетами в одночасье); Линия расследования должна быть легкой и немедленной. Смешение двух строк приводит к тяжелой обработке, пока пользователь ждет.
Визуализация потока данных
[ИНДЕКСИРОВАНИЕ - оффлайн]Ресурсы → Нормализовать → Чанк+Метаданные → Встроить → Векторная БД (вики, тикет, PDF, БД)[ЗАПРОС — онлайн]Вопрос пользователя → Предварительная обработка → Извлечение (гибрид+фильтр+переранжирование) → Подсказка (контекст+вопрос+инструкция) → Модель → Ответ+Источник → Пользователь
Объединение данных из нескольких источников
В реальных компаниях ответ не ограничивается одним местом. «Как оформить возврат денег покупателю?» Ответ на вопрос можно найти как в справочной статье (процедура), так и в истории заявок (реальные примеры), а также в PDF-файле политики (правила). Ассистент должен искать их все в одном пуле.
Критический момент: при объединении ресурсов в одно векторное хранилище каждый шард должен нести метаданные source_tour. Таким образом, вы можете искать их все и при необходимости фильтровать, например, «приводить только официальную политику». Кроме того, разные источники имеют разный уровень надежности: официальная политика > справочная статья > записка сотрудника. Вы можете указать этот приоритет при повторном ранжировании или подсказке.
Источник
Тип контента
доверие
Частота обновления
Политика PDF
официальное правило
высокий
ежемесячно
Справочная статья
Процедура
средне-высокий
еженедельно
История билетов
реальный образец
средний
Непрерывный
вики
Смешанная/текущая нота
Переменная
Непрерывный
Масштабируемость, кэш и задержка
В производстве выделяются три проблемы. Задержка: качество работы ухудшается, когда пользователь ждет более 2 секунд. Решение: отображать ответ в потоковом виде — он выливается на экран по мере того, как пишет модель. Кэш. Для часто задаваемых вопросов и повторяющихся контекстов кэш увеличивает скорость и снижает затраты. Масштаб: по мере роста пользователя необходимо иметь возможность масштабировать поиск и моделировать вызовы по горизонтали.
Эмпирическое правило в отношении затрат: обычно самый дорогой шаг — это количество токенов, идущих на более крупную модель. Таким образом, сокращение контекста до 4 хороших частей путем повторного ранжирования повышает как качество, так и стоимость. Обычно используется меньшая/более быстрая модель для простой классификации или маршрутизации и более мощная модель для окончательного ответа (например, claude-opus-4-8).
Внимание: не настраивайте индексацию по принципу «сделай один раз и забудь». Документы изменяются, удаляются, добавляются. Установите стратегию переиндексации: обнаруживайте измененные документы и повторно обрабатывайте только их. Устаревший индекс выдает ответ, который выглядит актуальным, но неверным.
Слабая архитектура/Сильная архитектура
Слабые (один сценарий, все смешано):
Когда пользователь спрашивает: прочитайте документы в этот момент, измельчите их, встройте, выполните поиск, ответьте на них.# Проблема: вся индексация повторяется для каждого вопроса; секунды задержки, # без разделения источников, без фильтра, без обновления.
Мощный (разделенные каналы + метаданные + кеш + потоковая передача):
Индексирование: пакетное выполнение в ночное время с обновлением измененных документов. Запрос: облегченная строка — предварительная обработка → гибридный поиск+фильтр → переранжирование → подсказка → модель (потоковая передача) → цитирование → журнал. Часто задаваемые вопросы и исходники кэшируются.
Три мини-кейса
Случай 1 — Перепутанная линия, сильная задержка. Стартап написал сценарий, который повторно обрабатывает PDF-файлы с каждым вопросом; Каждый ответ занимал в среднем 11 секунд. При разделении строки индексации и предварительной передаче данных в векторное хранилище время запроса уменьшалось до 1,3 секунды, а при потоковой передаче «первое слово» появлялось через 400 мс.
Случай 2. Слишком много ресурсов, неправильный приоритет. Помощник службы поддержки придал одинаковое значение PDF-файлу с политикой и старым примечаниям к билетам; Модель иногда представляла неправильный рейтинг сотрудника двухлетней давности как официальное правило. Когда в подсказку были добавлены метаданные source_tour и инструкция «учитывать официальную политику в случае конфликта», количество ошибок ложного приоритета сократилось на 89%.
Случай 3 — Устаревший индекс. Ассистент отдела кадров работал с индексом, который не обновлялся 3 месяца; Политика отпусков изменилась, но помощник вспоминал старые времена. Когда было установлено ежедневное обновление, которое обнаруживает измененные файлы, текущий уровень ответа увеличился с 70% до 99%.
Распространенные ошибки
- Смешивание строк индексации и запроса: тяжелая обработка выполняется, пока пользователь ждет; задержка взрывается.
- Не указывать тип источника в метаданных: нет приоритезации и фильтрации; Ненадежный источник, похоже, является официальным.
- Отсутствие стратегии обновления: индекс устаревает; Производятся неправильные ответы, которые кажутся актуальными.
- Пропустить потоковую передачу: пользователь смотрит на пустой экран; Воспринимаемая задержка становится высокой.
- Использование самой большой модели на каждом этапе: стоимость неоправданно возрастает; Оставьте рулевое управление меньшей модели.
В заключение
- Корпоративный RAG-помощник состоит из двух отдельных линий: автономное индексирование и онлайн-запрос; разделить их физически.
- Индексирование = соединитель + нормализация + фрагмент/метаданные + встраивание/загрузка; запрос = предварительная обработка + извлечение + подсказка + генерация + постобработка.
- Данные из нескольких источников объединяются в один репозиторий, но метаданные source_type и приоритет доверия сохраняются.
- Потоковая передача и кэширование с учетом задержки, регулирование контекста и выбор модели по стоимости имеют решающее значение.
- Без повторной индексации индекс устаревает; Регулярно обрабатывайте изменяющиеся документы.
Задача приложения
Нарисуйте архитектурную схему помощника для своей команды. (1) Определите как минимум три реальных источника данных и запишите потребность в соединителе, частоту обновления и уровень доверия для каждого. (2) Нарисуйте линии индексации и запроса отдельно с помощью диаграммы со стрелками. (3) «Где я могу уменьшить задержку и стоимость в этом помощнике?» Напишите не менее двух конкретных решений к вопросу. (4) Опишите свою стратегию обновления в одном предложении: какой ресурс будет переиндексироваться и как часто?
контрольный список
- [ ] Я могу рисовать строки индексации и запроса отдельно и с правильными компонентами.
- [ ] Я могу комбинировать данные из нескольких источников с помощью source_type и приоритета доверия.
- [ ] Я могу принимать решения о потоковой передаче/кэшировании с учетом задержки и выборе модели с учетом стоимости.
- [ ] Я знаю, почему так важна стратегия переиндексации.
- [ ] Я имею в виду, что самым дорогим шагом в моей архитектуре обычно является токен, который передается в более крупную модель.