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