import openai
# Exemplu de Few-Shot Prompting scurt - adesea suficient în 90% din cazuri
def classify_support_ticket(user_message: str) -> str:
system_instruction = """
Ești un clasificator strict de tichete. Răspunzi DOAR cu unul din tag-urile: [BUG, BILLING, FEATURE].
Exemplu 1:
User: Nu pot trece de pasul de plată cu cardul.
Output: BILLING
Exemplu 2:
User: Aplicația dă crash când apăs pe avatar în iOS.
Output: BUG
"""
response = openai.chat.completions.create(
model="gpt-4o-mini",
temperature=0.0,
messages=[
{"role": "system", "content": system_instruction},
{"role": "user", "content": user_message}
]
)
return response.choices[0].message.content.strip()Nu mai aruncați bani pe fine-tuning înainte să stoarceți tot ce se poate dintr-un prompt bine structurat. Anul trecut am plătit peste 3.000$ pe un fine-tune de Llama 2 pentru un client, doar ca să-mi dau seama că 4 exemple puse bine într-un system prompt pe GPT-4 dădeau rezultate identice fără niciun cost de mentenanță. Dacă te întrebi când merită să schimbi ponderile modelului și când să schimbi doar textul din request, hai să discutăm cifre și cazuri reale.
Când un prompt bun e mai mult decât suficient
În 90% din proiectele de care m-am lovit în ultimii doi ani, un prompt bine scris combinat cu RAG (Retrieval-Augmented Generation) rezolvă problema curat. Dacă ai nevoie ca LLM-ul să extragă date dintr-un text, să clasifice tichete de suport sau să răspundă pe baza documentației interne, nu ai niciun motiv tehnic să faci fine-tuning.
Prin few-shot prompting (adică îi dai modelului 3-5 exemple de "input -> output" direct în prompt), un model generalist ca GPT-4o sau Claude 3.5 Sonnet înțelege instant formatul și cazurile de margine.
Trade-off-ul direct: Cumpări flexibilitate și viteza de dezvoltare, dar plătești mai mulți tokeni pe fiecare request fiindcă trimiti exemplele de fiecare dată. Totuși, la un volum mic spre mediu (sub 10.000 de request-uri pe zi), e incomparabil mai ieftin decât să plătești instanțe dedicate pentru un model antrenat de tine.
Când fine-tuning-ul chiar își scoate banii
Fine-tuning-ul nu este despre a învăța modelul informații noi — pentru asta folosești RAG. Fine-tuning-ul este despre stil, format strict și reducere de latență/costuri la volum mare.
Am avut un proiect de clasificare de date juridice unde procesam peste 120.000 de request-uri zilnic. Promptul nostru inițial era un monstru de 1.800 de tokeni pentru că trebuia să-i explicăm modelului un format JSON extrem de ciudat și 20 de reguli de sintaxă. Latența era uriașă (peste 3 secunde per call), iar bill-ul lunar de API arăta ca o chirie în Cluj.
Am strâns un set de date curat de 2.000 de exemple și am făcut fine-tune pe un model mic, Llama 3 8B. Rezultatul?
- Prompt-ul a scăzut de la 1.800 tokeni la 45 tokeni (nu mai trebuia să-i dăm instrucțiuni lungi, modelul știa deja ce are de făcut).
- Latența a scăzut sub 400ms.
- Am mutat modelul pe infrastructura noastră cloud și am tăiat costul lunar de la $4.500 la sub $800.
Regula mea de aur în producție
Înainte să atingi vreun script de antrenare, urmează pașii ăștia în ordine strictă:
- Zero-shot prompt: Scrie simplu ce vrei.
- Few-shot prompt: Adaugă 3-5 exemple reprezentative de output.
- RAG: Dacă modelul halucinează pe date specifice de business, conectează o bază de date vectorială.
- Fine-tuning: Schimbă ponderile DOAR dacă depășești bugetul din cauza volumului masiv, dacă latența e inacceptabilă pentru UX, sau dacă un model mic (3B/8B) trebuie să imite un model uriaș pe o singură sarcină hiper-specifică.
Să sari direct la fine-tuning e ca și cum ți-ai construi propriul framework web înainte să scrii prima pagină HTML. Recomandat e să începi leneș, să măsori costurile per request și să treci la modele custom doar când numerele din billing te obligă.
Voi la ce volum de date sau request-uri ați simțit că un prompt engineering bun a atins o limită?