import OpenAI from 'openai';
const openai = new OpenAI();
const tools = [{
type: 'function' as const,
function: {
name: 'getUserRevenue',
description: 'Returnează veniturile generate de un utilizator pe baza ID-ului său',
parameters: {
type: 'object',
properties: {
userId: { type: 'number', description: 'ID-ul unic al utilizatorului' }
},
required: ['userId']
}
}
}];
async function handleAgentQuery(userPrompt: string) {
const response = await openai.chat.completions.create({
model: 'gpt-4o-mini',
messages: [{ role: 'user', content: userPrompt }],
tools
});
const toolCall = response.choices[0].message.tool_calls?.[0];
if (toolCall && toolCall.function.name === 'getUserRevenue') {
const { userId } = JSON.parse(toolCall.function.arguments);
const dbResult = await db.query('SELECT sum(amount) FROM orders WHERE user_id = $1', [userId]);
return `Utilizatorul ${userId} a cheltuit în total ${dbResult.rows[0].sum} EUR.`;
}
return response.choices[0].message.content;
}Am pus în producție un agent simplu cu OpenAI Function Calling care trage date direct din Postgres pentru echipa de vânzări. Vă arăt cum am structurat fluxul și de ce n-ar trebui să lăsați niciodată LLM-ul să scrie SQL direct pe baza de date. Economisești zeci de ore de suport, dar dacă nu ești atent, te trezești cu drop table.
De ce Function Calling și nu Text-to-SQL?
La un proiect cu 12k utilizatori activi, managerii mă tot băteau la cap cu rapoarte custom: „Câți useri din Cluj avem?”, „Care e valoarea medie a coșului?”. Să le fac dashboard-uri în Metabase pentru fiecare query ad-hoc era exclus, îmi mânca tot timpul.
Prima tentație a fost să las GPT-4 să genereze SQL direct pe baza schemei bazei de date. Am renunțat rapid. E un coșmar de securitate și o invitație deschisă la SQL Injection prin prompt-uri dubioase introduse de utilizatori malicioși. În plus, LLM-ul mai halucinează ocazional coloane care nu există în schemă.
Soluția safe? Function calling (sau Tool Use). Nu lași modelul să scrie SQL. Îi dai tu o listă de funcții predefinite, scrise de tine în cod, pe care el le poate apela. El doar decide când și cu ce parametri să le ruleze.
Arhitectura pe scurt
Fluxul are trei pași simpli și un roundtrip obligatoriu:
- Trimitem întrebarea utilizatorului și schema funcțiilor noastre către OpenAI.
- OpenAI analizează textul și ne zice: „Apelează funcția
getUserRevenuecu argumentuluserId: 402”. - Rulăm noi funcția în Node.js (luăm datele din Postgres în siguranță, cu query parametrizat), trimitem rezultatul înapoi la OpenAI, iar el îi formulează omului un răspuns politicos.
Unde doare cel mai tare (Trade-offs)
Nimic nu e gratis pe lumea asta, iar pattern-ul ăsta vine cu două mari probleme pe care le-am simțit pe pielea mea:
- Latența: Un singur răspuns necesită două apeluri API la OpenAI plus interogarea bazei de date. Vorbim de 2-4 secunde de așteptare. Pentru un chat în timp real pe site e horror. Pentru un bot de Slack intern e perfect.
- Costurile: Schema funcțiilor ocupă tokeni. Dacă ai 20 de funcții complexe și trimiți și istoricul conversației, un singur prompt poate mânca lejer 3-4k de tokeni la fiecare interacțiune. Plătești destul de mult pentru conveniență.
La final, am redus tichetele de suport pe rapoarte cu aproape 40%. Echipa de sales își scoate singură datele în Slack, iar eu nu mai stau să scriu query-uri de mână marțea la ora 10 seara.
Voi ați lăsa un agent să ruleze chestii în baza de date sau preferați să le dați un instrument de BI clasic și să se descurce singuri?