const tools = [
{
type: "function",
function: {
name: "query_sales_db",
description: "Interoghează baza de date de vânzări pentru rapoarte financiare.",
parameters: {
type: "object",
properties: {
startDate: { type: "string", description: "Format YYYY-MM-DD" },
category: { type: "string", enum: ["it", "auto", "food"] },
limit: { type: "number", default: 100 }
},
required: ["startDate"]
}
}
}
];
// În loop-ul de chat, verifici tool_calls
if (response.choices[0].message.tool_calls) {
const call = response.choices[0].message.tool_calls[0];
const args = JSON.parse(call.function.arguments);
// Execuți query-ul real în DB-ul tău cu parametrii validați
const data = await db.sales.findMany({ where: { category: args.category, date: { gte: new Date(args.startDate) } }, take: args.limit });
// Trimite datele înapoi la OpenAI pentru sintetizarea răspunsului
}M-am lovit recent de o problemă clasică: un client voia un dashboard ultra-customizabil pentru un ERP, dar echipa de frontend era deja îngropată în tichete. Sincer, m-am săturat să tot adăugăm dropdown-uri și checkbox-uri pentru fiecare scenariu ipotetic. Așa că am decis să implementăm un agent simplu folosind Function Calling de la OpenAI. Rezultatul? Am redus timpul de generare a rapoartelor ad-hoc cu vreo 40% și am scăpat de mentenanța a zeci de endpoint-uri de filtrare.
Ideea e simplă, dar mulți o dau în bară pentru că încearcă să fie prea deștepți. Nu vrei să-i dai LLM-ului acces direct să scrie SQL pur (decât dacă vrei să te trezești cu un DROP TABLE sau cu baza blocată de un join infinit). Pattern-ul care mi-a funcționat mie implică definirea unor funcții specifice care acționează ca niște interfețe controlate între model și baza de date.
Cum funcționează de fapt
În loc să trimiți tot contextul bazei în prompt (ceea ce ar costa o avere în tokeni), îi descrii modelului o listă de tools. De exemplu, o funcție numită get_sales_data care acceptă parametri precum date_range, category sau region. Când utilizatorul întreabă „Cât am vândut pe segmentul de electronice luna trecută?”, OpenAI nu-ți dă un răspuns text imediat. Îți returnează un obiect JSON cu numele funcției și argumentele extrase din limbaj natural.
Am pățit la început să las argumentele prea libere și modelul o lua pe arătură, inventând categorii care nu existau. Soluția? Folosește enumerări (enums) în schema JSON a funcției. Dacă îi spui clar că category poate fi doar 'electronics', 'home' sau 'garden', rata de eroare scade drastic.
Trade-offs și securitate
Nimic nu e moca pe lumea asta. Primul mare risc e legat de performanță. Dacă agentul decide că are nevoie de 3 apeluri de funcții consecutive pentru a răspunde la o întrebare complexă, latența sare lejer de 5-6 secunde. Pentru un chat intern e ok, pentru un produs user-facing e la limită.
Pe partea de securitate, am aplicat o regulă de aur: user-ul de bază de date folosit de agent este strict Read-Only. Mai mult, am limitat numărul de rânduri returnate la maximum 500. Am avut un caz la un proiect cu vreo 12k înregistrări unde modelul a cerut un export masiv și a crăpat instanța de Node din cauza memoriei înainte să apuce să proceseze răspunsul.
Un alt aspect e „hallucination check”. Chiar dacă funcția returnează date goale, modelul are tendința să „înfrumusețeze” realitatea. Trebuie să-i dai instrucțiuni clare în system_message: „Dacă funcția returnează un set gol, spune clar că nu există date, nu încerca să estimezi”.
Concluzia mea
Function calling e genial pentru a transforma limbajul natural în date structurate, dar succesul stă în cât de bine îți definești interfața funcțiilor. Nu încerca să faci un agent care „știe de toate”. Mai degrabă fă 5 funcții mici și specifice decât una mamut care primește un obiect JSON gigant.
Voi cum gestionați accesul LLM-urilor la datele sensibile? Mergeți pe varianta de funcții predefinite sau riscați cu un Text-to-SQL ceva mai liber?