import openai
# Varianta 1: Prompt engineering (fără fine-tuning)
# Trimiti de fiecare dată un system prompt uriaș (cost mare în input tokens, latență mare)
response_prompt = openai.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "Ești un parser juridic. Regulile sunt... [2500 tokeni de reguli și 5 exemple]"},
{"role": "user", "content": "Text contract: ..."}
]
)
# Varianta 2: Model cu Fine-tuning (regulile sunt învățate în weights)
# Input tokeni minimi, răspuns ultra-rapid
response_ft = openai.chat.completions.create(
model="ft:gpt-4o-mini-2024-07-18:company:parser-v2",
messages=[
{"role": "user", "content": "Text contract: ..."}
]
)Am văzut mulți devi care sar direct la fine-tuning de îndată ce un model nu le scoate din prima JSON-ul exact așa cum vor. În 90% din cazuri e o greșeală scumpă și inutilă. Anul trecut am lucrat la un sistem de extras date din contracte (aprox. 18.000 de cereri pe zi) și am testat ambele variante până am găsit un echilibru financiar rezonabil.
De ce prompt engineering e prima opțiune
Toată lumea începe cu system prompts și few-shot learning. Pui 3-4 exemple în prompt, folosești un model mare gen Claude 3.5 Sonnet sau GPT-4o și treaba merge din prima zi. Avantajul e uriaș: schimbi logica de business în 10 secunde editând un simplu string. Nu ai pipeline-uri de MLOps, nu ai de curățat dataset-uri.
Dar la un volum serios, abordarea asta te rupe la buzunar. Când trimiteam câte un system prompt de 2.500 de tokeni la fiecare request doar ca să definim regulile și formatul JSON, factura OpenAI sărise de 2.200$ pe lună. În plus, latența medie era pe la 2.8 secunde per răspuns — inacceptabil pentru un UX fluid.
Când devine fine-tuning-ul soluția salvatoare
Existe o neînțelegere frecventă aici: fine-tuning-ul nu este pentru a învăța modelul informații noi. Pentru date noi sau cunoștințe dinamice folosești RAG (Retrieval-Augmented Generation). Fine-tuning-ul este exclusiv despre stil, format, structură și latență.
Am strâns 600 de exemple curate din producție (perechi input-output), verificate manual. Am rulat un fine-tuning pe un model mai mic și mult mai ieftin (GPT-4o-mini / Llama 3 8B auto-găzduit).
Rezultatele au fost clare:
- Prompt-ul de intrare a scăzut de la 2.500 de tokeni la doar 150 de tokeni (regulile erau deja învățate în ponderi).
- Factura lunară a scăzut de la 2.200$ la 350$.
- Latența a coborât sub 450ms.
Trade-off-urile pe care nu le calculează nimeni la început
Fine-tuning-ul sună excelent financiar, dar vine cu o ancoră grea: rigiditatea.
Dacă clientul vine săptămâna viitoare și zice "vezi că vrem să extragem și câmpul X din contracte", un prompt clasic îl modifici imediat. La fine-tuning, trebuie să modifici dataset-ul, să validezi din nou 600+ exemple, să rulezi antrenamentul și să testezi dacă modelul nu a suferit de catastrophic forgetting (să nu fi stricat comportamentul pe cazurile vechi).
În plus, curățarea datelor durează. Să pregătești 500 de exemple fără erori umane înseamnă zeci de ore de muncă migăloasă.
Regula mea empirică
Treci la fine-tuning doar dacă bifezi cel puțin una din condițiile astea:
- Ai peste 10.000 de request-uri/zi și costul token-ilor din system prompt îți depășește bugetul.
- Ai nevoie de latență sub 1 secundă și nu îți permiți timp de procesare pe context lung.
- Modelul de bază e incapabil să respecte un format ultra-complex doar din câteva exemple.
În rest, rămâi pe un prompt bine structurat și un model flagship. E mult mai ieftin să plătești tokeni scumpi câteva luni decât să irosești timp de engineering pe mentenanța unui model antrenat prematur.
Voi la ce prag de volum sau latență ați simțit că un prompt simplu nu mai face față?