Agentic retrieval: kai DI paieška pati suskaido painų klausimą
·
agentic retrieval iš pirmo žvilgsnio skamba kaip dar viena DI naujiena. Bet man čia įdomiausias labai žemiškas klausimas: ką žmogui ar komandai reikės daryti kitaip jau šią savaitę?
AWS aprašė agentic retrieval Amazon Bedrock Managed Knowledge Base aplinkoje. Paprastai tariant, DI paieška ne tik ieško pagal vieną sakinį, bet pati suskaido painų klausimą į kelias dalis.
Atvirai? DI naujienų dabar tiek, kad smegenys kartais nori paspausti „unsubscribe“ visam internetui. Bet kai žiūri ne į triukšmą, o į darbą, kai kurios temos lieka ant stalo.
KAS NUTIKO
Straipsnyje aiškinama, kodėl klasikinė retrieval paieška stringa su kelių dalių klausimais ir kaip AgenticRetrieveStream API leidžia agentui planuoti paieškos veiksmus, sekti eigą ir grąžinti tikslesnį kontekstą atsakymui.
Įmonių dokumentai retai atsako į klausimą vienoje vietoje. Vienas gabalas sutartyje. Kitas politikoje. Trečias seno susitikimo protokole. Žmogus tai suklijuoja galvoje. DI turi išmokti daryti panašiai.
KODĖL TAI SVARBU
Agentic retrieval svarbus todėl, kad geras atsakymas dažnai prasideda nuo geros paieškos. Jei agentas atsineša blogą kontekstą, net stiprus modelis tik gražiai aprašys klaidą.
DI jau seniai nebėra vien tekstų generatorius. Jis jungiasi prie dokumentų, duomenų bazių, sveikatos įrašų, klientų kanalų, prekybos sistemų ir vidinių procesų. O ten klaidos kainuoja daugiau nei vienas negražus sakinys.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia, kad žinių bazės kokybė tampa DI projekto širdimi. Neužtenka sumesti PDF į vieną vietą. Reikia galvoti, kaip klausimai bus skaidomi, kokie šaltiniai tikrinami ir kaip rodoma, iš kur atsakymas paimtas.
- testuoti kelių dalių klausimus
- reikalauti šaltinių prie atsakymo
- atskirti dokumentų paiešką nuo galutinio samprotavimo
- sekti, kuri paieškos dalis dažniausiai nepavyksta
Paimkite klausimą, kuris reikalauja trijų šaltinių, pavyzdžiui: ar klientui galima taikyti nuolaidą pagal sutartį, regioną ir mokėjimo istoriją. Toks testas greitai parodo, ar paieška realiai protinga.
KUR PASISLĖPUSI RIZIKA
Rizika – pasitikėti gražiu atsakymu be šaltinių. Jei agentas neparodo, ką rado ir ko nerado, vadovas lieka su maloniu tekstu ir neaiškia rizika.
Blogiausia DI klaida dažnai ateina gražiai. Ramiai. Su mandagiu tonu ir pasitikėjimu savimi. Todėl čia reikia ne tik entuziazmo, bet ir tikrinimo įpročio.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Susikurkite 20 sudėtingų klausimų rinkinį iš savo įmonės dokumentų. Tai bus geresnis testas už bet kokį demo.
Šaltinis: Amazon Web Services.
DUK
Kas yra agentic retrieval?
Tai paieškos būdas, kai agentas pats suskaido klausimą, planuoja paieškos veiksmus ir renka kontekstą atsakymui.
Kuo tai skiriasi nuo įprasto RAG?
Įprastas RAG dažnai ieško vienu užklausos pjūviu, o agentinis metodas gali daryti kelis paieškos žingsnius.
Kur tai naudinga?
Įmonių žinių bazėse, sutartyse, politikose, techniniuose dokumentuose ir klientų aptarnavimo procesuose.
Jei norite DI naudoti praktiškai, pradėkite nuo vieno proceso, ne nuo visos įmonės pertvarkymo. Susirašykite, kur dingsta laikas, kur atsiranda klaidos ir kur žmogaus peržiūra būtina. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
