paint-brush
RAG Revizuitde@docligot
339 lecturi
339 lecturi

RAG Revizuit

de Dominic Ligot4m2024/10/03
Read on Terminal Reader

Prea lung; A citi

Este timpul să regândim ingineria AI și să trecem dincolo de modurile. RAG își are locul în trusa de instrumente, dar nu este un panaceu.
featured image - RAG Revizuit
Dominic Ligot HackerNoon profile picture
0-item

CÂRPĂ. CÂRPĂ. CÂRPĂ.


În cursa de implementare a inteligenței artificiale în procesele și produsele de afaceri, a existat o tendință îngrijorătoare: o obsesie pentru generația de recuperare crescută (RAG). În timp ce RAG – o metodă care îmbină modele mari de limbaj (LLM) cu regăsirea cunoștințelor externe – a deschis fără îndoială noi căi de interacțiune cu cunoștințele, prea mulți practicieni se luptă cu aceasta.


Este timpul să recadram conversația despre implementarea AI, să recunoaștem capcanele dependenței excesive de RAG și să explorăm abordări alternative care pot fi mai potrivite, mai eficiente din punct de vedere al costurilor și mai elegante.

Mania RAG: Excesiune pentru multe cazuri de utilizare

RAG a devenit tehnica de bază pentru mulți ingineri AI care doresc să îmbunătățească acuratețea modelelor de limbaj prin furnizarea de context extern. Premisa este destul de simplă: prin încărcarea unor cantități mari de text în magazinele de vectori, aceste sisteme AI pot căuta documente relevante, pot prelua datele și le pot combina cu abilitățile generative ale modelului de limbaj pentru a produce răspunsuri mai precise.


Cu toate acestea, entuziasmul pentru RAG a dus la o explozie de implementări care supraestimează utilitatea acestuia. Nu este neobișnuit să vezi inginerii aruncând milioane de documente în magazinele de vectori, umflând costurile de stocare în cloud și procesare fără a înțelege dacă cazul de utilizare necesită chiar o asemenea complexitate. Mulți nu reușesc să ia în considerare dacă o soluție mai simplă ar putea fi suficientă sau dacă RAG este chiar necesar pentru problema lor specifică.

Capcanele implementărilor naive RAG

Mai rău, majoritatea inginerilor abordează implementarea RAG cu o mentalitate naivă, trecând cu vederea costurile pe termen lung și sarcinile de întreținere. Ei cred că încărcarea fiecărei bucăți de text într-un magazin de vectori va face cumva AI mai inteligentă. Dar de cele mai multe ori, această practică face opusul. Cu magazinele de vectori pline de documente redundante și inutile, LLM-urile sunt copleșite de recuperarea datelor care nu adaugă valoare. Acest lucru are ca rezultat timpi de răspuns mai lenți, costuri mai mari și soluții mai puțin eficiente.


RAG funcționează cel mai bine atunci când este folosit pentru a spori cunoștințele precise și relevante , nu atunci când este folosit ca o soluție generală pentru orice descărcare de documente disponibilă. Supraingineria prin RAG duce, de asemenea, la subutilizarea altor capabilități cheie AI și la o concentrare exagerată pe recuperare atunci când multe probleme ar putea fi rezolvate cu o logică și o structură mai simplă.

Nu orice problemă are nevoie de RAG

Iată adevărul: nu toate cazurile de utilizare necesită o configurare RAG. Dacă sarcina este restrânsă și bine definită - cum ar fi răspunsul la întrebări frecvente, întrebări de asistență pentru clienți sau angajarea într-un dialog structurat - un simplu tabel de căutare sau un grafic de cunoștințe poate fi suficient. Nu este nevoie să suportați costul general al rulării unui depozit masiv de vectori și a unui model de parametri cu mai multe milioane atunci când soluția poate fi construită folosind un sistem bazat pe reguli sau chiar un cadru de agent.


Zelul de a folosi RAG provine din ideea că mai multe date înseamnă performanță mai bună. Dar, în multe cazuri, calitatea depășește cantitatea. Un model reglat fin, cu cunoștințe vizate, sau chiar un chatbot conștient de cunoștințe, cu capabilități bazate pe reguli, poate funcționa mai bine fără a atinge vreodată o conductă RAG. Decizia de a implementa RAG ar trebui să fie dictată de complexitatea sarcinii, nu de popularitatea sa în rândul pasionaților de AI.

Cazul agenților mici cu cunoștințe înguste

Alternativa la sistemele RAG umflate este adesea mai elegantă și eficientă: agenți mici, specializați, cu cunoștințe limitate, dar precise. Acești agenți, atunci când sunt utilizați în tandem, pot depăși un singur model mare împovărat de terabytes de text. Fiecare agent poate fi proiectat să gestioneze anumite părți ale unui flux de lucru sau să răspundă la anumite tipuri de interogări, permițând sisteme AI modulare și flexibile. Acest lucru nu numai că reduce costurile, ci și face întregul sistem mai ușor de întreținut și scalat.



Imaginați-vă un scenariu în care un agent este responsabil pentru programare, altul pentru rezumat și al treilea pentru efectuarea căutărilor pe web. Fiecare dintre acești agenți poate lucra împreună, valorificând doar cunoștințele de care au nevoie, fără suprasolicitarea unui sistem monolitic. Prin implementarea multor modele mici sau agenți bazați pe logică, companiile pot obține rezultate mai precise și mai rapide, reducând în același timp semnificativ costurile de procesare și stocare.

Folosirea excesivă a LLM-urilor: când logica simplă va face

În cele din urmă, există utilizarea excesivă a LLM-urilor în scenarii în care logica simplă ar funcționa. LLM-urile sunt remarcabil de bune la înțelegerea și generarea limbajului natural, dar asta nu înseamnă că ar trebui să înlocuiască toate formele de automatizare. Multe sarcini, cum ar fi validarea datelor, completarea formularelor sau generarea de rapoarte structurate, pot fi realizate mai rapid și mai fiabil cu scripturi de bază, motoare de reguli sau sisteme deterministe.


Un prim exemplu este utilizarea unui LLM pentru o sarcină aritmetică sau o problemă de sortare. Acest lucru este ineficient și inutil. Nu numai că irosește resurse de calcul, dar crește și probabilitatea de erori în cazurile în care o funcție sau un algoritm simplu ar fi mai precis. Dorința de a implementa LLM-uri pentru orice s-a transformat într-un sindrom „ciocanul LLM în căutarea cuielor”. Această utilizare greșită duce la așteptări umflate și la o eventuală dezamăgire atunci când modelele nu funcționează conform așteptărilor în sarcini pe care nu au fost concepute pentru a le gestiona.

Regândirea ingineriei AI

Este timpul să regândim ingineria AI și să trecem dincolo de modurile. RAG își are locul în trusa de instrumente, dar nu este un panaceu. Viitorul constă în implementarea modelelor potrivite pentru sarcinile potrivite - uneori asta înseamnă RAG, dar de multe ori nu. Cu o înțelegere nuanțată a capabilităților AI, inginerii pot proiecta sisteme care sunt mai eficiente, mai eficiente și mai ușor de întreținut.


Despre mine: veteran de peste 20 de ani care combină date, AI, managementul riscurilor, strategie și educație. Câștigător de 4 ori a hackatonului și impact social de la avocatul datelor. În prezent, lucrează pentru a porni forța de muncă AI în Filipine. Aflați mai multe despre mine aici: https://docligot.com