Јединица 5 / 11

Асистент Архитектура који разговара са подацима компаније

Добици:

  • Дизајнирање компоненти и тока података РАГ помоћника предузећа од краја до краја
  • Комбиновање података из више извора (вики, улазница, ПДФ, база података) у један помоћник
  • Доносите архитектонске одлуке за скалабилност, кеширање и кашњење

У претходним јединицама учили смо делове један по један: уграђивање, векторска база података, цхункинг, проналажење. Хајде сада да их комбинујемо и направимо архитектуру од краја до краја асистента који разговара са подацима ваше компаније. Циљ је да запослени пита: „Која је наша политика одсуства?“ Систем у коме људи могу да постављају питања, одговори се заснивају на стварним интерним документима, цитатима и комбинују више извора података. Ова јединица обрађује целокупну архитектуру, ток података и одлуке на нивоу производње.

Енд-то-Енд компоненте

Корпоративни РАГ асистент се састоји од две одвојене линије. Линија за индексирање (оффлине) припрема податке; Линија упита (онлине) одговара на питање.

Компоненте линије индексирања:

  1. Конектори: Конектори који повлаче податке из извора — вики-ја, система тикета, продавнице датотека, базе података, е-поште.
  2. Нормализација: Конвертовање различитих формата (ПДФ, ХТМЛ, ДОЦКС) у чист текст; чишћење заглавља/подножја.
  3. Сецкање + метаподаци: Сецкање и означавање (извор, датум, ауторитет).
  4. Уграђивање + учитавање: Уписивање вектора и метаподатака у векторску базу података.

Компоненте цевовода упита:

  1. Претходна обрада упита: поновно писање, децентрализација.
  2. Преузимање: Хибридна претрага + филтер метаподатака + поновно рангирање.
  3. Брзо креирање: Постављање контекста + питања + инструкција у шаблон.
  4. Генерисање: Основан (контекстуални) одговор из модела + извори.
  5. Накнадна обрада: Форматирање цитата, безбедносна провера, евидентирање.
Савет: Физички одвојите линију за индексирање од линије упита. Индексирање је споро и периодично (ради у серијама преко ноћи); Линија истраге треба да буде лагана и непосредна. Мешање две линије доводи до тешке обраде док корисник чека.

Визуелизација тока података

[ИНДЕКСИРАЊЕ - ван мреже]Ресурси → Нормализуј → Група+метаподаци → Угради → Векторски ДБ (вики, тикет, ПДФ, ДБ)[УПИТ - на мрежи]Корисничко питање → Претходна обрада → Преузимање (хибрид+филтер+поновно рангирање) → Промпт (контекст+питање+инструкција) → Модел → Одговор корисника+извор

Комбиновање података из више извора

У правим компанијама, одговор се не зауставља на једном месту. „Како издати повраћај новца купцу?“ Одговор на питање можете пронаћи и у чланку помоћи (процедура), у историји тикета (прави примери) и у ПДФ-у политике (правила). Помоћник треба да их све претражи у једном базену.

Критична тачка: када се ресурси комбинују у једно векторско складиште, сваки део мора да носи метаподатке `соурце_тоур`. Дакле, можете их све претражити и филтрирати ако је потребно, као што је „донесите само званичне политике“. Такође, различити извори имају различите нивое поузданости: званична политика > чланак помоћи > белешка о улазници запосленог. Можете да одредите овај приоритет у поновном рангирању или промпту.

Извор

Тип садржаја

поверење

Учесталост ажурирања

Полици ПДФ

званично правило

висока

месечно

Чланак помоћи

Процедура

средње висок

недељно

Историја карата

прави узорак

средње

Континуирано

вики

Мешовита/тренутна нота

Променљива

Континуирано

Скалабилност, кеш меморија и кашњење

У производњи се издвајају три питања. Латенција: искуство се погоршава када корисник чека више од 2 секунде. Решење: прикажите одговор у стриминг форми — сипа се на екран док модел пише. Кеш меморија: За често постављана питања и контексте који се понављају, кеш и повећава брзину и смањује трошкове. Скала: Како се корисник повећава, потребно је бити у могућности хоризонтално скалирати преузимање и моделирати позиве.

Правило на страни трошкова: најскупљи корак је обично број токена који иду на већи модел. Стога, смањење контекста на 4 добра дела поновним рангирањем побољшава и квалитет и цену. Уобичајени дизајн је да се користи мањи/бржи модел за једноставну класификацију или рутирање и моћнији модел за коначни одговор (нпр. Цлауде-опус-4-8).

Опрез: Не подешавајте индексирање као "уради једном, заборави". Документи се мењају, бришу, додају. Успоставите стратегију поновног индексирања: откријте промењене документе и поново их обрадите. Застарели индекс даје одговор који се чини актуелним, али је погрешан.

Слаба архитектура / јака архитектура

Слабо (једна скрипта, све помешано):

Када корисник пита: прочитајте документе у том тренутку, раздвојите их, уградите, претражите их, одговорите на њих. # Проблем: сво индексирање се понавља за свако питање; секунди кашњења, # без раздвајања извора, без филтера, без освежавања.

Моћан (подељене цеви + метаподаци + кеш + стримовање):

Индексирање: серија ради ноћу, освежавање измењених докумената. Упит: лагана линија — претходна обрада → хибридно преузимање+филтер → прерангирање → упит → модел (стриминг) → цитат → дневник. Често постављана питања и извор су кеширани.

Три мини кућишта

Случај 1 — Збуњена линија, велико кашњење. Стартуп је написао скрипту која поново обрађује ПДФ-ове са сваким питањем; Сваки одговор је у просеку трајао 11 секунди. Када је индексна линија раздвојена и подаци су претходно пребачени у векторско складиште, време упита се смањило на 1,3 секунде и са стримингом, „прва реч“ се појавила за 400 мс.

Случај 2 — Превише ресурса, погрешан приоритет. Помоћник за подршку дао је једнаку тежину ПДФ-у о политици и старим биљешкама; Модел је понекад представљао нетачну оцену запосленог од пре две године као званично правило. Када су метаподаци соурце_тоур и инструкција „размотрите званичну политику у случају конфликта“ додани у промпту, грешке са лажним приоритетом су смањене за 89%.

Случај 3 — Застарели индекс. ХР асистент је радио са индексом који није ажуриран 3 месеца; Политика одсуства се променила, али асистент је говорио старим данима. Када је инсталирано дневно освежавање, које открива промењене датотеке, стопа тренутног одговора се повећала са 70% на 99%.

Уобичајене грешке

  • Мешање линија за индексирање и упите: Тешка обрада се обавља док корисник чека; кашњење експлодира.
  • Не стављајући тип извора у метаподатке: Нема приоритета и филтрирања; Чини се да је непоуздани извор званичан.
  • Не успостављање стратегије освежавања: Индекс постаје застарео; Настају погрешни одговори који изгледају актуелни.
  • Прескочи стримовање: Корисник гледа празан екран; Уочено кашњење постаје велико.
  • Коришћење највећег модела на сваком кораку: Трошкови се непотребно повећавају; Оставите управљање мањем моделу.

Укратко

  • Корпоративни РАГ помоћник се састоји од две одвојене линије: офлајн индексирање и онлајн упит; физички их раздвојити.
  • Индексирање = конектор + нормализација + комад/метаподаци + уградња/пренос; упит = пре-процес + преузимање + промпт + генерисање + накнадна обрада.
  • Подаци из више извора су комбиновани у једно спремиште, али су сачувани метаподаци типа_извора и приоритет поверења.
  • Стримовање и кеш за кашњење, ограничавање контекста и избор модела за цену су критични.
  • Без поновног индексирања, индекс постаје застарео; Редовно обрадите документе који се мењају.

Задатак апликације

Нацртајте архитектонски дијаграм асистента за свој тим. (1) Идентификујте најмање три стварна извора података и запишите потребу за конектором, учесталост ажурирања и ниво поверења за сваки. (2) Нацртајте линије за индексирање и упите одвојено дијаграмом оквир-стрелица. (3) „Где да смањим кашњење и трошкове у овом помоћнику?“ Напишите најмање две конкретне одлуке на питање. (4) Опишите своју стратегију освежавања у једној реченици: који ресурс ће бити поново индексиран и колико често?

контролна листа

  • [ ] Могу да нацртам линије за индексирање и упите одвојено и са исправним компонентама.
  • [ ] Могу комбиновати податке из више извора са изворним_типом и приоритетом поверења.
  • [ ] Могу да доносим одлуке о стримовању/кеширању за кашњење и избор модела за цену.
  • [ ] Знам зашто је стратегија поновног индексирања неопходна.
  • [ ] Имам на уму да је најскупљи корак у мојој архитектури обично токен који иде на већи модел.