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