RAG ar agentas? Kaip pasirinkti architektūrą savo užduočiai
RAG ar agentas — kurią LLM architektūrą rinktis?
Klauskite ne apie technologiją, o apie rezultatą: jei rezultatas yra atsakymas iš Jūsų žinių — dokumentų, sutarčių, procedūrų — teisingas pasirinkimas yra RAG. Jei rezultatas yra atliktas darbas Jūsų sistemose — sukurti įrašai, išsiųsti dokumentai, atnaujintos būsenos — reikia agento. Brandžiose sistemose jie jungiami: agentas naudoja RAG kaip žinių įrankį, bet sluoksniai projektuojami ir testuojami atskirai.
Kodėl šis klausimas apskritai kyla?
Nes iš išorės abu atrodo vienodai: langas, į kurį rašote, ir sistema, kuri protingai atsako. Skirtumas paaiškėja tik paklausus, kas atsitinka po atsakymo. RAG sistemoje — nieko: žmogus perskaitė ir pats sprendžia toliau. Agentinėje — atsakymas yra tarpinis žingsnis link veiksmo, kurį sistema atliks pati.
Šis skirtumas lemia viską: architektūrą, saugumo reikalavimus, diegimo trukmę ir kainą. Todėl pirkti „AI sprendimą“ neišsiaiškinus, kuris iš dviejų reikalingas, reiškia arba permokėti už nereikalingą sudėtingumą, arba gauti sistemą, kuri kalba, bet nedirba.
Kur RAG laimi, ir kur jo lubos?
RAG stiprybė — atsekamumas ir žemas rizikos profilis. Sistema nieko nekeičia Jūsų aplinkoje, tik atsako, ir kiekvieną atsakymą galima susieti su šaltiniu — o tai vienintelis būdas pagauti klaidą anksčiau nei ji paplinta. Diegimas matuojamas savaitėmis, ir jau pirmą mėnesį matyti, ar žmonės sistema naudojasi.
Lubos irgi aiškios. Pirma — RAG kokybę lemia ne modelis, o duomenų paruošimas: kaip dokumentai supjaustyti į gabalus, kas išmesta kaip pasenę, ar paieška randa tą ištrauką, kuri atsako į klausimą. Šis darbas nematomas pristatymuose ir sudaro didžiąją projekto dalį. Antra — RAG nieko nedaro. Jei procesas reikalauja veiksmo, RAG jį tik aprašys.
Praktinis testas: surinkite dvidešimt tikrų klausimų, į kuriuos sistema turės atsakyti, ir pažiūrėkite, ar atsakymai yra Jūsų dokumentuose. Jei taip — RAG suveiks. Jei atsakymui reikia sujungti tris sistemas ir kažką jose pakeisti — skaitykite toliau.
Ką agentas prideda ir ko pareikalauja mainais?
Agentas prideda veiksmą: įrankių sluoksnį, per kurį sistema skaito ir keičia duomenis, ir būsenos valdymą, kad kelių žingsnių užduotis nesugriūtų pusiaukelėje. Apie tai, kaip ši architektūra atrodo ir kur ji lūžta, rašėme atskirai — agentinės LLM sistemos versle.
Mainais agentas pareikalauja to, ko RAG nereikalauja: patikros taškų prieš negrįžtamus veiksmus, teisių projektavimo — ką sistema gali daryti, kieno vardu ir su kokiu pėdsaku — ir rimtesnio testavimo, nes klaidos kaina jau ne neteisingas sakinys, o neteisingas įrašas Jūsų CRM. Todėl sąžininga seka dažnai yra pradėti nuo RAG, o agentą statyti tada, kai žinių sluoksnis jau veikia ir pasitikėjimas juo išmatuotas.
Kaip nuspręsti per vieną susitikimą?
Trys klausimai, kurie išsprendžia daugumą atvejų:
- Koks rezultatas? Atsakymas žmogui — RAG. Įvykdytas veiksmas sistemose — agentas.
- Kokia klaidos kaina? Neteisingas atsakymas, kurį žmogus dar peržiūrės — RAG rizika, valdoma šaltiniais. Neteisingas veiksmas, kuris jau įvyko — agento rizika, valdoma patikros taškais. Jei patikros taškų projektuoti nesinori, agentą statyti dar anksti.
- Ar žinios paruoštos? Jei dokumentacija išsibarsčiusi ir pasenusi, nei RAG, nei agentas jos neišgelbės — pirmas darbas yra žinių tvarkymas, ir jis pigesnis už bet kurią architektūrą.
Dažni klausimai
Nežinote, kuri architektūra Jūsų atvejui?
Atsineškite užduotį į nemokamą 30 minučių pokalbį — išeisite su atsakymu, kuris sluoksnis reikalingas ir nuo ko pradėti.
Kaip vyksta pirmas pokalbis →