Retrieval-augmented generation sistemi altındakı data platforması qədər yaxşıdır. Ona tam dəqiqlikdə xam sənədlər, süzmək üçün metadata, retrieval qatına çatan təsnifat və mənbələr dəyişdikcə aktual qalan indeks lazımdır. Lakehouse bu dördünü bir idarə olunan nüsxə üzərində verir; ikiqatlı lake-warehouse mühiti isə heç birini təmiz vermir.

Bütün arqument budur, məqalənin qalanı isə onun arxasındakı mühəndislik detalıdır.

RAG ümumiyyətlə niyə data platformasından asılıdır?

Çünki retrieval AI etiketi geymiş data problemidir. Model sistemdəki ən az fərqləndirici komponentdir — eyni model hamıya əlçatandır. İşləyən assistentlə uydurma cavab verən assistenti fərqləndirən oxumaq üçün ona nə verildiyidir.

Bu, dörd platforma xüsusiyyətini həlledici edir.

Dəqiqlik. Retrieval mənbə məzmunu üzərində işləyir: müqavilələr, prosedurlar, tapşırıqlar, yazışmalar, transkriptlər və tam dənəvərlikdə qeydlər. Kurasiya olunmuş warehouse cədvəli cavabı əsaslandıran detalı artıq atıb.

Süzülə bilən metadata. Effektiv retrieval nadir hallarda sırf oxşarlıq axtarışıdır. O, metadata ilə məhdudlaşdırılmış oxşarlıq axtarışıdır — bu departament, bu sənəd növü, yalnız cari versiya, bu müştəri seqmenti. Həmin metadata mövcud olmalı və məzmuna bağlanmalıdır.

Retrieval qatının oxuya bildiyi təsnifat. Konkret istifadəçiyə nə göstərilə biləcəyi mənbə aktivinin necə təsnifləndiyindən asılıdır. Təsnifat yalnız siyasət sənədində varsa, retrieval qatı heç nə tətbiq edə bilmir.

Təzəlik. Cari kimi çəkilən qüvvədən düşmüş prosedur inamlı səhv cavab doğurur — bu isə cavabsızlıqdan pisdir.

İkiqatlı mühit dördündə də uduzur: xam qatda dəqiqlik var, governance yoxdur; warehouse-da governance var, dəqiqlik yoxdur; heç birində isə retrieval qatının istehlak edə biləcəyi təsnifat yoxdur. Bu, ümumən müəssisələri lakehouse arxitekturasına aparan eyni struktur arqumentdir — sadəcə AI yükü ilə kəskinləşmiş halda.

Embedding-lər harada yaşamalıdır?

Üç işlək şablon var və seçimin real nəticələri var.

Ayrıca vektor bazası. Miqyasda təxmini ən yaxın qonşu axtarışı üçün xüsusi qurulub, indeksləşdirməsi yetkindir. Qiyməti işlədilməli, qorunmalı və idarə olunmalı daha bir sistem, həmçinin törəmə şəxsi məlumatın yaşadığı ikinci yerdir.

Lakehouse-un içində vektor axtarışı. Embedding-lər məzmunun yanında sütun kimi, eyni table format-da, eyni giriş nəzarəti və lineage altında saxlanılır. Əməliyyat baxımından sadə və governance baxımından ardıcıldır; çox böyük miqyasda sırf axtarış performansında tarixən zəif olub, amma fərq xeyli daralıb.

Hibrid. Məzmun və metadata sistem qeydi kimi lakehouse-da, embedding-lər isə istənilən anda yenidən qurula bilən törəmə indeks kimi vektor anbarına köçürülür.

Yukon Labs ən çox hibridi qurur və bunun konkret bir səbəbi var: vektor indeksinə səlahiyyətli yox, törəmə kimi baxmaq yenidən embedding etməyi adi işə çevirir. Embedding modelləri yaxşılaşır, chunking strategiyaları dəyişir; bütöv korpusunu miqrasiya layihəsi olmadan yenidən embedding edə bilməyən sistem isə ilk dizaynında donmuş sistemdir.

Hansı şablon seçilsə də, bir qayda güzəştsizdir: embedding modeli və vektor anbarı mənbə sənədləri ilə eyni tərəfdə dayanır. Şəxsi məlumat olan sənəddən çıxarılan vektor embedding özü də törəmə şəxsi məlumatdır — bu arqument Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsində açılıb. Sənədləri hostlanan embedding xidmətinə göndərmək saxlanma vədlərindən asılı olmayaraq sərhədlərarası ötürmədir.

Giriş nəzarəti retrieval qatına necə çatır?

Demonu istehsalat sistemindən ayıran sual budur və korporativ RAG layihələrinin çoxu məhz burada dayanır.

Sadəlövh tətbiq hər şeyi bir vektor anbarına indeksləyir və hər istifadəçi üçün onu axtarır. Bu, assistent görməməli adama maaş rəqəmini, intizam qeydini və ya müştəri məlumatını ilk dəfə göstərənə qədər işləyir — model fayl yolunu sitat gətirmək əvəzinə məzmunu öz sözləri ilə dediyi üçün bu ifşanı fayl paylaşımındakı səhv konfiqurasiyadan çətin aşkarlamaq olur.

