Întrebarea care a stat în spatele Elite Solution: de ce un singur model AI mare (Claude, GPT-4) eșuează atât de des la întrebări simple de business, deși răspunde corect la teoria cuantică?
Răspunsul scurt: nu eșuează modelul. Eșuează arhitectura cu un singur agent care încearcă să facă totul.
Acest articol explică cum am construit alternativa.
Problema cu modelul singur
Când un cumpărător scrie pe Instagram "cât costă pentru un magazin de fashion cu 1000 mesaje pe lună?", un singur model trebuie să facă, simultan:
- Decidă că e o întrebare de pricing (nu support, nu off-topic)
- Cunoască pricing-ul actual al companiei (de la prompt sau context)
- Calculeze că 1000 mesaje/lună se încadrează în Growth, nu Starter
- Înțeleagă vocea de brand specifică pentru a răspunde fără hype
- Verifice că răspunsul nu inventează prețuri greșite
Și să facă toate astea în 2-4 secunde, în limita unui context limitat, cu un singur prompt de sistem.
Asta nu e o problemă de model — Claude Sonnet ar putea face fiecare pas separat foarte bine. E o problemă de orchestrare: un singur agent cu un singur prompt nu prioritizează corect între cele cinci sarcini.
Soluția: împărțim munca pe specialiști
Inspirat de cum lucrează o echipă umană de vânzări, am împărțit pipeline-ul în roluri:
Router — un model rapid (Claude Sonnet) care primește întrebarea și decide două lucruri: ce intent are (pricing_inquiry) și ce specialiști să invoce (knowledge, sales, case-studies). Output strict JSON, ~250ms.
Specialiști în paralel (Claude Haiku, ~1-2s fiecare):
- Knowledge caută în baza de cunoștințe a businessului tău (pgvector + RAG) și returnează chunks-uri relevante cu scor de confidence.
- Sales ia contextul (volum 1000 mesaje/lună), aplică criteriile de recomandare, returnează tier-ul (Growth) + argumente.
- Case-studies ar aduce dovezi din clienți similari (deocamdată: pilot phase, returnează onest că nu există încă).
Synthesizer (Felix) — Claude Sonnet streaming. Primește toate output-urile specialiștilor și produce un răspuns coerent, în vocea brandului. Token-by-token către UI cu caret blinking — utilizatorul vede răspunsul apărând incremental.
Reviewer — Claude Haiku, ultimul pas. Verifică răspunsul final împotriva evidence-urilor și unei liste fact-check (prețuri canonice, domeniu corect, stack tehnic). Dacă găsește mismatch, orchestrator-ul reia Synthesizer-ul cu corrections injectate.
De ce funcționează mai bine
Trei motive concrete:
1. Specializare per prompt. Fiecare agent are un system prompt scurt (300-500 cuvinte) focusat pe o singură sarcină. Router-ul nu trebuie să știe pricing; Sales-ul nu trebuie să clasifice intent. Asta înseamnă prompts mai dense, instrucțiuni mai stricte, mai puțin loc pentru distragere.
2. Paralelism real. Specialiștii rulează în paralel prin Promise.allSettled. Latența totală nu se cumulează — e dictată de cel mai lent specialist (în general 1-2s pentru Haiku). Pentru o întrebare care cere 3 specialiști, nu plătim 3× latența. Plătim 1×.
3. Verificare post-generare. Reviewerul nu e "al doilea model care confirmă primul" (cost mare, beneficiu mic). E un agent specializat care verifică un set explicit de fapte canonice contra răspunsului final. Costa ~$0.001 per query, prinde 80%+ din halucinații concrete.
Trade-offs onești
Arhitectura asta nu e gratis. Câteva costuri reale:
Latency totală mai mare decât un single-agent call. Un agent singur poate răspunde în 3-5s. Orchestrarea noastră ajunge la 15-20s pe medie. Mascam asta cu UI streaming (utilizatorul vede activitate constantă), dar timpul real e mai mare. Optimizările vin: prompt caching beta de la Anthropic, reducere max_tokens, intent-aware parallelism reduction pentru queries simple.
Cost per query mai mare. Un single-agent call costă ~$0.003. Pipeline-ul nostru costă ~$0.02. Acceptabil pentru valoarea adăugată (răspuns mai bun, audit complet), dar trebuie calibrat.
Complexitate operațională. Debug-ul unui pipeline cu 5 agenți cere instrumentare serioasă: trace events persistate, retry logic, observability per agent. Investiție inițială mai mare în tooling.
Când are sens
Orchestrarea multi-agent are sens când:
- Volume conversational mare (sute-mii de mesaje pe lună)
- Întrebări nuanțate, nu doar FAQ rigid
- Brand voice important, nu chatbot generic
- Audit factual obligatoriu (legal, sales)
- Buget per query > $0.01 acceptabil
Pentru un FAQ simplu cu 20 întrebări fixe, un script if/else e mai bun. Pentru tot ce e dincolo, multi-agent își amortizează complexitatea în 2-3 luni de operare.
Vrei să vezi pipeline-ul în acțiune pe propriile întrebări? Vorbește direct cu Felix pe pagina noastră de chat — vei vedea trace-ul în timp real pe coloana din dreapta.