Vahid 5 / 11

Şirkət məlumatları ilə danışan köməkçi memarlıq

Qazanclar:

  • Müəssisə RAG köməkçisinin komponentlərinin və məlumat axınının dizaynı
  • Çox mənbəli məlumatların (wiki, bilet, PDF, verilənlər bazası) bir köməkçidə birləşdirilməsi
  • Ölçeklenebilirlik, keşləmə və gecikmə üçün memarlıq qərarları qəbul edin

Əvvəlki bölmələrdə hissələri bir-bir öyrəndik: yerləşdirmə, vektor verilənlər bazası, parçalama, axtarış. İndi gəlin bunları birləşdirək və öz şirkət məlumatlarınızla danışan köməkçinin arxitekturasını yaradaq. Məqsəd işçinin “Məzuniyyət siyasətimiz nədir?” sualını verməkdir. İnsanların sual verə biləcəyi bir sistem, cavablar real daxili sənədlərə, sitatlara əsaslanır və çoxsaylı məlumat mənbələrini birləşdirir. Bu bölmə bütün arxitektura, məlumat axını və istehsal səviyyəsində qərarları emal edir.

Başdan Uca Komponentlər

Korporativ RAG köməkçisi iki ayrı xəttdən ibarətdir. İndeksləmə xətti (oflayn) məlumatları hazırlayır; Sorğu xətti (onlayn) suala cavab verir.

İndeksləmə xətti komponentləri:

  1. Bağlayıcılar: Mənbələrdən məlumatları çəkən birləşdiricilər — wiki, bilet sistemi, fayl anbarı, verilənlər bazası, e-poçt.
  2. Normallaşdırma: Müxtəlif formatların (PDF, HTML, DOCX) təmiz mətnə ​​çevrilməsi; başlıq/altbilgi təmizləmə.
  3. Chunking + metadata: Parçalanma və etiketləmə (mənbə, tarix, səlahiyyət).
  4. Yerləşdirmə + yükləmə: Vektorlar və metadataların vektor verilənlər bazasına yazılması.

Sorğu boru kəməri komponentləri:

  1. Sorğunun əvvəlcədən işlənməsi: Yenidən yazmaq, mərkəzsizləşdirmə.
  2. Axtarış: Hibrid axtarış + metadata filtri + yenidən sıralama.
  3. Tez yaratma: Şablonda kontekst + sual + təlimatların yerləşdirilməsi.
  4. Nəsil: Model + mənbələrdən əsaslandırılmış (kontekstual) cavab.
  5. Post-processing: Sitat formatı, təhlükəsizlik yoxlanışı, giriş.
İpucu: İndeksləmə xəttini sorğu xəttindən fiziki olaraq ayırın. İndeksləmə yavaş və dövri xarakter daşıyır (bir gecədə partiyalar şəklində işləyir); Sorğu xətti yüngül və dərhal olmalıdır. İstifadəçi gözləyərkən iki xəttin qarışdırılması ağır emal etməyə məcbur edir.

Məlumat axınının vizuallaşdırılması

[INDEXING - oflayn]Resurslar → Normallaşdırın → Yığma+Metaməlumat → Yerləşdirin → Vektor DB (wiki, bilet, PDF, DB)[QUERY - onlayn]İstifadəçi sualı → Əvvəlcədən emal → Axtarış (hibrid+filtr+yenidən sıralama) → Sorğu (kontekst+sual+təlimat →İstifadəçi+təlimat)

Çox Mənbəli Məlumatların Birləşdirilməsi

Həqiqi şirkətlərdə cavab bir yerdə dayanmır. "Müştəriyə pulu necə qaytarmaq olar?" Sualın cavabını həm yardım məqaləsində (prosedurda), həm bilet tarixçəsində (real nümunələr), həm də siyasət PDF sənədində (qaydalar) tapmaq olar. Köməkçi onların hamısını bir hovuzda axtarmalıdır.