Birlikdə işlədilən üç mexanizm:

Sorğu vaxtı təsnifat və səlahiyyət üzrə süzün. Hər chunk öz mənbə aktivinin təsnifat və giriş atributlarını daşıyır. Retrieval istifadəçinin səlahiyyətlərinə görə oxşarlıq sıralamasından sonra yox, əvvəl süzür. Sıralamadan sonra süzmək geniş yayılmış qısayoldur və məhdud istifadəçilərə doğru nəticələr yerinə sadəcə daha az nəticə qaytarır.

İndeksləri həssaslıq pilləsinə görə bölün. Ciddi məhdudlaşdırılmış məzmun əksər istifadəçi sorğularının heç vaxt toxunmadığı ayrıca indeksdə. Bu, partlayış radiusunu məhdudlaşdırır və audit hekayəsini sadələşdirir.

Data qatında da tətbiq edin. Assistent sənəd yox, strukturlu data sorğulayanda sorğu mühərrikindəki sətir və sütun səviyyəli siyasət işə düşür. Starburst-dakı federativ giriş nəzarətinin AI dövründəki konkret faydası budur: analitikin SQL-ini idarə edən eyni siyasət agentin sorğusunu da idarə edir, sinxron saxlanmalı ikinci siyasət mühərriki olmadan. Mexanikası Starburst və Trino Azərbaycanda məqaləsindədir.

Hər üçünün söykəndiyi atributlar catalog-dan gəlir. İdarə olunmayan mühitlərdə AI layihələrinin məhz bu nöqtədə dayanmasının səbəbi budur: «bu istifadəçi nə görə bilər» sualının qeyd olunmuş cavabı yoxdur, minlərlə aktiv üzrə onu geriyə doğru cavablandırmaq isə sprint yox, governance proqramıdır.

Retrieval üçün ingestion pipeline-ı necə görünür?

Altı mərhələ və hər birində cavab keyfiyyətinə ciddi təsir edən qərar var.

Çıxarış. Sənədlərdən mətnə, quruluşu qoruyaraq. Başlıqlar, cədvəllər və siyahılar məna daşıyır; cədvəli davamlı cümləyə çevirən çıxarıcı ən çox soruşulacaq məzmunu məhv edir. Skan edilmiş sənədlərə OCR lazımdır, OCR keyfiyyəti isə aşağıdakı hər şeyin tavanını qoyur.

Chunking. Məzmunun çəkilə bilən vahidlərə bölünməsi. Sabit ölçülü chunking sadədir və semantik sərhədləri kəsir; bölmə və bəndlərə hörmət edən struktur yönümlü chunking müəssisələrin real saxladığı sənəd tiplərində — müqavilələr, prosedurlar, qaydalar — daha yaxşı işləyir. Chunk-lar arasında örtüşmə sərhəd itkilərini azaldır, əvəzində indeks ölçüsünü artırır.

Metadata bağlanması. Hər chunk mənbə sənədini, bölməni, versiyanı, qüvvəyəminmə tarixini, sahibi, təsnifatı və dili daşıyır. Komandaların atladığı mərhələ budur; atlamaq isə sonradan süzməyi, aktuallıq qaydalarını və istinadı mümkünsüz edir.

Embedding. Mətndən vektora. Model seçimi qeyri-ingilis məzmun üçün komandaların gözlədiyindən çox əhəmiyyət daşıyır — Azərbaycan dili ümumi təyinatlı embedding modellərində ingilis və ya rus dilindən qat-qat az təmsil olunur; retrieval keyfiyyətini güman etmək yerinə dil üzrə yoxlamağın praktiki səbəbi də budur.

İndeksləmə. Metadata süzülə bilən atribut kimi vektor anbarına yazılır.

Qeydiyyat. Bu aktivin artıq retrieval əhatəsində olduğunun catalog-da qeyd edilməsi. Bu addım olmadan assistentin nə görə bildiyini heç kim deyə bilmir — istənilən baxışdakı ilk sual isə elə budur.

İndeksi necə aktual saxlamaq olar?

Ən çətin əməliyyat tələbi və ən çox korpus böyüdükcə dözülməz olan tam gecə yenidən qurma ilə həll edilən tələb.

Mənbədə dəyişikliyin aşkarlanması. Sənədlər üçün fayl dəyişiklik hadisələri və ya qrafikli skan. Strukturlu data üçün analitik platformanın işlətdiyi eyni CDC mexanizmi — real vaxt analitikası: streaming, CDC və lakehouse məqaləsində açılıb.

Artımlı yenidən embedding. Yalnız dəyişmiş məzmun yenidən embedding olunur. Bu, sabit chunk kimliyini, o isə deterministik chunking-i tələb edir — sonradan geydirilməsi bahalı olan dizayn qərarı.

