LLM-First sau Code-First? Unde aparține inteligența în AI de producție

Cum să decizi ce ar trebui să gestioneze modelul, ce ar trebui să gestioneze codul tău și cum să le conectezi pe amândouă.

Acum câțiva ani, arhitectura unei aplicații AI arăta astfel: trimiți un prompt unui model de limbaj mare -> primești un răspuns -> îl afișezi utilizatorului. Acela nu mai este întregul tablou în zilele de azi. Modelele sunt solicitate să interpreteze intenția, să recupereze informații, să aleagă instrumente, să invoce API-uri, să facă planuri și să execute fluxuri de lucru cu mai mulți pași.

Această schimbare a divizat domeniul în două – LLM-First sau Code-First

Într-o arhitectură LLM-first, modelul este în centru și decide ce se întâmplă în continuare. Citește cererea, alege un instrument, stabilește ordinea operațiunilor, verifică rezultatele intermediare și își schimbă cursul când este necesar.

Într-o arhitectură code-first, software-ul/codul rămâne responsabil de secvențiere, reguli de business, validare, permisiuni și execuție. LLM-ul aici este ca un specialist pe care codul îl apelează când este nevoie de înțelegere sau generare de limbaj.

Oamenii adoră să discute despre care este mai bun. Eu cred că acesta este argumentul greșit. Întrebarea mai bună este unde aparține fiecare tip de inteligență. Cele mai puternice sisteme de producție pe care le-am văzut rar sunt pur și simplu una dintre ele. Ele combină raționamentul probabilistic cu controlul determinist și fac acest lucru în mod deliberat.

De ce LLM-First este atât de atrăgător

Software-ul tradițional funcționează perfect când poți defini clar cerințele. De exemplu, un utilizator alege un produs, introduce o sumă și trimite o plată. Definiți stările permise, regulile de validare, condițiile de eroare și secvența tranzacției în cod. Gata.

Limbajul natural nu cooperează așa. Imaginează-ți un utilizator tastând: “Găsește tranzacțiile care par neobișnuite, explică ce s-a întâmplat și spune-mi ce ar trebui să investighez mai întâi.”

Nu există un traseu fix prin această cerere. Sistemul trebuie să decidă ce înseamnă „neobișnuit”, să stabilească ce date sunt relevante, poate să invoce mai multe instrumente, să evalueze răspunsul și să scrie o explicație pe care o poate folosi o persoană. Nicio echipă de ingineri/niciun cod nu va anticipa fiecare formulare și fiecare combinație de solicitări în prealabil.

Aici un LLM joacă un rol vital, acționând ca un strat flexibil de raționament între limbajul uman și serviciile tale deterministe. De asemenea, este motivul pentru care agenții atrag atât de multă atenție. ghidul de arhitectură AI agentică al Google Cloud descrie un agent ca o aplicație în care un model AI acționează ca motor de raționament, în timp ce instrumentele îi permit să acceseze sisteme și date externe.

al Anthropic Construirea agenților AI eficienți ghid face o distincție la care revin în mod constant. Într-un flux de lucru, modelele și instrumentele urmează căi pe care codul tău le definește. Într-un agent, LLM-ul își dirijează propriul proces și decide cum să folosească instrumentele. Același ghid recomandă să începi cu cea mai simplă arhitectură care rezolvă problema, în loc să adaugi complexitate agentică prin reflexie. Aș sublinia acel sfat de două ori.

Limitele „Lasă modelul să decidă”

Un model poate raționa despre ce ar trebui să se întâmple. Raționamentul nu este același cu aplicarea unei reguli.

De exemplu, ia în considerare un flux de lucru financiar. Un LLM ar putea fi excelent la înțelegerea “trimite aceeași sumă pe care am trimis-o luna trecută aceluiași furnizor”. Dar ar trebui să decidă și dacă transferul este autorizat, să calculeze limitele de reglementare, să verifice deținerea contului, să înlăture o politică de securitate și să execute tranzacția?

Probabil nu. Aceste sarcini sunt deterministe, testabile, auditate și aplicabile, și exact asta este în care software-ul tradițional excelează. Riscul crește pe măsură ce modelele obțin acces la instrumente. ghidul de securitate AI generativă al OWASP semnalează autonomie excesivă ca un risc semnificativ: acordarea unui sistem bazat pe LLM mai multă funcționalitate, permisiuni sau autonomie decât necesită sarcina. Un rezultat al modelului ciudat sau manipulat este un lucru când produce text. Este mult mai grav când modelul poate acționa în lumea reală.