Kritik məqam: resursları bir vektor anbarında birləşdirərkən, hər bir parça “mənbə_turu” metadatasını daşımalıdır. Beləliklə, siz onların hamısını axtara və lazım gələrsə, "yalnız rəsmi siyasətləri gətirin" kimi süzgəcdən keçirə bilərsiniz. Həmçinin, müxtəlif mənbələr müxtəlif etibarlılıq səviyyələrinə malikdir: rəsmi siyasət > yardım məqaləsi > işçinin bilet qeydi. Bu prioriteti yenidən sıralamada və ya sorğuda təyin edə bilərsiniz.

Mənbə

Məzmun növü

güvən

Tezliyi yeniləyin

Siyasət pdf

rəsmi qayda

yüksək

aylıq

Kömək məqaləsi

Prosedur

orta-yüksək

həftəlik

Bilet tarixçəsi

real nümunə

orta

Davamlı

viki

Qarışıq/cari qeyd

Dəyişən

Davamlı

Ölçeklenebilirlik, Kesh və Gecikmə

İstehsalda üç məsələ önə çıxır. Gecikmə: İstifadəçi 2 saniyədən çox gözlədikdə təcrübə pisləşir. Həll yolu: cavabı axın şəklində göstərin — model yazarkən ekrana tökülür. Keş: Tez-tez verilən suallar və təkrarlanan kontekstlər üçün keş həm sürəti artırır, həm də xərcləri azaldır. Ölçek: İstifadəçi artdıqca axtarışın miqyasını və zəngləri üfüqi modelləşdirməyi bacarmaq lazımdır.

Xərc tərəfində əsas qayda: ən bahalı addım adətən daha böyük modelə gedən tokenlərin sayıdır. Buna görə də, yenidən sıralamaqla konteksti 4 yaxşı hissəyə endirmək həm keyfiyyəti, həm də dəyəri yaxşılaşdırır. Ümumi dizayn sadə təsnifat və ya marşrutlaşdırma üçün daha kiçik/sürətli modeldən və yekun cavab üçün daha güclü modeldən istifadə etməkdir (məsələn, claude-opus-4-8).

Diqqət: İndeksləşdirməni "bir dəfə et, unut" kimi qurmayın. Sənədlər dəyişdirilir, silinir, əlavə olunur. Yenidən indeksləşdirmə strategiyası qurun: dəyişdirilmiş sənədləri aşkar edin və yalnız onları yenidən emal edin. Köhnə indeks cari görünən, lakin səhv olan cavab verir.

Zəif Arxitektura / Güclü Arxitektura

Zəif (tək skript, hər şey qarışıq):

İstifadəçi soruşduqda: həmin anda sənədləri oxuyun, xırdalayın, yerləşdirin, axtarın, cavab verin.# Problem: hər bir sual üçün bütün indeksləşdirmə təkrarlanır; saniyə gecikmə, # mənbənin ayrılması, filtr yoxdur, yeniləmə yoxdur.

Güclü (split borular + metadata + keş + axın):

İndeksləmə: toplu gecə işləyir, dəyişdirilmiş sənədləri təzələyir. Sorğu: yüngül xətt — əvvəlcədən emal → hibrid axtarış+filtr → yenidən sırala → sorğu → model (axın) → sitat → qeyd. Tez-tez verilən suallar və mənbə yaddaşda saxlanılır.

Üç mini qutu

1-ci hal - Qarışıq xətt, ağır gecikmə. Başlanğıc hər sualla PDF-ləri təkrar emal edən skript yazdı; Hər cavab orta hesabla 11 saniyə çəkdi. İndeksləmə xətti ayrıldıqda və məlumatlar əvvəllər vektor anbarına köçürüldükdə, sorğu müddəti 1,3 saniyəyə qədər azaldı və axınla "ilk söz" 400 ms-də göründü.

