Nagpadala ka ng RAG system. Gumagana ito... karamihan. Minsan ang mga sagot ay kahanga-hangang mabuti. Minsan ay may kumpiyansa itong nagsasaad ng isang bagay na ganap na mali, na binabanggit ang isang dokumento na hindi nagsasabi kung ano ang sinasabi ng modelo na sinasabi nito. At kung minsan ay nakakaligtaan nito ang sagot kahit na ang tamang dokumento ay nakalagay doon sa iyong knowledge base.
Ito ang normal na estado ng produksyon RAG system. Ang tanong ay hindi kung mayroon kang mga isyu sa kalidad — mayroon ka — ito ay kung mayroon kang isang sistematikong paraan upang mahanap at ayusin ang mga ito. Iyan ang para sa RAG retrospective: regular na pagsusuri kung saan nasira ang iyong pipeline at gumagawa ng mga naka-target na pagpapabuti sa halip na hulaan.
Bakit RAG Kailangan ng Mga System ang Kanilang Sariling Retrospective
AngRAG ay hindi isang sistema. Ito ay isang hanay ng mga bahagi, at ang kalidad ng bawat link ay tumutukoy sa panghuling output. Kapag masama ang sagot, maaaring nasaan man ang kabiguan:
- Pag-ingest: Ang mga dokumento ay na-parse nang hindi tama, ang mga tipak ay nahati sa masasamang lugar, ang metadata ay nawala
- Pagbawi: Ang query sa paghahanap ay hindi tumugma sa mga tamang dokumento, hindi nakuha ng modelo ng pag-embed ang semantic na koneksyon, ang iyong top-K ay masyadong maliit o masyadong malaki
- Pagpupulong ng konteksto: Ang mga nakuhang tipak ay indibidwal na may kaugnayan ngunit magkasalungat sa isa't isa, o ang window ng konteksto ay napuno ng ingay
- Pagbuo: Nag-hallucinate ang modelo sa kabila ng magandang konteksto, o binalewala nito ang nauugnay na konteksto pabor sa parametric na kaalaman nito
Ang karaniwang software na retrospective ay hindi nilagyan upang lutasin ang mga failure mode na ito. Kailangan mo ng isang format na sumusubaybay sa masasamang output pabalik sa pipeline upang mahanap ang aktwal na punto ng pagkabigo. Kung hindi, hahantong ka sa "pag-aayos" ng pagkuha kapag ang tunay na problema ay chunking, o muling pagsulat ng mga prompt kapag ang tunay na problema ay pagkuha.
Mga Sukatan na Karapat-dapat sa Pagsubaybay
Bago magpatakbo ng RAG retrospective, kailangan mo ng data. Hindi lahat ng posibleng sukatan — sapat lang para ma-diagnose ang pinakakaraniwang mga failure mode.
Retrieval Quality
Precision@K: Sa mga K na dokumentong nakuha, ilan ang aktwal na nauugnay? Kung ibinabalik mo ang 10 piraso at 2 lang ang kapaki-pakinabang, binabaha mo ang window ng konteksto ng ingay.
Recall@K: Sa lahat ng may-katuturang dokumento sa iyong knowledge base, ilan ang napunta sa iyong top-K na mga resulta? Ang mababang recall ay nangangahulugan na ang mga tamang sagot ay umiiral ngunit ang iyong pagkuha ay hindi mahanap ang mga ito.
MRR (Mean Reciprocal Rank): Saan lumalabas ang unang nauugnay na resulta sa iyong ranggo? Kung ang pinakamahusay na dokumento ay pare-pareho sa posisyon 5 sa halip na posisyon 1, ang iyong ranggo ay kailangang gumana kahit na ang pagpapabalik ay maayos.
Hindi mo kailangang kalkulahin ang mga ito sa iyong buong base ng kaalaman. Halimbawa ng 50-100 kamakailang mga query, magkaroon ng hukom ng tao na may kaugnayan sa pagkuha ng mga dokumento, at kalkulahin mula doon. Gawin ito buwan-buwan.
Kalidad ng Pagbuo
Katapatan: Talaga bang ipinapakita ng nabuong sagot kung ano ang sinasabi ng mga nakuhang dokumento? Ito ang tanong ng hallucination. Maaari mong makita-check ito sa pamamagitan ng paghahambing ng mga output laban sa kontekstong ibinigay.
Kaugnayan ng sagot: Talagang sinasagot ba ng tugon ang tanong na itinanong? Posibleng makabuo ng ganap na tapat na buod ng mga nakuhang dokumento na ganap na nakakaligtaan ang layunin ng user.
Paggamit ng konteksto: Kapag ang tamang impormasyon ay nasa nakuhang konteksto, ginagamit ba talaga ito ng modelo? Kung palagi kang kumukuha ng magagandang dokumento at binabalewala ng modelo ang mga ito, ito ay isang generation-side na problema (karaniwan ay isang nag-uudyok na isyu).
Mga Sukatan sa Pagpapatakbo
Latency: Gaano katagal ang buong pipeline mula sa query hanggang sa tugon? Hatiin ito ayon sa bahagi para malaman mo kung ang pagkuha o henerasyon ang bottleneck.
Cost per query: Subaybayan ang paggamit ng token at mga gastos sa API. Ang ilang mga pagpapahusay sa kalidad (tulad ng pagpapalawak ng window ng konteksto o muling pagraranggo) ay makabuluhang nagpapataas ng gastos.
Pagpapatakbo ng Retrospective
Paghahanda (Bago ang Pulong)
Magtalaga ng isang tao upang maghanda ng "sample ng pagkabigo" — 10-15 kamakailang mga query kung saan mali ang output o hindi magandang kalidad. Para sa bawat isa, kunin ang buong pipeline state: ang orihinal na query, kung ano ang nakuha, anong konteksto ang ipinadala sa modelo, at kung ano ang nabuo ng modelo. Ang bakas na ito ay mahalaga. Kung wala ito, nagde-debug ka nang bulag.
Ihanda din ang iyong mga trend ng sukatan. Bubuti ba o lumalala ang mga bagay mula noong huling retro? Anumang matalim na pagbabago?
Ang Pulong (60 minuto)
Pagsusuri ng sukatan (10 minuto). Maglakad sa mga sukatan ng pagkuha at pagbuo. Tumutok sa mga uso at sorpresa, hindi isang numero-by-number na pagbigkas. Ang "Precision@5 ay bumaba mula 0.72 hanggang 0.58 ngayong buwan" ay kapaki-pakinabang. Ang pagbabasa ng bawat sukatan mula sa isang dashboard ay hindi.
Pagsusuri ng pagkabigo (35 minuto). Ito ang core ng retro. Kunin ang sample ng failure at uriin ang bawat isa sa kung saan nasira ang pipeline:
- Pagkabigo sa pagkuha: Ang mga tamang dokumento ay hindi nakuha. Bakit? Query-document mismatch? Pag-embed ng limitasyon ng modelo? Masyadong agresibo ang pag-filter ng metadata?
- Chunking failure: Nakuha ang tamang dokumento, ngunit hinati ng mga hangganan ng tipak ang sagot sa dalawang tipak at isa lang ang naibalik. O ang chunk ay masyadong malaki at diluted na may hindi nauugnay na nilalaman.
- Pagkabigo ng konteksto: Nakuha ang magagandang tipak, ngunit nawala ang mahalagang impormasyon sa window ng pag-order o truncation ng konteksto. O kaya'y nilito ng mga magkasalungat na tipak ang modelo.
- Pagkabigo sa henerasyon: Nagbigay ng magandang konteksto, ngunit nag-hallucinate pa rin ang modelo, binalewala ang konteksto, o nagbigay ng hindi malinaw na sagot sa halip na ang partikular na isa na available sa mga dokumento.
Para sa bawat pagkabigo, tanungin ang: "Ano ang pinakamurang pag-aayos na makakahuli o makakapigil dito?" Minsan ito ay isang agarang pag-aayos. Minsan ito ay muling pag-chun ng isang partikular na dokumento. Minsan ito ay isang sistematikong pagbabago.
Pag-priyoridad at mga item sa pagkilos (15 minuto). Pagsama-samahin ang mga pagkabigo ayon sa ugat na dahilan. Ang pattern na nagdulot ng pinakamaraming pagkabigo ay nakakakuha ng higit na pansin. Pumili ng 2-3 pagpapahusay na ipapatupad bago ang susunod na retro.
Mga Karaniwang Pattern ng Pagkabigo at Pag-aayos
Narito ang mga pattern na pinakamadalas mong makikita at praktikal na diskarte sa bawat isa:
"Ang tamang dokumento ay nasa aming base ng kaalaman ngunit nakakaligtaan ito ng pagkuha." Ito ay karaniwang isang problema sa pagkakatulad sa pag-embed. Ang query ng user ay gumagamit ng ibang bokabularyo kaysa sa source na dokumento. Mga pag-aayos: magdagdag ng hakbang sa pagpapalawak ng query (muling isulat ang query ng user sa maraming parirala), ipatupad ang hybrid na paghahanap (pagsamahin ang mga semantic embedding na may pagtutugma ng keyword tulad ng BM25), o pagbutihin ang iyong pag-filter ng metadata upang paliitin ang espasyo sa paghahanap.
"Kinukuha namin ang tamang dokumento ngunit ang maling bahagi." Ang iyong diskarte sa pag-chunking ay higit na mahalaga kaysa sa napagtanto ng karamihan sa mga koponan. Kung gumagamit ka ng fixed-size na chunking (hal., 500 token), halos tiyak na hinahati mo ang mahalagang content sa mga hangganan. Pag-aayos: gumamit ng semantic chunking (hati batay sa mga pagbabago sa paksa), magdagdag ng chunk overlap, subukan ang hierarchical chunking kung saan ang mas malalaking parent chunks ay nagbibigay ng konteksto para sa mas maliliit na child chunks.
"Hindi pinapansin ng modelo ang magandang konteksto at gumagawa ng mga bagay-bagay." Isa itong isyu sa pag-udyok at pag-uugali ng modelo. Ang parametric na kaalaman ng modelo ay sumasalungat sa ibinigay na konteksto, at ang parametric na kaalaman ay nananalo. Mga pag-aayos: isaayos ang prompt ng iyong system upang tahasang turuan ang modelo na gumamit lamang ng ibinigay na konteksto, magdagdag ng pagtuturo na "kung ang konteksto ay hindi naglalaman ng sagot, sabihin mo," isaalang-alang ang pagbabawas ng temperatura ng modelo.
"Tama ang mga sagot ngunit masyadong mabagal." Ang mga problema sa latency ay karaniwang nagmumula sa isa sa tatlong lugar: masyadong maraming mga retrieval call, masyadong malaki ang window ng konteksto (mas maraming token = mas mabagal na henerasyon), o mga hakbang sa muling pagraranggo na nagdaragdag ng oras ng pagproseso. I-profile ang iyong bahagi ng pipeline ayon sa bahagi. Ang pag-aayos ay depende sa kung saan pupunta ang oras.
"Hindi pare-pareho ang kalidad — mahusay para sa ilang paksa, kakila-kilabot para sa iba." Karaniwan itong nangangahulugan na ang ilang bahagi ng iyong base ng kaalaman ay mas mahusay na na-index kaysa sa iba. Maaaring ang ilang mga dokumento ay na-parse nang hindi maganda, o ang ilang mga paksa ay walang sapat na saklaw. I-map ang iyong mga pagkabigo ayon sa lugar ng paksa at makikita mo ang mga puwang.
Pagbuo ng Patuloy na Pagpapabuti ng Loop
Tinatrato ng mga pinakaepektibong RAG team ang kanilang system bilang isang produkto, hindi isang proyekto. Ito ay hindi kailanman "tapos." Ang bawat retrospective ay dapat gumawa ng mga incremental na pagpapabuti, at ang mga pagpapahusay na iyon ay dapat na masusukat sa susunod na retro.
Isang praktikal na ritmo:
- Lingguhan: Mabilis na pagsusuri ng mga automated na sukatan ng kalidad (maaaring async, tingnan lang ang dashboard)
- Bi-weekly o buwanan: Buong retrospective na may failure analysis
- Kada apat na buwan: Mas malalaking desisyon sa arkitektura — dapat ba nating baguhin ang mga modelo ng pag-embed, muling isaayos ang ating base ng kaalaman, magpatibay ng bagong diskarte sa chunking?
Panatilihin ang isang gumaganang dokumento ng kung ano ang iyong sinubukan at kung ano ang epekto nito. Ang RAG optimization ay umuulit at nonlinear — minsan ay babalikan mo ang mga diskarte na hindi gumana dati dahil ang natitirang bahagi ng pipeline ay nagbago nang sapat na ang mga ito ay gumagana ngayon.
Iwasan ang Makintab na Bagay na Trap
Linggu-linggo ay may bagong papel o balangkas na nagsasabing malutas ang RAG na kalidad. Labanan ang pagnanais na i-rearchitect ang iyong pipeline batay sa isang post sa blog. Sa halip, gamitin ang iyong retrospective data upang matukoy ang iyong aktwal na pinakamalaking problema sa kalidad, at lutasin ang partikular na problemang iyon. Marahil ang sagot ay isang magarbong bagong re-ranking model. Mas malamang, inaayos nito kung paano mo i-chunk ang iyong dokumentasyon ng produkto.
Ang mga koponan na pinakamabilis na umunlad ay hindi ang mga gumagamit ng pinaka sopistikadong arkitektura. Sila ang may pinakamahigpit na feedback loop sa pagitan ng "masama ang output na ito" at "eto ang partikular na dahilan, at narito ang binago namin."
Subukan ang NextRetro libre — Ikategorya ang RAG mga pattern ng pagkabigo na may mga column at bumoto kung aling mga pagpapahusay ng pipeline ang uunahin.
Huling Na-update: Pebrero 2026
Oras ng Pagbasa: 7 minuto