Nimic din acestea nu înseamnă că modelele nu ar trebui să ia niciodată acțiuni. Înseamnă că autonomia modelului trebuie să fie limitată de autoritatea deterministă.

Code-First contează în continuare

Cu AI-ul avansând atât de repede, este ușor să simți că ingineria convențională a ieșit din modă. Eu susțin contrariul. AI face ca sistemele deterministe bune să fie mai importante, nu mai puțin.

Codul este încă alegerea corectă ori de câte ori o sarcină necesită repetabilitate exactă. Autentificarea este cel mai simplu exemplu. Un model nu ar trebui să “raționeze” dacă cineva are privilegii de administrator. Aplicația ta ar trebui să interogheze un sistem autoritar de gestionare a identității și accesului. La fel este și pentru calculele financiare, verificările de drepturi, validarea datelor, constrângerile de reglementare, limitele tranzacțiilor, validarea schemei și orice lucru ireversibil. Acestea necesită contracte explicite, nu presupuneri.

Acest lucru se aliniază cu o gândire mai largă de guvernanță. NIST AI Risk Management Framework cere organizațiilor să gestioneze riscul AI pe parcursul proiectării, dezvoltării, implementării și utilizării. Partenerul său Generative AI Profile adaugă că sistemele generative pot necesita supraveghere suplimentară, documentație, revizuire și controale, în funcție de riscul implicat.

Așadar, consider util să împart fiecare decizie de proiectare în două întrebări:

Ce ar trebui să se întâmple?

și

Ce este permis să se întâmple?

Un LLM poate adesea să ajute cu primul. Sistemele deterministe ar trebui, de obicei, să se ocupe de al doilea.

Modelul Hibrid: Raționați probabilistic, executați determinist

Pentru majoritatea aplicațiilor enterprise, răspunsul practic este un hibrid. LLM-ul funcționează ca un strat de interpretare și raționare. Serviciile deterministe funcționează ca un strat de execuție și aplicare.

Iată un exemplu. Să presupunem că un asistent AI ajută dezvoltatorii să creeze medii temporare de testare API, iar un dezvoltator scrie: “Dă-mi un sandbox pentru fluxul de lucru de onboarding al clientului.”

LLM-ul poate interpreta asta, să determine care flux de lucru este probabil cel dorit, să citească documentația și să sugereze ce API-uri sunt probabil relevante. Dar crearea efectivă a mediului nu ar trebui să depindă de text generat liber. Codul poate confirma că API-urile solicitate există, să valideze contractele lor, să verifice autorizarea, să impună limitele de resurse, să genereze o configurație aprobată și să ruleze implementarea.

Împărțirea aproximativă arată astfel:

• LLM-ul: înțelege, raționează, clasifică, propune, rezumă.
• Codul: validează, autorizează, calculează, persistă, impune, execută.

Fiecare parte face ceea ce îi stă cel mai bine, și niciuna nu este solicitată să imite punctele forte ale celeilalte.

Granițele contează mai mult pe măsură ce agenții devin mai puternici

Această separare devine mai importantă pe măsură ce trecem de la asistenți la agenți. Un asistent care oferă un răspuns greșit deranjează pe cineva. Un agent cu acces de scriere în producție poate provoca un haos mult mai mare.

Remedierea nu constă neapărat în eliminarea autonomiei. Este să adăugăm autonomia treptat, menținând în același timp punctele de control explicite. ghidul Google privind sistemele multi-agent recomandă asocierea comportamentului dinamic al IA cu controale de securitate deterministe, observabilitate, autonomie clar definită și supraveghere umană pentru scenarii critice pentru afaceri.

Aprobarea umană poate fi, de asemenea, integrată în fluxul de lucru în sine, în loc să fie o plasă de siguranță informală. Microsoft’s agent framework documentation, de exemplu, suportă apeluri de instrumente care se opresc până când o persoană aprobă explicit operațiunea solicitată.

Principiul este simplu: cu cât consecințele unei acțiuni sunt mai mari, cu atât controalele deterministe din jurul ei ar trebui să fie mai puternice.

Cinci întrebări de pus înainte de a delega o sarcină unui LLM

Când decid dacă o componentă ar trebui să fie LLM-first sau code-first, trec prin următoarele:

