Bago ilunsad ang RAG chatbot, sukatin nang hiwalay ang retrieval at sagot

Oktubre 11, 2026 nang 02:00 PM|May-akda: QUASA Editorial Team|6 minutong pagbasa| 1

Para malaman kung handa nang ilunsad ang isang RAG chatbot, bumuo ng test set na maaaring ulitin at sukatin nang hiwalay ang retrieval at kalidad ng sagot. Inihihiwalay ng gabay ng Microsoft sa RAG evaluators ang pagsusuri sa mga nakuhang dokumento mula sa groundedness, relevance at completeness ng huling tugon.

Patakbuhin ang parehong mga tanong sa kasalukuyan at iminungkahing bersyon. Tingnan muna kung nakuha ang impormasyong kailangan, saka kung ginamit ito nang tama sa sagot. Kung wala ang mahalagang passage sa naibigay na konteksto, retrieval ang unang sisiyasatin; kung naroon ito ngunit mali o kulang pa rin ang sagot, siyasatin ang prompt at generator.

Bumuo ng test set na may mapagkakatiwalaang batayan

Ang bawat test case ay dapat may tanong, inaasahang sagot at batayang makikita sa corpus. Kumuha ng mga tanong mula sa totoong gamit ng chatbot: paghahanap ng isang patakaran, pagsasama ng impormasyon mula sa magkakaibang dokumento, at tanong na walang sapat na mapagkukunan upang sagutin. Kung Filipino at English ang ginagamit ng mga empleyado o customer, isama ang karaniwang anyo ng tanong sa parehong wika.

Sa pinakamaliit na kapaki-pakinabang na rekord, ilagay ang query ID, tanong, reference answer, mahahalagang puntong dapat masaklaw, at mga ID ng sumusuportang dokumento o passage. Markahan din kung inaasahan ang pagtanggi sa pagsagot dahil kulang ang ebidensya. Para sa bawat run, itago ang aktuwal na sagot, nilalaman at pagkakasunod ng mga nakuha na chunk, pati bersyon ng corpus, retriever settings, prompt at modelo. Kung score lamang ang naiwan, mahirap balikan kung aling passage ang nawala o kung anong pagbabago ang nakaapekto sa resulta.

Ipaberipika sa taong may pananagutan sa nilalaman ang reference answer at mga label ng passage. Maaaring lumang patakaran ang nasa test set kahit bago na ang nasa corpus; sa gayong kaso, ang reference ang kailangang itama bago husgahan ang sistema. Magtabi rin ng mga test case na hindi paulit-ulit na ginagamit sa pagpili ng chunk size, ranking o prompt, upang may hiwalay na batayan para sa desisyon sa release.

Sukatin kung nakuha at nauna ang tamang konteksto

Dalawang magkaibang tanong ang dapat sagutin sa retrieval: nakuha ba ang impormasyong kailangan, at gaano kataas sa resulta ang mga kapaki-pakinabang na chunk? Sa tutorial ng MongoDB sa RAG evaluation, ginagamit ang context precision at context recall para sa retrieval, faithfulness at answer relevance para sa generation, at hiwalay na paghahambing para sa kabuuang application.

Ang context precision ay tumutulong makita kung nauuna ang mga may kaugnayang chunk kaysa sa mga hindi gaanong kapaki-pakinabang. Mahalaga ito kapag limitado ang kontekstong maipapasa sa generator: maaaring nakuha ang tamang dokumento ngunit hindi umabot sa bahaging aktuwal na ipinasa. Ang context recall ay tumitingin naman kung gaano karami sa kailangang impormasyon ang nasama sa mga nakuha na resulta.

Kailangan ng ihahambing na batayan para sa recall. Ayon sa depinisyon ng Ragas sa context recall, maaaring hatiin ang reference answer sa mga pahayag at suriin kung sinusuportahan ang bawat isa ng retrieved context; maaari ring ihambing ang mga ID ng nakuha at inaasahang passage. Magkaiba ang dalawang paraang iyon, kaya itala kung alin ang ginamit sa bawat paghahambing.

