Табыстар:
- Кәсіпорынның RAG көмекшісінің құрамдас бөліктері мен деректер ағынын жобалау
- Көп дереккөзді деректерді (wiki, билет, PDF, дерекқор) бір көмекшіге біріктіру
- Масштабтау, кэштеу және кешігу үшін архитектуралық шешімдер қабылдаңыз
Алдыңғы бөлімдерде біз бөліктерді бір-бірлеп үйрендік: ендіру, векторлық деректер базасы, бөлшектеу, іздеу. Енді осыларды біріктіріп, сіздің компанияңыздың деректерімен сөйлесетін көмекшінің архитектурасын құрайық. Мақсат - қызметкерден: «Біздің демалыс саясатымыз қандай?» Деп сұрау. Адамдар сұрақтар қоя алатын жүйе, жауаптар нақты ішкі құжаттарға, дәйексөздерге негізделген және көптеген деректер көздерін біріктіреді. Бұл құрылғы бүкіл архитектураны, деректер ағынын және өндіріс деңгейіндегі шешімдерді өңдейді.
Құрамдас бөліктер
Корпоративтік RAG көмекшісі екі бөлек жолдан тұрады. Индекстеу жолы (офлайн) деректерді дайындайды; Сұрау жолы (онлайн) сұраққа жауап береді.
Индекстеу жолының құрамдас бөліктері:
- Қосқыштар: дереккөздерден деректерді алатын қосқыштар — вики, билет жүйесі, файлдар қоймасы, дерекқор, электрондық пошта.
- Нормалау: Әртүрлі форматтарды (PDF, HTML, DOCX) таза мәтінге түрлендіру; жоғарғы/төменгі деректемелерді тазалау.
- Chunking + метадеректер: бөлшектеу және белгілеу (көзі, күні, өкілеттігі).
- Енгізу + жүктеу: векторлар мен метадеректерді векторлық дерекқорға жазу.
Сұрау құбырының құрамдастары:
- Сұрауды алдын ала өңдеу: қайта жазу, орталықсыздандыру.
- Іздеу: гибридті іздеу + метадеректер сүзгісі + қайта бағалау.
- Шақыруды құру: Үлгіге мәтінмән + сұрақ + нұсқауларды орналастыру.
- Генерация: Үлгі + көздерден негізделген (контекстік) жауап.
- Кейінгі өңдеу: дәйексөзді пішімдеу, қауіпсіздікті тексеру, журналға жазу.
Кеңес: Индекстеу жолын сұрау жолынан физикалық түрде бөліңіз. Индекстеу баяу және мерзімді (бір түнде партиялармен жұмыс істейді); Сұрау желісі жеңіл және шұғыл болуы керек. Екі жолды араластыру пайдаланушы күткен кезде ауыр өңдеуге мәжбүр етеді.
Деректер ағынын визуализациялау
[ИНДЕКСТЕУ - офлайн]Ресурстар → Нормалау → Бөлік+Метадеректер → Енгізу → Векторлық ДБ (wiki, билет, PDF, DB)[QUERY - онлайн]Пайдаланушы сұрағы → Алдын ала өңдеу → Іздеу (гибридті+сүзгі+қайта рейтинг) → Хабарлау (контекст+сұрақ+нұсқау) →Пайдаланушы → Нұсқау
Көпкөзді деректерді біріктіру
Нағыз компанияларда жауап бір жерде тоқтамайды. «Клиентке ақшаны қалай қайтаруға болады?» Сұрақтың жауабын анықтамалық мақаладан (процедурадан), билеттер тарихынан (нақты мысалдар) және PDF саясатында (ережелер) табуға болады. Көмекші олардың барлығын бір пулда іздеуі керек.
Маңызды сәт: ресурстарды бір векторлық қоймаға біріктіру кезінде әрбір үзіндіде 'source_tour' метадеректері болуы керек. Сондықтан олардың барлығын іздеп, қажет болған жағдайда сүзуге болады, мысалы, «тек ресми саясаттарды әкеліңіз». Сондай-ақ, әртүрлі көздердің сенімділік деңгейі әртүрлі: ресми саясат > анықтамалық мақала > қызметкердің билет жазбасы. Бұл басымдықты қайта рейтингте немесе сұрауда көрсетуге болады.
Дереккөз
Мазмұн түрі
сенім
Жаңарту жиілігі
Саясат PDF
ресми ереже
жоғары
ай сайын
Көмекші мақала
Процедура
орташа-жоғары
апта сайын
Билет тарихы
нақты үлгі
орташа
Үздіксіз
вики
Аралас/ағымдағы нота
Айнымалы
Үздіксіз
Масштабтау, кэш және кешігу
Өндірісте үш мәселе көзге түседі. Кідіріс: пайдаланушы 2 секундтан астам күткен кезде тәжірибе нашарлайды. Шешім: жауапты ағындық пішінде көрсету — ол модель жазу кезінде экранға құйылады. Кэш: Жиі қойылатын сұрақтар мен қайталанатын мәтінмәндер үшін кэш жылдамдықты арттырады және шығынды азайтады. Масштаб: Пайдаланушы ұлғайған сайын іздеуді масштабтау және қоңырауларды көлденең үлгілеу мүмкіндігі қажет.
Шығындар жағында негізгі ереже: ең қымбат қадам әдетте үлкенірек үлгіге баратын белгілердің саны болып табылады. Сондықтан, қайта сұрыптау арқылы контекстті 4 жақсы бөлікке дейін азайту сапаны да, құнын да жақсартады. Жалпы дизайн қарапайым жіктеу немесе маршруттау үшін кішірек/жылдамырақ үлгіні және соңғы жауап үшін неғұрлым қуатты модельді пайдалану болып табылады (мысалы, claude-opus-4-8).
Абайлаңыз: «бір рет жасаңыз, ұмытыңыз» деп индекстеуді орнатпаңыз. Құжаттар өзгертіледі, жойылады, қосылады. Қайта индекстеу стратегиясын жасаңыз: өзгертілген құжаттарды анықтаңыз және тек оларды қайта өңдеңіз. Ескірген индекс ағымдағы болып көрінетін, бірақ қате жауап береді.
Әлсіз архитектура / Күшті архитектура
Әлсіз (бір сценарий, барлығы аралас):
Пайдаланушы сұраған кезде: құжаттарды сол сәтте оқыңыз, ұсақтаңыз, ендіріп, іздеңіз, жауап беріңіз.# Мәселе: әрбір сұрақ үшін барлық индекстеу қайталанады; секундтық кідіріс, # көзді бөлу, сүзгі, жаңарту жоқ.
Күшті (бөлінген құбырлар + метадеректер + кэш + ағын):
Индекстеу: бума түнде жұмыс істейді, өзгертілген құжаттарды жаңартады. Сұрау: жеңіл сызық — алдын ала өңдеу → гибридті іздеу+сүзгі → қайта рейтинг → сұрау → үлгі (ағын) → дәйексөз → журнал. Жиі қойылатын сұрақтар мен дереккөз кэштелген.
Үш шағын корпус
1-жағдай — Шатастырылған сызық, ауыр кешігу. Стартап әр сұрақпен PDF файлдарын қайта өңдейтін сценарий жазды; Әрбір жауап орташа есеппен 11 секундты алды. Индекстеу сызығы бөлінгенде және деректер бұрын векторлық қоймаға жіберілгенде, сұрау уақыты 1,3 секундқа дейін қысқарды және ағынмен «бірінші сөз» 400 мс-те пайда болды.
2-жағдай - Тым көп ресурстар, қате басымдық. Қолдау көрсетуші PDF саясаты мен ескі билет жазбаларына бірдей мән берді; Модель кейде қызметкердің екі жыл бұрынғы дұрыс емес рейтингін ресми ереже ретінде көрсетті. Хабарламаға source_tour метадеректері және "қақтығыс болған жағдайда ресми саясатты қарастыру" нұсқауы қосылғанда, жалған басымдықты қателер 89%-ға азайды.
3-жағдай – ескірген индекс. HR көмекшісі 3 ай бойы жаңартылмаған индекспен жұмыс істеді; Демалыс саясаты өзгерді, бірақ көмекші ескі күндерді айтты. Өзгертілген файлдарды анықтайтын күнделікті жаңарту орнатылғанда, ағымдағы жауап беру жылдамдығы 70%-дан 99%-ға дейін өсті.
Жалпы қателер
- Индекстеу және сұрау жолдарын араластыру: пайдаланушы күткен кезде ауыр өңдеу орындалады; кідіріс жарылады.
- Метадеректерге бастапқы түрін қоймау: басымдылық пен сүзгілеу жоқ; Сенімсіз дереккөз ресми болып көрінеді.
- Жаңарту стратегиясын орнатпау: Индекс ескіреді; Ағымдағы болып көрінетін қате жауаптар шығарылады.
- Ағынды өткізіп жіберу: пайдаланушы бос экранға қарайды; Қабылданатын кідіріс жоғары болады.
- Әр қадамда ең үлкен үлгіні пайдалану: Құны қажетсіз өседі; Рульді кішірек үлгіге қалдырыңыз.
Қысқаша айтқанда
- Корпоративтік RAG көмекшісі екі бөлек жолдан тұрады: желіден тыс индекстеу және онлайн сұрау; оларды физикалық түрде ажыратыңыз.
- Индекстеу = қосқыш + қалыпқа келтіру + бөлік/метадеректер + ендіру/жүктеп салу; сұрау = алдын ала өңдеу + іздеу + шақыру + генерация + кейінгі процесс.
- Көп бастапқы деректер бір репозиторийге біріктірілген, бірақ бастапқы_түрінің метадеректері мен сенім басымдылығы сақталады.
- Ағын және кешіктіруге арналған кэш, контекстті шектеу және құны үшін үлгі таңдау маңызды.
- Қайта индекстеусіз индекс ескіреді; Құжаттарды өзгертуді жүйелі түрде қайта өңдеңіз.
Қолданбалы тапсырма
Өз тобыңыздың көмекшісінің архитектуралық схемасын сызыңыз. (1) Кемінде үш нақты деректер көзін анықтаңыз және әрқайсысы үшін қосқыш қажеттілігін, жаңарту жиілігін және сенім деңгейін жазып алыңыз. (2) Көрсеткі диаграммасы арқылы индекстеу және сұрау жолдарын бөлек сызыңыз. (3) «Осы көмекшіде кідіріс пен шығынды қайдан азайтамын?» Сұраққа кем дегенде екі нақты шешім жазыңыз. (4) Жаңарту стратегияңызды бір сөйлеммен сипаттаңыз: қай ресурс қайта индекстеледі және қаншалықты жиі?
бақылау парағы
- [ ] Мен индекстеу және сұрау жолдарын бөлек және дұрыс құрамдастармен сала аламын.
- [ ] Мен көп дереккөзді деректерді source_type және сенім басымдылығымен біріктіре аламын.
- [ ] Мен кідіріс бойынша ағындық/кэш шешімдерін және құны бойынша үлгі таңдауды қабылдай аламын.
- [ ] Мен қайта индекстеу стратегиясының неліктен маңызды екенін білемін.
- [ ] Менің архитектурадағы ең қымбат қадам әдетте үлкенірек үлгіге баратын таңбалауыш екенін есте ұстаймын.