1. Are sarcina are un singur răspuns corect din punct de vedere obiectiv? Dacă da, orientați-vă spre cod determinist. Calculul taxelor, permisiunile și validarea schemei nu ar trebui să se schimbe deoarece un model le poate interpreta diferit astăzi.
2. Implică limbaj ambiguu sau informații nestructurate? Dacă da, un LLM poate adăuga valoare reală.
3. Ce se întâmplă dacă modelul greșește? Arhitectura potrivită pentru un rezumat de întâlnire este foarte diferită de arhitectura potrivită pentru inițierea unei plăți.
4. Poate fi validată independent ieșirea? Planurile generate de LLM devin mult mai sigure când regulile deterministe pot verifica acțiunea rezultată înainte de execuție.
5. Are cu adevărat necesar un agent? Dacă cunoști deja pașii, un flux de lucru obișnuit cu câteva apeluri LLM orientate este de obicei mai simplu, mai ieftin, mai ușor de testat și de operat.

Această ultimă întrebare merită o atenție suplimentară. Agenții sunt puternici tocmai pentru că pot gestiona situații în care nu poți prezice fiecare pas. Dar dacă tu poți prezice pașii, transformarea lor într-o problemă de raționare deschisă adaugă adesea variabilitate fără a adăuga inteligență.

Fiabilitatea este o proprietate arhitecturală, nu un prompt

Multe echipe încep prin a încerca să îmbunătățească fiabilitatea aproape în totalitate prin ingineria prompturilor. Prompturile contează, dar nu pot suporta întreaga sarcină.

Un sistem de producție ar trebui să presupună că ieșirea modelului va fi uneori incompletă, defectuoasă, neașteptată sau pur și simplu greșită. OWASP Top 10 pentru aplicații LLM enumeră riscuri precum injectarea de prompt și gestionarea incorectă a ieșirii, ceea ce consolidează un obicei esențial: tratarea ieșirii modelului ca intrare neîncredere pentru sistemele din aval, nu ca instrucțiuni de rulare automată.

Acest lucru schimbă întrebarea pe care o pui. În loc de \”Cum să scriu un prompt care să facă modelul să urmeze regula întotdeauna?\”, întreabă \”Cum să proiectez sistemul astfel încât regula să nu poată fi încălcată chiar și când modelul face o greșeală?\”

Este o problemă de arhitectură software, nu o problemă de promptare. Un prompt poate spune unui agent să nu efectueze o acțiune neautorizată. Un serviciu de autorizare poate opri efectiv această acțiune. Cele două controale nu sunt echivalente.

Dincolo de dezbatere: Sisteme orientate pe intenție

Reflectând la toate acestea, am ajuns să cred că dezbaterea LLM-first versus code-first indică o a treia idee: orientat pe intenție arhitectură.

Într-un sistem orientat pe intenție, aplicația începe prin a înțelege ce încearcă utilizatorul să realizeze. Acolo este unde un LLM este cel mai valoros, deoarece oamenii rareori sunt preciși în privința a ceea ce își doresc. De acolo, sistemul convertește treptat acea ambiguitate în operații structurate și deterministe.

O cerere precum \”Ajută-mă să rezolv problema de plată a clientului\” ar putea deveni un flux de lucru: înțelege intenția, recuperează tranzacția, identifică motivul eșecului, recomandă o soluție, solicită aprobare, execută operația aprobată.

Unele dintre aceste etape beneficiază de raționamentul modelului lingvistic. Altele ar trebui să fie servicii fixe. Arhitectura nu este definită de cine \”câștigă\”, AI sau codul. Este definită de locul în care incertitudinea este acceptabilă.

Concluzia

Pe măsură ce modelele evoluează, va fi tentant să le oferim control asupra unor părți din stivă din ce în ce mai mari. Uneori aceasta va fi decizia corectă. În alte sisteme, cel mai sofisticat design va fi cel care oferă în mod deliberat modelului mai puțină autoritate.

Ingineria AI în producție, în final, constă în plasarea inteligenței la limita potrivită. Folosiți modele lingvistice acolo unde interpretarea, raționamentul, sinteza și adaptarea creează valoare. Folosiți software determinist acolo unde consistența, autorizarea, precizia și aplicarea regulilor contează. Apoi conectați-le prin interfețe înguste, observabile și bine testate.

Viitorul AI pentru întreprinderi probabil nu este pur LLM-first sau pur code-first. Este LLM acolo unde incertitudinea cere inteligență și cod acolo unde certitudinea cere control.

Această distincție poate conta mult mai mult decât modelul pe care îl alegeți.