2-ci hal - Çoxlu resurs, səhv prioritet. Dəstək köməkçisi siyasət PDF və köhnə bilet qeydlərinə bərabər əhəmiyyət verdi; Model bəzən rəsmi qayda olaraq işçinin iki il əvvəlki səhv reytinqini təqdim edirdi. Mənbə_turu metadatası və "münaqişə halında rəsmi siyasəti nəzərdən keçirin" təlimatı sorğuya əlavə edildikdə, yanlış prioritet xətalar 89% azaldı.

3-cü hal - köhnəlmiş indeks. HR köməkçisi 3 ay ərzində yenilənməmiş indekslə işləyirdi; Tətil siyasəti dəyişdi, amma köməkçi köhnə günləri deyirdi. Dəyişən faylları aşkar edən gündəlik yeniləmə quraşdırıldıqda, cari cavab nisbəti 70%-dən 99%-ə yüksəldi.

Ümumi səhvlər

  • İndeksləmə və sorğu xətlərinin qarışdırılması: İstifadəçi gözləyərkən ağır emal edilir; gecikmə partlayır.
  • Mənbə növünün metadataya qoyulmaması: Prioritetləşdirmə və filtrləmə yoxdur; Etibar olunmayan mənbə rəsmi görünür.
  • Yeniləmə strategiyası yaratmamaq: İndeks köhnəlir; Cari görünən səhv cavablar hazırlanır.
  • Yayımdan keçin: İstifadəçi boş ekrana baxır; Qəbul edilən gecikmə yüksək olur.
  • Hər addımda ən böyük modeldən istifadə: Xərclər lazımsız şəkildə artır; Sükanı daha kiçik modelə buraxın.

Xülasə

  • Korporativ RAG köməkçisi iki ayrı sətirdən ibarətdir: oflayn indeksləşdirmə və onlayn sorğu; onları fiziki cəhətdən ayırın.
  • İndeksləmə = birləşdirici + normallaşdırmaq + yığın/metadata + yerləşdirmə/yükləmə; sorğu = pre-proses + axtarış + istək + yaratmaq + sonrakı proses.
  • Çox mənbəli məlumatlar bir repozitoriyada birləşdirilir, lakin mənbə_tipi metadata və etibar prioriteti qorunur.
  • Gecikmə üçün axın və keş, kontekst tənzimləmə və qiymət üçün model seçimi vacibdir.
  • Yenidən indeksləşdirmədən indeks köhnəlir; Dəyişən sənədləri mütəmadi olaraq təkrar emal edin.

Tətbiq tapşırığı

Öz komandanız üçün köməkçinin memarlıq diaqramını çəkin. (1) Ən azı üç real məlumat mənbəyini müəyyənləşdirin və hər biri üçün birləşdirici ehtiyacını, yeniləmə tezliyini və etibar səviyyəsini yazın. (2) Qutu-ox diaqramı ilə indeksləşdirmə və sorğu sətirlərini ayrıca çəkin. (3) "Bu köməkçidə gecikmə və xərcləri harada azalda bilərəm?" Suala ən azı iki konkret qərar yazın. (4) Yeniləmə strategiyanızı bir cümlə ilə təsvir edin: hansı resurs yenidən indeksləşdiriləcək və nə qədər tez-tez?

yoxlama siyahısı

  • [ ] İndeksləmə və sorğu sətirlərini ayrı-ayrılıqda və düzgün komponentlərlə çəkə bilirəm.
  • [ ] Mən çox mənbəli məlumatları source_type və etibar prioriteti ilə birləşdirə bilirəm.
  • [ ] Mən gecikmə üçün axın/kesh qərarları və qiymətə görə model seçimi edə bilərəm.
  • [ ] Yenidən indeksləşdirmə strategiyasının niyə vacib olduğunu bilirəm.
  • [ ] Mən arxitekturamda ən bahalı addımın adətən daha böyük modelə gedən işarə olduğunu xatırlayıram.