RAG peržiūrėtas

RAG. RAG. RAG.

Lenktynėse dėl dirbtinio intelekto diegimo verslo procesuose ir produktuose pastebima nerimą kelianti tendencija: „Retrieval-Augmented Generation“ (RAG) manija. Nors RAG – metodas, kuris sujungia didelius kalbos modelius (LLM) su išorinių žinių gavimu – neabejotinai atvėrė naujas sąveikos su žiniomis galimybes, per daug praktikų su juo kovoja.

Atėjo laikas pertvarkyti pokalbį apie AI įgyvendinimą, pripažinti per didelio pasitikėjimo RAG spąstus ir ištirti alternatyvius metodus, kurie gali būti tinkamesni, ekonomiškesni ir elegantiškesni.

RAG manija: perteklius daugeliu atvejų

RAG tapo įprasta technika daugeliui AI inžinierių, norinčių pagerinti kalbos modelių tikslumą pateikdami išorinį kontekstą. Prielaida pakankamai paprasta: įkeldamos didžiulį teksto kiekį į vektorių saugyklas, šios AI sistemos gali ieškoti atitinkamų dokumentų, nuskaityti duomenis ir sujungti juos su kalbos modelio generaciniais gebėjimais, kad gautų tikslesnius atsakymus.

Tačiau entuziazmas dėl RAG privedė prie įdiegimų, kurie pervertina jo naudingumą, sprogimą. Neretai pastebima, kad inžinieriai išmeta milijonus dokumentų į vektorines saugyklas, padidina saugojimo debesyje ir apdorojimo išlaidas, nesuprasdami, ar naudojimo atvejis netgi reikalauja tokio sudėtingumo. Daugelis neapmąsto, ar gali pakakti paprastesnio sprendimo, ar RAG iš viso reikalinga konkrečiai jų problemai.

Naivių RAG įgyvendinimo spąstai

Dar blogiau, kad dauguma inžinierių į RAG diegimą žiūri naiviai, neatsižvelgdami į ilgalaikes išlaidas ir priežiūros naštą. Jie mano, kad įkėlus kiekvieną teksto fragmentą į vektorių parduotuvę, dirbtinis intelektas kažkaip taps protingesnis. Tačiau dažniausiai ši praktika veikia priešingai. Kadangi vektorinės parduotuvės yra pripildytos perteklinių ir nereikalingų dokumentų, LLM yra priblokšti išgauti duomenis, kurie nesukuria pridėtinės vertės. Tai lemia lėtesnį atsako laiką, didesnes išlaidas ir ne tokius efektyvius sprendimus.

RAG geriausiai veikia, kai jis naudojamas tikslioms ir aktualioms žinioms pagilinti, o ne tada, kai jis naudojamas kaip bet kokio galimo dokumentų išmetimo priemonė. Dėl perdėto projektavimo per RAG taip pat nepakankamai išnaudojamos kitos pagrindinės AI galimybės ir per daug dėmesio skiriama paieškai, kai daug problemų būtų galima išspręsti naudojant paprastesnę logiką ir struktūrą.

Ne kiekvienai problemai reikia RAG

Štai tiesa: ne visais atvejais reikalinga RAG sąranka. Jei užduotis siaura ir tiksliai apibrėžta, pvz., atsakymas į DUK, klientų palaikymo užklausas ar struktūrinis dialogas, gali pakakti paprastos paieškos lentelės arba žinių diagramos. Nereikia patirti papildomų išlaidų, susijusių su didžiulės vektorių saugyklos ir kelių milijonų parametrų modelio paleidimu, kai sprendimas gali būti sukurtas naudojant taisyklėmis pagrįstą sistemą ar net agento sistemą.

Noras naudoti RAG kyla iš minties, kad daugiau duomenų reiškia geresnį našumą. Tačiau daugeliu atvejų kokybė nugali kiekybę. Tiksliai sureguliuotas modelis su tikslinėmis žiniomis arba net žiniomis pagrįstas pokalbių robotas su taisyklėmis pagrįstomis galimybėmis gali veikti geriau, nepaliečiant RAG dujotiekio. Sprendimą įgyvendinti RAG turėtų lemti užduoties sudėtingumas, o ne jos populiarumas tarp AI entuziastų.

Mažų agentų, turinčių siaurų žinių, atvejis

Alternatyva išpūstoms RAG sistemoms dažnai yra elegantiškesnė ir efektyvesnė: maži specializuoti agentai, turintys ribotas, bet tikslias žinias. Šios priemonės, naudojamos kartu, gali pranokti vieną didelį modelį, kuriam tenka terabaitų teksto našta. Kiekvienas agentas gali būti sukurtas taip, kad tvarkytų konkrečias darbo eigos dalis arba atsakytų į tam tikros rūšies užklausas, todėl galima naudoti modulines ir lanksčias AI sistemas. Tai ne tik sumažina išlaidas, bet ir palengvina visos sistemos priežiūrą bei mastelį.

Įsivaizduokite scenarijų, kai vienas agentas yra atsakingas už planavimą, kitas už apibendrinimą, o trečias už žiniatinklio paieškas. Kiekvienas iš šių agentų gali dirbti kartu, panaudodamas tik jiems reikalingas žinias, be monolitinės sistemos išlaidų. Įdiegę daug mažų modelių ar logika pagrįstų agentų, įmonės gali gauti tikslesnius ir greitesnius rezultatus, tuo pačiu žymiai sumažindamos apdorojimo ir saugojimo išlaidas.

Per didelis LLM naudojimas: kada tiks paprasta logika

Galiausiai, yra per didelis LLM naudojimas scenarijuose, kur tiktų paprasta logika. LLM nepaprastai gerai supranta ir kuria natūralią kalbą, tačiau tai nereiškia, kad jie turėtų pakeisti visas automatizavimo formas. Daugelį užduočių, pvz., duomenų patvirtinimą, formų pildymą ar struktūrinių ataskaitų generavimą, galima atlikti greičiau ir patikimiau naudojant pagrindinius scenarijus, taisyklių variklius arba deterministines sistemas.

Puikus pavyzdys yra LLM naudojimas atliekant aritmetinę užduotį arba rūšiavimo problemą. Tai neefektyvu ir nereikalinga. Tai ne tik eikvoja skaičiavimo išteklius, bet ir padidina klaidų tikimybę tais atvejais, kai paprasta funkcija ar algoritmas būtų tikslesni. Noras įgyvendinti LLM viskam virto „LLM plaktuko ieškant nagų“ sindromu. Šis netinkamas naudojimas sukelia išpūstus lūkesčius ir galiausiai nusivylimą, kai modeliai neatlieka taip, kaip tikėtasi, atliekant užduotis, kurioms jie nebuvo skirti.

AI inžinerijos permąstymas

Atėjo laikas permąstyti AI inžineriją ir pereiti nuo mados. RAG turi savo vietą įrankių rinkinyje, bet tai nėra panacėja. Ateitis priklauso nuo tinkamų modelių diegimo tinkamoms užduotims atlikti – kartais tai reiškia RAG, bet dažnai ne. Turėdami niuansų supratimą apie AI galimybes, inžinieriai gali sukurti efektyvesnes, efektyvesnes ir lengviau prižiūrimas sistemas.

Apie mane: daugiau nei 20 metų veteranas, derinantis duomenis, AI, rizikos valdymą, strategiją ir švietimą. 4x hakatono nugalėtojas ir socialinis duomenų gynėjo poveikis. Šiuo metu dirbama siekiant paskatinti dirbtinio intelekto darbuotojus Filipinuose. Sužinokite daugiau apie mane čia: https://docligot.com