Kapag mababa ang recall, alamin muna kung nasa corpus ang nawawalang impormasyon. Kung naroon, siyasatin ang indexing, chunk boundaries, access filters at dami ng kinukuhang resulta. Kung nakuha ang tamang passage ngunit natabunan ng hindi kaugnay na resulta, mas makabuluhang tingnan ang ranking o reranking. Ang mismong listahan ng mga chunk ang magpapakita ng pagkakaibang hindi kayang ipaliwanag ng isang average score.

Suriin ang sagot laban sa kontekstong talagang naibigay

Sa pagsusuri ng generation, gamitin ang tanong, eksaktong kontekstong natanggap ng generator, aktuwal na sagot at reference answer. Tinutukoy ng groundedness o faithfulness kung may pahayag sa sagot na hindi sinusuportahan ng konteksto. Tinutukoy ng relevance kung tumutugon ang sagot sa tanong. Ang completeness naman ay tumitingin kung naisama ang mahahalagang puntong nasa inaasahang sagot; ang Response Completeness evaluator ng Microsoft ay nakatala bilang preview.

Maaaring grounded ang isang sagot ngunit kulang pa rin: halimbawa, binanggit nito ang patakaran ngunit iniwan ang kondisyon kung kailan ito naaangkop. Maaari ring mukhang kumpleto ang sagot ngunit may idinagdag na detalye na wala sa mga nakuha na passage. Para sa test case na walang sapat na batayan, suriin kung malinaw na ipinahahayag ng chatbot ang kakulangan ng impormasyon sa halip na magbigay ng tiyak ngunit walang suportang sagot.

Kung automated evaluator ang nagbibigay ng marka, balikan ang mga kasong mababa ang score at ang paliwanag sa marka. Ipasuri sa taong may kaalaman sa dokumento ang mga sagot na may malaking epekto sa patakaran o proseso, gayundin ang mga kasong salungat ang marka sa nakikitang ebidensya. Ang ganitong pagsusuri ay nagbibigay ng mas matibay na batayan sa pag-aayos kaysa sa paghabol lamang sa mas mataas na aggregate score.

Itugma ang pagkabigo sa bahaging dapat siyasatin

Mababa ang context recall: hanapin ang nawawalang source at siyasatin ang saklaw ng corpus, indexing, chunking, filters at dami ng kinukuhang resulta.
Nakuha ang tamang source ngunit mababa ang context precision: tingnan ang pagkakasunod ng mga resulta, laki ng chunk at ranking o reranking.
Kumpleto ang naibigay na konteksto ngunit mababa ang groundedness: ihambing ang bawat problemadong pahayag sa passage na nakita ng generator, saka siyasatin ang prompt at modelo.
May batayan at may kaugnayan ang sagot ngunit kulang: tukuyin ang iniwang punto sa reference answer at alamin kung hindi ito ginamit ng generator o hindi pala naisama sa konteksto.

Mga direksiyon ito sa pag-iimbestiga, hindi awtomatikong hatol sa isang bahagi ng sistema. Halimbawa, maaaring lumitaw na problema sa completeness ang isang nawawalang kondisyon, ngunit retrieval ang sanhi kung wala talaga ito sa naipasa na context. Sa kabilang banda, kung naroon ang kondisyon at hindi pa rin nabanggit, mas makabuluhang subukan ang pagbabago sa prompt o modelo habang nakapirmi ang retrieval.

Gamitin ang buong daloy bilang release check

Pagkatapos ng pag-aayos sa retrieval o generation, patakbuhin muli ang daloy mula tanong hanggang huling sagot sa nakapirming test set. Ihambing ang bawat metric at ang mahahalagang test case sa dating bersyon, kasama ang corpus, prompt, modelo at retrieval settings na ginamit. Maaaring umangat ang retrieval score habang lumalala ang isang sagot, kaya kailangan pa ring suriin ang end-to-end na resulta.

Sa release checklist, isama ang mga tanong na nangangailangan ng maraming passage, mga tanong na walang sapat na source, at mga sagot na may malaking epekto sa aktuwal na gawain. Itakda ng team ang katanggap-tanggap na resulta batay sa panganib ng gamit at sa sarili nitong baseline; walang iisang score threshold na angkop sa lahat ng RAG application. Kapag may kritikal na sagot na walang batayan o may iniwang mahalagang kondisyon, itala ang test case, ayusin ang bahaging tinukoy ng ebidensya at ulitin ang regression test bago ilunsad.

Basahin din:

I-share: