A Content Studio belső működése

A Nortinia Content Studio nem egy CMS. Inkább egy pipeline: bemegy egy target (egy konkrét célközönség + brand voice + témafókusz), és kijön belőle egy publikálható cikk. Hat hónappal a stabilizálás után megpróbáljuk leírni, mit szúrtunk el először, és mit hagyunk most rendben.

A pipeline négy szakasza

1. target — egy NestJS service-ben tárolt entitás Postgres FORCE RLS alatt. Egy targetre 30+ mező jut: persona, tone, tiltott kifejezések, kötelező CTA-k, kulcsszavak, kiküldés gyakorisága. A target a tudás. Minden más egyetlen lekérés tőle.
2. generator — egy BullMQ job, amely a target alapján Nortinia Engine-en keresztül hívja a megfelelő modellt. Egy generátor egy cikket állít elő egy futás alatt. Nincs retry middle-of-generation: ha hibázik, eldobjuk és újrahívjuk a teljes job-ot tiszta inputtal.
3. eval — szigorú kapu, nem hint. Hat dimenzió mentén pontoz: tartalmi relevancia, tone-illeszkedés, faktualitás, tiltott szavak, hosszminimum, CTA-jelenlét. A küszöb tenant-szinten konfigurálható, de alapból 0.78 minden dimenzióra. Ha nem megy át, vissza a generátorba — maximum három iteráció.
4. publish — egy POST-hívás a fogadó storefront /api/blog/publish route-jára. Idempotens (articleId alapján), Bearer tokennel autentikál, és a payload egy CmsArticle JSON.

Miért lett az eval kapu, nem hint

Az első hat hét alatt az evalt csak figyelmeztető rétegként futtattuk. A szerkesztő látta a pontszámokat, de a generátor mindig publikált. Hat hét végén 312 cikk volt élesben, és kiderült, hogy 47 közülük olyan hangnemű, ami semmilyen brandhez nem illeszkedett. Egyetlen ügyfél telefonja után úgy döntöttünk: az eval ezentúl kapu. Ha nem megy át, nem publikálunk. Pont.

A három iteráció után dobott cikkek 19%-ban kerülnek a manuális review queue-ba. A többi 81% kuka. Ez fáj, de olcsóbb, mint visszamenőleg törölni élesről.

Approval mode: auto vs. manual

Minden tenant beállíthatja, hogy az eval-átment cikket automatikusan publikáljuk, vagy egy emberi szerkesztő várja a queue-ban. A 14 design partnerünk közül:

• 9 tenant auto módban — heti 3-5 cikk, nem kell emberi kéz, mindenki boldog
• 5 tenant manual módban — szabályozott iparágak (egészségügy, pénzügyi tanácsadás), itt a compliance felülbírál mindent

A tanulság: nem létezik egyetlen jó alapbeállítás. A SaaS minta szerint az új tenant manual módban indul, és az első 20 átment cikk után magától felajánljuk az auto-t.

A legnehezebb darab: persona ingestion

Amikor egy új target jön be, valakinek le kell írnia a célközönséget. Eleinte azt hittük, ez egy egyszerű űrlap dolga. Aztán szembesültünk vele, hogy a tenant 70%-a nem tudja megfogalmazni, kinek ír. "Kkv-knak" nem persona. "35-55 közötti döntéshozó" sem persona.

Amit most csinálunk: a tenant feltölt 3-5 meglévő anyagot (cikk, brossúra, LinkedIn poszt), és az engine kiszedi belőlük a tone-jegyeket, a visszatérő témákat, és egy javasolt personát ad vissza. A tenant ezt szerkesztheti. A javaslat 78%-ban változatlanul megy át. Ez volt a legfontosabb UX-döntés az egész Studio életében.

Mit nem építettünk meg (és miért nem)

• Real-time co-editing — három tenant kérte. Egyik sem használta volna napi szinten. Nem építettük meg.
• Saját képgenerátor a cikkekben — a Nortinia Engine /illustrate endpointja már ezt csinálja, nem duplikáljuk.
• A/B teszt a publikált cikkekre — érdekes, de túl korai. 14 tenant, heti ~40 cikk: nincs elég volumen szignifikáns tesztekre.

Számok hat hónap után

• 2 847 publikált cikk
• 67%-os első-iterációs átmenési arány
• 12 perc átlagos teljes pipeline-idő (target read → publish HTTP 200)
• 0.31 USD átlagos modell-költség cikkenként (GPT-5 vegyes felhasználással)

A pipeline most stabilabb, mint amilyennek hat hónappal ezelőtt remélni mertük. A következő fázis a többnyelvűség mélyítése: jelenleg HU/EN, jövő negyedévben jön a DE és a SK.

Mit terveztünk építeni de elhalasztottuk

• Cikk-versioning fastorically. Minden publish külön rekord, de a generátor minden iterációja nem maradt meg. Hat tenant kérte, hogy lássák a "miért bukott meg az eval első körben" trace-t. Ez egy hasznos diagnosztikai eszköz, de nem business critical. Jövő hónapban épül.
• Cross-target tudásmegosztás. Két target hasonló iparágban gyakran ugyanazt a hibát eredményezi. Egy közös "tanulás bank" pufferből merítve csökkenthetné az ismétlő hibákat. A privacy oldal viszont nem trivális (egy tenant tartalom-mintáját nem akarjuk másnak átadni). Halasztva.
• In-line szerkesztés a manual queueban. Most kódból editáljuk, vagy a webes UI-t használjuk amely nem volt teljes körű. Ez egy 2 hetes UX-fókusz lesz.

A csapatdinamika

A Studio-t most két fős mérnök csapat tartja fenn, mellette egy operations engineer fél munkanapban. Ez kevésnek tűnhet 2 847 cikk havi szállításához, de a pipeline annyira automatizált, hogy a manuális idő nagyrészt a target-onboarding (új tenant) és az eval szabály-finomítás. A go-live-után 4 hónap alatt egyetlen non-business hours alarm sem érkezett, ami önmagában egy jó jel.