Problem: köməkçi yaddaşdan cavab verir

Şirkət daxili siyasətlər üçün köməkçi qurur. Məzuniyyət qaydası soruşulanda köməkçi səlis, amma yanlış cavab verir, çünki model cari sənədi görməyib və boşluğu inandırıcı görünən mətnlə doldurur. Fine-tuning uyğun gəlmir: sənədlər həftəlik dəyişir, giriş qaydaları işçiyə görə fərqlənir və cavabın haradan gəldiyini göstərmək lazımdır.

Retrieval-augmented generation (RAG) işi iki yerə bölərək bunu həll edir. Sisteminiz öz məlumatından uyğun mətni tapır, onu promptun içinə qoyur və modeldən yalnız həmin mətnə əsaslanıb cavab verməsini istəyir. Dil bacarığını model verir, faktları sizin məlumatınız.

Pipeline

 ingest (oflayn)                      query (onlayn)
 ---------------                      --------------
 sənədlər                             istifadəçi sualı
    |                                      |
 parse + təmizləmə                  avtorizasiya + yenidən yazma
    |                                      |
 chunk  -> metadata              namizədlərin tapılması
    |                              (açar söz + vektor)
 embed  -> index  <------------------------+
                                           |
                                   rerank / filtr
                                           |
                                  prompt + mənbələrin qurulması
                                           |
                                  LLM -> cavab + istinadlar
                                           |
                                    validasiya + log

Ingest tərəfinə məlumat pipeline-ı, query tərəfinə isə gecikməsi və uğursuzluq rejimləri olan servis kimi yanaşın. Modelin təhlükəsiz çağırılması backend servisdən LLM-i çağırmaq məqaləsində izah olunur.

Chunking

Modellər və indekslər bütöv fayllarla yox, parçalarla işləyir. Chunk sərhədləri nəyin tapıla biləcəyini müəyyən edir.

  • Əvvəl struktura (başlıqlar, bölmələr, siyahı elementləri), sonra ölçüyə görə bölün. Chunk tək başına mənalı olmalıdır.
  • Cümlələr kontekstdən asılıdırsa, qonşu chunk-lar arasında müəyyən üst-üstə düşmə (overlap) saxlayın.
  • Hər chunk ilə metadata saxlayın: sənəd id-si, başlıq, bölmə yolu, versiya, dil, giriş qrupu, son yenilənmə.
  • Çox kiçik olsa, məna itir; çox böyük olsa, lazım olan cümlə seyrəlir və giriş baha olur. Universal ölçü yoxdur; qiymətləndirmə dəstinizlə tənzimləyin.

Embedding və retrieval

Embedding modeli mətni vektora çevirir ki, oxşar mənalı mətnlər yaxın vektorlar versin. Sorğu zamanı sualı embed edir və ən yaxın chunk vektorlarını axtarırsınız. Saxlama üçün bir neçə seçim var: ayrıca vektor database və ya artıq işlətdiyiniz database-də vektor genişlənməsi, məsələn PostgreSQL-də. Orta miqyas üçün tanış database çox vaxt qazanır, çünki filtrləri, transaction-ları və artıq bildiyiniz əməliyyatı birləşdirir.

SELECT id, doc_id, section, contentFROM chunkWHERE access_group = ANY (:groups)   -- əvvəl avtorizasiya  AND language = :langORDER BY embedding <=> :query_vector  -- məsafə operatoruLIMIT 8;

Operatorların adı genişlənmədən asılıdır; əsas fikir odur ki, filtr sorğunun hissəsidir. Əvvəlcə tapıb sonra filtrləməyin və oxumaq hüququ olmayan istifadəçi üçün məhdud mətni promptun içinə qoymayın.

Təmiz vektor axtarışı dəqiq identifikatorları (xəta kodları, məhsul adları, maddə nömrələri) qaçıra bilir. Açar söz (full-text) və vektor nəticələrini birləşdirən, sonra merge və ya rerank edən hibrid retrieval çox vaxt daha davamlıdır.

Grounding və istinadlar

Modelə nömrələnmiş mənbələr verin və ondan yalnız onlara əsaslanmağı, mənbə nömrələrini göstərməyi və mənbələrdə cavab olmayanda bunu deməyi xahiş edin. Sonra kodda yoxlayın: istinadlar həqiqətən verdiyiniz mənbələrə aid olmalıdır, istinadsız cavab isə "tapılmadı" kimi göstərilə bilər. answer, citations[] və confidence kimi sahələri olan cavab formatı hər hansı strukturlu çıxış kimi yoxlanıla bilər.

İstinadlar istifadəçiyə iddiaları yoxlamağa imkan verir və sizə debug izi qoyur. Onlar düzgünlüyü sübut etmir, çünki model öz cümləsini dəstəkləməyən parçaya istinad edə bilər, ona görə nümunə götürüb baxın.

Aktuallıq və həyat dövrü

