const tools = [
{
type: "function",
function: {
name: "get_sales_by_region",
description: "Returnează totalul vânzărilor pentru o regiune specifică.",
parameters: {
type: "object",
properties: {
region: { type: "string", enum: ["Bucuresti", "Cluj", "Timisoara"] },
period: { type: "string", description: "Ex: 'last_month', 'this_year'" }
},
required: ["region"]
}
}
}
];
// În handler-ul de backend:
if (response.choices[0].message.tool_calls) {
const call = response.choices[0].message.tool_calls[0];
const args = JSON.parse(call.function.arguments);
// VALIDARE STRICTĂ înainte de DB
if (!['Bucuresti', 'Cluj', 'Timisoara'].includes(args.region)) {
throw new Error("Regiune invalidă!");
}
const data = await db.sales.findMany({ where: { city: args.region } });
// Trimitem datele înapoi la OpenAI pentru interpretare
}Acum vreo șase luni am avut un proiect pentru un dashboard de analytics unde clientul voia să întrebe „Câți useri din Cluj au cumpărat abonamente Pro luna asta?”. Prima tentativă a fost naivă: am trimis schema bazei de date în prompt și i-am zis lui GPT-4 să-mi dea SQL-ul înapoi. Rezultatul? Un dezastru total. Ba inventa coloane care nu existau, ba făcea join-uri care îmi puneau baza de date în cap la doar 5k înregistrări.
Atunci m-am prins că abordarea corectă nu e să-l lași pe LLM să fie DBA, ci să-l folosești ca pe un dispecer inteligent. Aici intervine Function Calling (sau tools în API-ul nou). În loc să-i dai acces la „țevi”, îi dai o listă de scule pe care le poate apela când are nevoie de date.
Cum funcționează schema, de fapt
Secretul stă în definiția uneltelor. Tu îi spui modelului: „Uite, am o funcție numită get_sales_report care primește un oraș și un interval de timp”. OpenAI nu execută codul tău. El doar analizează întrebarea userului și, dacă vede că se potrivește cu descrierea funcției, îți dă înapoi un obiect JSON cu argumentele extrase din text.
E un trade-off pe care mulți îl ignoră la început: latența. Dacă faci un agent care are nevoie de date din DB, ai minim două roundtrip-uri către API-ul OpenAI. Primul ca să decidă ce funcție să apeleze, al doilea ca să interpreteze datele pe care i le dai tu înapoi din DB. La un proiect cu vreo 8k useri activi, am observat că timpul de răspuns urca de la 2 secunde la vreo 5-6 secunde. E mult, dar pentru un raport complex, userul de obicei are răbdare.
Securitatea nu e opțională
Marea greșeală pe care o văd pe forumuri e încrederea oarbă în parametrii returnați de model. Dacă GPT îți zice că vrea să ruleze get_user_details(id: "123 OR 1=1"), și tu bagi asta direct într-un query, ești terminat. LLM-ul poate fi manipulat prin prompt injection să încerce să extragă mai multe date decât trebuie.
Întotdeauna, dar absolut întotdeauna, validezi argumentele primite în codul tău de backend. Eu folosesc Zod pentru asta. Dacă modelul trimite un string unde mă așteptam la un UUID, dau eroare și îi spun modelului „Invalid format”, iar el de obicei se prinde și reîncearcă corect.
Un pattern care chiar merge
Am observat că agentul devine mult mai stabil dacă îi dai funcții atomice. În loc de o funcție mamut query_database, mai bine îi dai get_customer_by_email și list_recent_orders. Astfel, reduci șansa ca modelul să o ia pe arătură.
Un alt aspect important e documentarea parametrilor în interiorul JSON-ului de definiție. Dacă nu-i explici clar ce înseamnă fiecare câmp, o să înceapă să „ghicească”. De exemplu, la un câmp de status, am scris explicit: „Statusul poate fi doar 'pending', 'shipped' sau 'cancelled'”. Din momentul ăla, rata de succes a apelurilor corecte a sărit de la 70% la peste 95%.
La final, marea întrebare rămâne: merită efortul față de un sistem clasic de filtre? Dacă ai useri non-tehnici care au nevoie de rapoarte ad-hoc, răspunsul e un „da” hotărât. Dar dacă e vorba de chestii repetitive, un UI bine gândit va bate mereu un chatbot la viteză și precizie.
Voi cum gestionați validarea datelor care vin dinspre LLM înainte să le atingeți baza de date?