Am pus un agent AI pentru blog să publice singur. Trei luni mai târziu aveam 47 de articole, trafic organic aproape neschimbat și o problemă pe care n-am anticipat-o: articolele semănau între ele. Nu erau identice. Dar dacă citeai două la rând, simțeai că veneau din același loc.
Nu era defect de model. Era defect de sistem. Asta e autopsie, nu scuză.
Diagnosticul: formula de rotație cu perioadă prea scurtă
Am pornit cu o listă de 30 de subiecte. Am scris un script care alegea subiectul zilei după o formulă: indexul zilei din an modulo lungimea listei. Părea simplu și elegant.
Problema: dacă lista are 30 de elemente și roți după ziua din an, după 30 de zile o iei de la capăt. Exact. Subiectul de la ziua 1 revenea la ziua 31, la ziua 61, la ziua 91. Într-un an publicai fiecare subiect de 12 ori, cu variații de formulare.
Am adăugat mai multe subiecte în listă. Dar formula de rotație rămânea deterministă. Aceeași sămânță, aceeași ordine, aceeași perioadă. Un agent AI pentru blog care rulează pe o formulă fixă se comportă ca un mecanism de ceas: previzibil și repetitiv.
Soluția la formulă nu e să mărești lista la nesfârșit. E să scoți complet formula și să pui o coadă cu ordine manuală. Ordinea contează: subiecte similare puse la distanță una de alta, nu una după alta.
Agent AI pentru blog: deduplicarea pe ce a publicat, nu pe ce planifică
Prima corecție a fost deduplicarea pe istoricul real. Nu pe lista de planuri, nu pe ce era în coadă: pe titlurile și subiectele deja publicate, cu un hash al subiectului principal.
Înainte de a trimite un subiect la agent, sistemul calculează un fingerprint: hashlib din Python pe câteva cuvinte cheie extrase din subiect. Dacă hash-ul mai e în baza de date a publicărilor din ultimele 90 de zile, subiectul e sărit. Nu publicat cu o altă formulare. Sărit complet.
Asta a tăiat repetițiile directe. Dar articolele continuau să semene.
Cauza reală: modelul cauta pe web și găsea ce găsea toată lumea
Instrucțiunea era: „scrie cu exemple concrete și date reale”. Modelul interpreta asta literal: căuta pe web, găsea aceleași 3-4 surse indexate bine pentru subiect și le parafraza. Același conținut, alte cuvinte.
Asta nu e defect de model. E că nu i-am dat nicio altă sursă. Dacă nu ai material propriu, modelul folosește ce găsește. Ce găsește e același cu ce găsise și săptămâna trecută, fiindcă același subiect are aceleași surse indexate bine.
Genericul nu vine din lene. Vine din lipsa de material specific. Google descrie asta în ghidul pentru conținut util: conținutul creat pentru a acoperi un subiect, fără experiență proprie sau perspectivă distinctă, nu aduce valoare indiferent cât de bine e scris tehnic.
Simptomul era vizibil în structura articolelor. Fiecare articol despre același domeniu începea cu un paragraf de context, urmat de aceleași trei sau patru puncte, urmat de concluzie. Nu pentru că modelul copiase. Ci pentru că sursele publice aveau aceeași structură și modelul o reflecta.
Soluția: brief-ul care cară materialul cu el
Am schimbat modelul complet. Nu mai există o listă de subiecte. Există o coadă de brief-uri.
Un brief nu e un titlu. E un document de 200-400 de cuvinte care conține: subiectul, unghiul specific, materialul de folosit (studii, date, experiențe proprii, conversații cu clienți), ce trebuie acoperit și ce nu. Modelul primește brief-ul, nu subiectul.
Dacă brief-ul e generic, articolul e generic. Dacă brief-ul are material specific, articolul îl reflectă. Agent AI pentru blog nu produce conținut bun singur: produce conținut bun dintr-un brief bun. Asta e onest și e de fapt argumentul de vânzare: nu vinzi un robot care scrie, vinzi un sistem care amplifică brief-uri bune.
Un brief bun durează 20-30 de minute să fie scris. Dar el înlocuiește 2-3 ore de scris textul complet. Calculul are sens dacă tratezi brief-ul ca pe o muncă separată, nu ca pe un pas în plus înainte de scris.
Regula din prompt nu face ce face poarta din cod
Aveam o regulă în promptul agentului: „evită propozițiile lungi fără virgulă, evită clișeele de tip gazetă”. Articolele publicate aveau exact asta. De fiecare dată.
Motivul e că o regulă în prompt e o sugestie. Modelul încearcă s-o urmeze, dar dacă nu există o verificare exterioară care să respingă textul când regula e încălcată, regula se erodează. Cu cât mai complexe instrucțiunile, cu atât mai puțin sunt urmate toate simultan.
Am adăugat o poartă automată care rulează după ce modelul termină textul și înainte de publicare. Poarta verifică:
- Prezența clișeelor de limbaj generat: formule ca „este X de reținut”, „în epoca Y”, „nu trebuie trecut cu vederea”
- Construcții repetate de tranziție: „De asemenea”, „Astfel”, „Totodată” în mai mult de 10% din propoziții
- Uniformitatea lungimii propozițiilor: un coeficient de variație sub 0.5 indică un ritm de metronom
- Em-dash în text (un tipar specific modelelor care scriu în engleză și traduc obiceiuri)
Dacă poarta respinge, textul nu se publică. Agentul rescrie. Dacă rescrierea e respinsă a treia oară, brief-ul merge în coada de revizuit de om. Nu se publică automat cu al patrulea retry.
Codul care verifică e mai fiabil decât promptul care instruiește. Un string de 10 caractere căutat cu regex e fie acolo, fie nu e. Un model de limbaj urmat de o instrucțiune e aproximativ acolo, uneori, depinde de context.
Agent AI pentru blog: ce tipare verifici automat
Verificarea de ritm e cel mai util test. Un text scris de un om variază natural: propoziții de 3 cuvinte lângă propoziții de 25. Textul generat tinde spre uniformitate. Coeficientul de variație al lungimii propozițiilor sub 0.5 e un semnal, nu o certitudine, că textul sună mecanic.
Clișeele sunt mai ușor de detectat: expresii fixe, căutate ca string-uri exacte. Poți folosi un al doilea apel API cu un model mai mic și mai ieftin care evaluează textul pe o scară 1-5 pentru naturalețe. Dar asta adaugă latență și cost. Stringurile fixe prinse în cod sunt mai rapide și mai predictibile.
Ce nu se poate verifica automat: dacă informația e corectă, dacă unghiul e original, dacă articolul aduce ceva ce nu există deja pe web. Asta e munca omului care scrie brief-ul. Nici un model de limbaj, oricât de bun, nu știe ce ai văzut tu în propria firmă pe care nu l-a văzut nimeni altcineva.
Când coada e goală, nu publici
Asta pare evident, dar nu era în sistemul inițial. Dacă nu era brief nou, sistemul genera subiect din lista rotativă și publica oricum. Presiunea de a posta constant era codificată în logică.
Am scos-o. Dacă coada de brief-uri e goală, agentul nu publică nimic în ziua respectivă și trimite un reminder că trebuie scris un brief nou. O zi fără articol nu strică nimic. Un articol generic în plus strică puțin din credibilitatea sitului.
E o decizie greu de luat în practică. Simți că pierzi tempo. Dar agent AI pentru blog fără brief bun e un generator de conținut inutil, nu un instrument de marketing.
Am testat ambele variante. Lunile cu brief-uri constante au adus articole citate și distribuite. Lunile în care am publicat pentru a menține ritmul au adus articole vizitate o dată din trafic organic și uitate. Frecvența nu compensează relevanța.
Ce rămâne obligatoriu de om
Alegerea subiectului. Scrierea brief-ului cu materialul inclus. Revizuirea brief-urilor respinse de trei ori de poartă. Și decizia de a nu publica când nu există material suficient pentru un brief bun.
Scrierea brief-ului înseamnă concret: alegi unghiul, adaugi datele care susțin unghiul, marchezi ce nu trebuie spus și ce trebuie obligatoriu menționat. Agentul ia de acolo. Fără brief, agentul ia de pe web și asta am văzut deja unde duce.
Asta nu e o limitare a sistemului. E design intenționat. Un agent AI pentru blog care funcționează fără om produce conținut fără perspectivă proprie. Conținut fără perspectivă proprie nu câștigă vizibilitate organică și nu convinge pe nimeni de nimic.
Poți citi și cum am construit un chatbot pentru documente interne care urmează aceeași logică: sistemul amplifică ce îi dai, nu inventează ce nu are.
Construim astfel de sisteme pentru firme mici și medii din România. Dacă vrei să înțelegi cum ar arăta un agent AI pentru blog cu brief-uri bune la baza lui, scrie-ne la office@seoclub.ro. Prima discuție e despre subiectele și materialul pe care le ai deja, nu o demonstrație generică.
Poți citi și cum funcționează automatizarea cu aprobare umană la alte tipuri de conținut operațional, dacă vrei să înțelegi cum se aplică același principiu de control la alte fluxuri.