Sənədlər dəyişir və köhnəlmiş cavab cavabsızlıqdan pisdir.

  • Hər sənəd üçün məzmun hash-i saxlayın; yalnız dəyişənləri yenidən ingest edin.
  • Silinmələri idarə edin: chunk-ları və vektorları silin, keşləri etibarsız edin (keşləmə strategiyaları).
  • Embedding modelini versiyalayın. Fərqli modellərin vektorları müqayisə oluna bilməz, model dəyişikliyi hər şeyin yenidən embed olunması deməkdir, ideal halda yeni indeksə və sonra keçidlə.
  • Vacib olanda cavabda sənəd tarixini göstərin.

Qiymətləndirmə: retrieval və cavabı ayrıca ölçün

"Pis cavabların" çoxu retrieval uğursuzluğudur. Real suallardan və onlara cavab verməli sənədlərdən kiçik, versiyalanmış dəst qurun.

  1. Retrieval: hər sual üçün düzgün chunk ilk nəticələrdədirmi? Sadə hit rate-i zamanla izləyin.
  2. Cavab: cavab verilmiş mənbələrlə dəstəklənir, düzgün istinad edir və uyğun heç nə olmayanda imtina edirmi?
  3. Reqressiya: chunking, embedding modeli, prompt və ya sıralama dəyişəndə yenidən işə salın.

Məlumatda cavabı olmayan suallar da əlavə edin; həmişə cavab verən sistem təhlükəlidir.

Açar söz axtarışının kifayət etdiyi hallar

İstifadəçilər tanış adlar, kodlar və ifadələr axtarırsa və sənədlər yaxşı adlandırılıbsa, yaxşı sıralaması olan full-text indeks daha az xərc və mürəkkəblikl ehtiyacı ödəyə bilər. İndeks əsasları SQL indekslərinin izahında var. İnsanlar sualları sənədlərdən fərqli ifadə edəndə, sinonimlər və ya dillər arasında embedding-ə keçin. Ağlabatan yol: açar söz retrieval və qiymətləndirmə dəsti ilə başlayın, sonra vektor əlavə edib yaxşılaşma fərz etmək əvəzinə nəticələri müqayisə edin.

Təhlükəsizlik

Tapılan sənədlər etibarsız girişdir: saxlanılmış səhifə modelə yönəlmiş təlimat daşıya bilər. LLM inteqrasiyası məqaləsindəki kimi məhdudlaşdırma tətbiq edin, sənəd səviyyəli icazələri retrieval zamanı tətbiq edin (API təhlükəsizliyi və OWASP siyahısı) və köməkçiyə funksiyanın tələb etdiyindən artıq alət verməyin.

Sorğunun özünü də emal etmək faydalı ola bilər. Söhbət tarixçəsindən asılı qısa sual ("bəs ikincisi?") müstəqil sorğuya çevrilməlidir, əks halda retrieval nə axtaracağını bilmir. Bunu ayrıca addım kimi saxlayın, nəticəsini loglayın və qiymətləndirmə dəstinə daxil edin. Beləliklə, pis cavabın səbəbini sualın yenidən yazılmasında, axtarışda, yoxsa generasiyada axtarmaq asanlaşır.

Tez-tez edilən səhvlər

  • Sabit simvol sayı ilə bölüb cədvəlləri və cümlələri ortadan kəsmək.
  • Metadata-nı atlayıb sonra filtrləyə, istinad edə və silə bilməmək.
  • Giriş nəzarətini retrieval-dan sonraya saxlamaq.
  • Heç vaxt yenidən ingest etməmək, nəticədə cavabların reallıqdan uzaqlaşması.
  • Keyfiyyəti bir neçə təsirli demo sualı ilə qiymətləndirmək.
  • Prompta çoxlu chunk doldurmaq; uyğun olmayan mətn həm cavabı, həm xərci pisləşdirir.

Kompromislər

Daha çox kontekst tutumu artırır, amma xərci, gecikməni və diqqət dağınıqlığını da artırır. Rerank dəqiqliyi yaxşılaşdırır, amma əlavə addım gətirir. Ayrıca vektor database müstəqil miqyaslanır, amma əməliyyat və sinxronizasiya işi əlavə edir. Aqressiv keşləmə cavabları sürətləndirir, amma açarlar istifadəçi icazələrini nəzərə almırsa, köhnə və ya icazəsiz məzmun göstərə bilər.

Yoxlama siyahısı

  • Chunk-lar strukturu izləyir və metadata daşıyır.
  • Avtorizasiya filtri retrieval sorğusunun hissəsidir.
  • Əvvəl hibrid və ya açar söz baza xətti ölçülüb.
  • Cavablar verilmiş mənbələrə istinad edir və "tapılmadı" deyə bilir.
  • Yenidən ingest, silmə və embedding versiyalanması həll olunub.
  • Qiymətləndirmə dəsti retrieval və cavabı, cavabsız sualları da əhatə edir.

Növbəti addımlar