Yayılan silmə. Mənbə sənədi silinəndə onun chunk-ları və embedding-ləri də silinməlidir. Bu, həm keyfiyyət, həm hüquqi tələbdir: arxasında embedding qoyan silinmə sorğusu yerinə yetirilməyib.

Versiyanın birinci dərəcəli məsələ kimi idarəsi. Qüvvədən düşmüş sənədlər ya indeksdən çıxmalı, ya da retrieval-ın süzdüyü qüvvəyəminmə tarixi atributu daşımalıdır. Korporativ tətbiqlərdə ən çox rast gəlinən səhv cavab kateqoriyasının — iki il əvvəl əvəzlənmiş siyasəti inamla sitat gətirməyin — qarşısını məhz bu bir nəzarət alır.

Lakehouse bunu niyə mümkün edir?

Beş xüsusiyyət, hər biri əks halda ayrıca inteqrasiya layihəsidir.

Bir idarə olunan nüsxə. Məzmun və strukturlu data eyni giriş nəzarəti və təsnifat altındadır, ona görə retrieval əhatəsi ifadə oluna bilir.

Açıq table format-lar zamanda geri baxış verir. Sistemin konkret tarixdə nə çəkəcəyini təkrar istehsal etmək mümkündür — keçmiş nəticəni audit zamanı izah edərkən bu vacibdir və tələb birbaşa ISO/IEC 42001 məqaləsində görünür.

Metadata və məzmun birlikdə qalır, ona görə chunk səviyyəli atributlar vektor anbarında qapanmır, sorğulana bilir.

Eyni mühərrik həm analitiklərə, həm agentlərə xidmət edir. «Ötən rübdə kredit həcmi nə qədər idi» sualına cavab verən agent sorğu icra edir və bunu analitikin qarşılaşdığı eyni siyasət altında edir.

Lineage AI yolunu da əhatə edir. Hansı mənbələr hansı indeksi qidalandırır və deməli, mənbə dəyişəndə hansı hesabatlar və hansı assistentlər təsirlənir.

Bunların platformanın bütövünə necə oturduğu müasir data platforması qurmaq məqaləsindədir.

On-premise-də bu necə görünür?

Buradakı banklar və dövlət qurumları üçün hər komponent perimetrin içində işləyir: obyekt anbarı, table format, sorğu mühərriki, embedding modeli, vektor indeksi və inferens.

Tətbiqlərdən iki praktiki qeyd.

Embedding inferensdən ucuzdur və korpus miqyasında asanlıqla az qiymətləndirilir. Böyük sənəd mühitini embedding etmək ciddi birdəfəlik batch işidir, model dəyişəndən sonra yenidən embedding isə onu təkrarlayır. Sabit sorğu yükünə görə yox, buna görə ölçün və onu istənilən digər batch yükü kimi qrafikə salın.

Darboğaz model ölçüsü yox, retrieval keyfiyyətidir. Cavablar məyus edəndə komandalar daha böyük modelə əl atır, real defekt isə demək olar həmişə chunking, əskik metadata və ya köhnəlmiş məzmundur. GPU ölçülməsi və xərc mühakiməsi LLM-lərin on-premise tətbiqi, retrieval keyfiyyəti arqumenti isə korporativ AI-da kontekst niyə vacibdir məqaləsindədir.

Əsas məqamlar

  • Retrieval keyfiyyəti data platformasının xüsusiyyətidir. Model sistemdəki ən az fərqləndirici komponentdir.
  • RAG sisteminə dəqiqlik, süzülə bilən metadata, oxuna bilən təsnifat və təzəlik lazımdır. İkiqatlı mühit heç birini təmiz vermir.
  • Vektor indeksinə səlahiyyətli yox, törəmə kimi baxın ki, yenidən embedding layihə yox, adi iş olsun.
  • Embedding modelini və vektor anbarını mənbə sənədləri ilə eyni tərəfdə saxlayın.
  • Oxşarlıq sıralamasından əvvəl səlahiyyət üzrə süzün, indeksləri həssaslığa görə bölün və strukturlu sorğular üçün siyasəti data qatında tətbiq edin.
  • Metadata-nı chunking mərhələsində bağlayın — versiya, qüvvəyəminmə tarixi, sahib, təsnifat, dil. Sonradan əlavə etmək praktiki deyil.
  • Silmə və əvəzlənmiş versiyaları açıq idarə edin; cari kimi çəkilən köhnə sənədlər ən çox rast gəlinən səhv cavab kateqoriyasıdır.
  • Retrieval keyfiyyətini dil üzrə yoxlayın. Azərbaycan dili ümumi təyinatlı embedding modellərində nəzərəçarpacaq dərəcədə az təmsil olunur.

Yukon Labs retrieval qatını idarə olunan lakehouse bünövrəsi üzərində qurur — federativ sorğu və ardıcıl giriş nəzarəti üçün Starburst, retrieval qatının oxuduğu təsnifat üçün OvalEdge, onların üzərində orchestration qatı kimi isə HAVAA. Arxitektura fonu üçün data lakehouse arxitekturası məqaləsinə baxın.