# Polylane: hogyan akadályozzuk meg, hogy a slop elérje a prodot (2026-09-21)

> **Szerzők:** Vi Tran és Boris Tane
> **Forrás:** <https://polylane.com/blog/how-we-prevent-slop-from-hitting-prod/>
> **Megjelenés:** 2026. szeptember 21.
> **Formátum:** Technikai blog poszt (kb. 2100 szó), mérnöki esettanulmány mérési adatokkal
> **Téma:** Agent-alapú produkciós kockázatbecslés a pull request folyamatban
> **Alkalmazhatóság a saját rendszerünkre:** MAGAS (lásd a dedikált szekciót)

---

## Bevezetés és a lényeg

A cikk egy olyan rést tárgyal, amit a legtöbb agent-alapú fejlesztői rendszer nem zár be. Ha van egy "szoftvergyárad", amely promptból pull requestet csinál, akkor a jelenlegi ellenőrzések mind a **diffet** nézik: típusok, tesztek, linter, formatter, kód-review. Egyik sem tud semmit arról a **produkciós rendszerről**, amelyre a diff le fog kerülni. Ezért a legfontosabb kérdésre, hogy „ez a változás rendben van-e a prodon?”, nincs válasz.

A Polylane pontosan erre a kérdésre épített egy képességet, és a cikk a technikai megvalósítást írja le. A szerzők szándékosan leszűkítik a feladatot: a stílus, az elnevezések és a teszt-lefedettség nem érdekli őket, kizárólag az, hogy a változás a mergelés és deploy után **negatív hatással lesz-e a produkcióra**. A választ a pull request szakaszában adják meg, a meglévő tesztek mellett, és a kimenet egy egyszerű **„mehet” / „nem mehet”** üzenet a bizonyítékokkal együtt.

A cikk legértékesebb része nem a rendszer, hanem a mérési fegyelem. A szerzők nyíltan leírják, hogy az első prototípusuk **kudarcot vallott** a latenciakeretükön (medián közel 7 perc, gyakori 20 perces futások), és hogy a jelenlegi megoldásuk egy részét (**az idősort-előrejelzést**) még mindig mérik, és egyelőre csak a „vibes-eval”-t teljesíti. Ez a fajta önkorlátozás ritka a termékipari blogposztokban.

A legfontosabb tanulságok:

- **A diff-alapú ellenőrzés szerkezetileg vak a rendszerállapotra.** Egy zöld CI-futás nem mond semmit arról, hogy a változás mit tesz a futó produkcióval. A megoldás egy **kontextusgráf**, amely a repókat, a felhőerőforrásokat és a csapatokat összekapcsolja.
- **A megbízhatóság a hivatkozásokból jön, nem a modell konfidenciájából.** A rendszer kimenete egy **trajektória-főkönyv**: minden ok-okozati lánc minden eleme hivatkozást hordoz (fájl és sor, log-sablon a darabszámmal, metrikaolvasat, konfigkulcs, gráfél).
- **A háromállapotú ítélet jobb, mint a bináris.** A trajektória lehet `confirmed`, `plausible` vagy `refuted`, és a szabály konzervatív: bármely megerősített trajektória bukott értékelést jelent.
- **A látens keret maga a termék.** A CI-ban futó lépésnek 2-3 perc a költségvetése. A prototípus 7 perces mediánja elfogadhatatlan volt, a jelenlegi 94 másodperc.
- **A lépéskeret közlése a modellel fontosabb, mint maga a szám.** A 30 lépéses plafon akkor működik, ha a modell minden lépésnél látja, mennyit fogyasztott.
- **Az új munka új szálon indul, nem a meglévőbe simul.** A szerzők prototípusa a friss commitot egy „steering” üzenetként fűzte be ugyanabba a review-szálba, és a modell ettől elkezdte újraolvasni a már megvizsgált fájlokat. Az új szál indítása ellenintuitív módon **csökkentette** a latenciát.
- **A siker-metrika a megelőzött incidens, nem a futtatott elemzés.** Jelenleg heti **2,3 megelőzött produkciós incidens ügyfélenként**, és ezt négy konkrét feltétellel definiálják.

## A rendszer kérdése és a folyamat

A szerzők egyetlen kérdésre szűkítik a rendszer feladatát:

> „Vajon ez a változás, a mergelés és a deploy után, negatív hatással lenne a produkcióra?”

A folyamat hat lépésből áll, és a felépítés lineáris:

1. A pull request olyan fájlokat érint-e, amelyek hathatnak a produkcióra?
2. Mely felhőerőforrások érintettek potenciálisan?
3. Kontextus gyűjtése ezeknek az erőforrásoknak a **jelenlegi produkciós állapotáról**.
4. A változás által bevezethető **több lehetséges meghibásodási mód** kiértékelése.
5. Annak előrejelzése, hogyan változhat a produkció a deploy után.
6. A fejlesztők értesítése a valószínű meghibásodási módokról.

A gyakorlati példa, amit a cikk bemutat, jól mutatja, miért nem elég a diff. Egy migrációs fájl `migrations/0114_order_search_trgm.sql:3` **`CREATE INDEX … USING gin (search_text gin_trgm_ops)`** utasítást ad hozzá `CONCURRENTLY` nélkül. A sima `CREATE INDEX` a teljes építés idejére **teljes írási zárat** tesz az `orders` táblára. Az `orders-db` a checkout-ot szolgálja ki körülbelül **38 írás/másodperc** terheléssel, és minden egyes írás a zár mögött sorakozik fel, amíg az index fel nem épül. A javaslat: az indexet `CREATE INDEX CONCURRENTLY`-vel, a tranzakciós migráción kívül kell építeni.

Ebben a példában a diff önmagában teljesen rendben lévő SQL-t mutat. A probléma csak a **produkciós állapot** (a tábla terhelése) és a **végrehajtási művelet** (a zár) együtteséből származik. Ez a cikk központi érve.

## A kontextusgráf: a rendszerállapot összerakása

A kontextusgráf a rendszer gerince. Ez egy folyamatosan épülő regiszter, amely az összes felhőerőforrást, repót és csapatot összekapcsolja. Egy számítási csomópont, például egy Lambda-függvény, össze van kötve azzal az adatbázissal, amelyből olvas, és azzal a sorral, amely triggereli. A repókat a szokásos manifest-fájlok alapján veszik fel a gráfba: **Terraform**, **CloudFormation**, **Wrangler**. Ez teremti meg a kapcsolatot a repók és a felhőerőforrások között.

Amikor egy pull request beérkezik egy repóba, a rendszer végigköveti a kontextusgráf éleit, és összegyűjti az összes potenciálisan érintett felhőerőforrást. Mivel egy repóból sok erőforrás települhet, egy **kis modell** szűri a jelölteket. A szűrt kontextus a diffel, a PR leírásával és a commitokkal együtt megy az agentnek.

Emellett a diff átmegy egy **determinisztikus heurisztikacsomagon**, amelyek gyorsan ráirányítják az agent figyelmét arra, ami általában negatív hatással szokott lenni:

- olyan migráció, amelyet kézzel kell alkalmazni, vagy a deployhoz képest meghatározott sorrendben;
- **`CREATE INDEX` `CONCURRENTLY` nélkül**, vagy **`ADD COLUMN … NOT NULL` alapérték nélkül**, amelyek a teljes művelet idejére zárat tesznek a táblára;
- olyan végpont eltávolítása, amelyet a jelenleg telepített verzió még olvas;
- olyan kód, amely elkezd olvasni egy környezeti változót, secretet vagy bindinget, amelyet semmi nem hoz létre a difben.

A szerzők hangsúlyozzák, hogy ezek **javaslatok**, nem kemény szabályok: a heurisztikák a valószínű deploykockázatok felé terelik az agentet, nem döntenek helyette.

## Trajektóriák: a bizonyítékokkal ellátott ok-okozati láncok

Az agent a kapott kontextusból különböző meghibásodási módokat állít elő, és mindegyiket egyenként kivizsgálja. A kimenet egy **trajektória-főkönyv**. A szerzők definíciója szerint egy trajektória **egyetlen ok-okozati lánc**: egy kiváltó okból, a megváltozott kódon keresztül, egy adott metrikán megfigyelhető romlásig. A lánc **minden eleme hivatkozást hordoz**: egy fájl és sor, egy log-sablon a darabszámával, egy metrikaolvasat, egy konfigkulcs, egy gráfél.

Ez a rész a cikk legfontosabb módszertani mondanivalója. A bizonyíték nincs a szövegben elszórva, hanem **strukturálisan a lánc minden linkjéhez hozzá van rendelve**. Így egy trajektória vagy megállja a helyét hivatkozásokkal, vagy nem.

Az agent minden trajektóriát megpróbál **igazolni és cáfolni** is, mielőtt ítéletet mond. A végállapot háromféle lehet:

- **`confirmed`**: a trajektória a produkciós telemetriával megerősítést nyert.
- **`plausible`**: a lánc konkrét, de egy vagy több linket csak „tippelni” lehetett, mert nincs telemetriai adat a megerősítéshez.
- **`refuted`**: a produkciós telemetria elég bizonyítékot adott arra, hogy ez a trajektória valószínűleg nem következik be.

A szabály konzervatív, és a cikk a kódot is megadja:

```typescript
export function deriveTrajectoryVerdict(trajectories: Trajectory[]): "pass" | "fail" {
  return trajectories.some((entry) => entry.status === "confirmed") ? "fail" : "pass";
}
```

Az ábra szerinti példában három trajektória fut: egy eltávolított index, amelyet a checkout még használ (`confirmed`), egy retry-változás, amely felerősíti a terhelést az `orders-db`-n (`plausible`), és egy eltávolított binding, amely elrontja a workert (`refuted`). A `confirmed` miatt az ítélet **nem mehet**, a másik kettőtől függetlenül.

Érdemes észrevenni a **`plausible`** kategória szerepét: ez az a hely, ahol a rendszer elismeri, hogy **nem tud dönteni**, mert nincs mért adata. Ez pontosan az a fajta őszinte állapot, ami a legtöbb automatizált rendszerből hiányzik, mert a bináris „átment / nem ment” nem engedi meg.

## Az előrejelzés: miért kell multivariáns modell

A szerzők az agentnek egy eszközt adnak, amellyel historikus adatokból **idősorokat jelez előre**, külső tényezők befektetésének lehetőségével. Az indoklás a cikk legjobban megfogalmazott érvei közé tartozik.

Tegyük fel, hogy egy trajektória szerint egy változás felezni fogja egy retry-ző útvonal timeoutját. Hogy ez számít-e, a forgalomtól függ, és a forgalom nem egyetlen szám, hanem **alakzat**. Egy sor 60 százalékos mélységben, ami ott is marad, rendben van. Ugyanaz a sor 60 százalékon, de **hetente emelkedve**, egészen más helyzet, és az elmúlt egy óra metrikáinak olvasása nem mondja meg, melyikkel van dolgod.

Ezért mielőtt az agent megfogalmazza egy trajektória ítéletét, lehúzza az érintett erőforrások historikus sorozatait, és **együtt** jelzi előre őket. A szerzők jelenleg a **`Toto-2.0-22m`** modellt futtatják saját maguknál (self-hosted), amely a Datadog nyílt súlyú, megfigyelhetőségi metrikákra hangolt idősor-alapmodell családjának legkisebb használható tagja. Egy hívásban legfeljebb **16 sorozat** megy be, és **p10, p50, p90** kvantilisek jönnek vissza.

Az indoklás arra, hogy miért kell dedikált multivariáns modell, és miért nem elég egy újabb prompt: a sorozatok **nem függetlenek**. A kérési arány, a hibaarány, a latencia és a sormélység ugyanazon az erőforráson együtt mozognak, és ha mindegyiket külön jelzed előre, eldobod azt a korrelációt, amiért az előrejelzés egyáltalán ért valamit. A cikk megfogalmazása szerint egy hívásban minden sorozat **egy attention-csoportot** oszt meg.

A gyakorlati használat a sávon múlik, nem a mediánon: **64 órás megfigyelés** megy be, és **24 órás** előrejelzés jön vissza. A sáv a horizonttal szélesedik, és az agent a **sávot** olvassa a medián helyett. Az a válasz, ahol a p10 a küszöb felett marad, más, mint ahol átlépi.

Ez a rész viszont az, ahol a szerzők a legerősebben korlátozzák a saját állításukat, és ezt érdemes szó szerint megőrizni:

> „Ez a legkísérletibb képesség, amit nemrég adtunk hozzá, és még mindig mérjük a hatását. De már átmegy a vibes-evalon.”

## A latenciakeret: a prototípus kudarca és a három javítás

Mivel a produkciós hatásbecslés a pull request folyamatában fut, **gyorsnak kell lennie**. A szerzők saját repóikban kötelező CI-lépésként futtatják, és ha lassú, az egész SDLC lelassul. A költségvetésük **2-3 perc**, és ezen túl bármi elfogadhatatlan egy CI/CD pipeline-ban.

Az első prototípus ezt **teljesen elbukta**: a medián közel **7 perc** volt, és gyakoriak voltak a **20 perces** futások. A mérés szerint tipikusan **30-40 szekvenciális modell-lépést** futtattak, a legrosszabb esetekben közel **600 lépést**, egyenként **17 másodpercet** fogyasztva a keretből, és a kimenetük túlnyomó része **reasoning token** volt.

A cél az lett, hogy csökkentsék a modell-lépések számát, hogy az egész folyamat 3 perc alá kerüljön. Három változtatást emelnek ki (a mérések 2026. szeptember 15-én, **325 futtatásból** származnak).

**1. Lépéskeret bevezetése és közlése az agenttel.** A keret **30 lépésben** van maximalizálva agent-fordulónkét, és a modell **minden lépésnél látja, mennyit fogyasztott**. A szerzők megfigyelése szerint a szám beírása a promptba lehetővé teszi, hogy a modell körülötte tervezzen, és **ez többet számít, mint maga a szám**.

**2. Új review indítása a meglévőbe simulás helyett.** Egy pull requesthez a megnyitás után folyamatosan érkeznek új commitok. Az első prototípusban a teljes új diffet **ugyanabba a review-szálba** fűzték be, egy „steering” felhasználói üzenetként. Ez az irányítás **nagymértékben összezavarta** a modellt, amely elkezdte újraolvasni a már megvizsgált fájlokat, és újrafuttatni a már befejezett telemetriai lekérdezéseket.

A mostani megoldás: egy új commit **törli** az előző értékelési futást, és **teljesen új szálat** indít. A szerzők megjegyzik, hogy ez **ellenintuitív**, de végül **csökkentette** a teljes review-k latenciáját.

**3. A korábbi munka újrafelhasználása.** Amikor egy új commit érkezik egy már befejezett review után, korábban naivan a nulláról indult az egész hatásbecslés. Bevezették a korábbi értékelés **újrafelhasználását**, és az új értékelés csak a **két egymást követő commit közötti kisebb diffre** fut.

Az eredmény: a medián latencia **94 másodperc**, és a szerzők szerint kényelmesen a kereten belül van.

## A siker-metrika: megelőzött incidens, nem futtatott elemzés

A cikk záró szakasza teszi fel a helyes kérdést: mi értelme elégetni ennyi tokent, ha nincs értelmes eredmény? A szerzők metrikája a **hetente megelőzött incidensek száma ügyfelenként**, és egy megelőzött incidens négy feltétel **együttállása**:

- a rendszer jelez egy potenciális produkciós kockázatot;
- egy mérnök egy vagy több commitot tol fel;
- egy új értékelés arra jut, hogy a potenciális kockázat **enyhült**;
- a pull request **mergelésre kerül**.

A jelenlegi szám **2,3 megelőzött produkciós incidens ügyfelenként, hetente**. A szerzők hozzáteszik, hogy ez már jelentős, és arra számítanak, hogy nőni fog, valamint hogy folyamatosan iterálnak és **evalokat** futtatnak az agent teljesítményének és minőségének javítására.

Ez a metrika-definíció önmagában is tanulságos. Nem azt méri, hogy hány elemzés futott le, hány trajektóriát találtak, vagy hány tokent használtak el. Azt méri, hogy **a valóságban megváltozott-e valami**: a kockázat jelzése, a javítás, majd a mergelés együtt egy megelőzött incidens. A négy feltétel sorrendje ráadásul azt is kizárja, hogy egy jelzés nélkül elhaladt PR-t vagy egy meg nem javított kockázatot sikernek számoljanak.

## Saját rendszerünkre alkalmazható (MAGAS alkalmazhatóság)

Ez a cikk azért magas alkalmazhatóságú, mert ugyanazt a rést tárgyalja, ami a saját minőségbiztosítási pipeline-jainkban is megvan, és a megoldás szerkezete átvihető. Az alábbi pontok konkrétak és nem elvi szintűek.

**1. A diff-alapú ellenőrzés és a rendszerállapot-ellenőrzés szétválasztása.** A saját critique-ünk (`post_summary_critique_check.py`) **diff-alapú**: azt nézi, hogy a summary szövegében van-e `## Összegzés`, `## Forrás`, hány H2 van, mennyi a szószám. Ezek a summary **belső** tulajdonságai. Amivel nem foglalkozik, az a **célrendszer állapota**: a transcript létezik-e, a kanonikus helyén van-e, a counter egyezik-e a valós fájlszámmal, a topic-linkek élnek-e. Pontosan ez a hibaosztály volt a mai All-In feldolgozásban is: a critique `good`-ot adott, miközben a transcript a rossz mappában volt, és három korábbi summary hibás útvonalra mutatott. A cikk megoldása szerint **kontextusgráfra** van szükség, ami nálunk részben már létezik: a `wiki_sandbox_sync_check.py` és a `wiki_build_summaries.py --strict` **rendszerállapot-ellenőrzés**, nem diff-ellenőrzés. A tanulság az, hogy ezt a réteget kell erősíteni, nem az újabb szövegbeli MUST HAVE szabályokat.

**2. A háromállapotú ítélet bevezetése a jelenlegi kétszintű helyett.** Az `injection_assertions.py` **már most is** produkál egy `advisory` státuszt, amikor a `--transcript` hiányzik, mert a C-ellenőrzés nem tudja igazolni az eredetet. Ez pontosan a cikkbeli **`plausible`**: a lánc konkrét, de nincs telemetria a megerősítéshez. A cikk szerinti **`refuted`** viszont nálunk hiányzik: nincs olyan állapot, amikor a mérés azt mutatja, hogy egy gyanú **nem** áll fenn. Ennek a bevezetése csökkentené a hamis pozitívok kézi átnézésének terhét, mert a „megvizsgáltuk és nem igaz” elkülönülne a „nem vizsgáltuk meg”-től.

**3. A konzervatív alapérték: bármely megerősített találat bukás.** A jelenlegi critique-ünk **figyelmeztetés-központú**: a `too_long` flag „NEM blocker” minősítést kap, és a pipeline továbblép. Ez a gyakorlatban azt jelenti, hogy a figyelmeztetés nem kapu. A cikk szabálya egy sorban: **bármely `confirmed` trajektória → `fail`**. A saját rendszerünkre fordítva: minden olyan ellenőrzésnek, amelyik **igazolhatóan** problémát talál (nem stílus-preferenciát, hanem szerkezeti hibát), blokkolónak kell lennie. A `too_long` maradhat figyelmeztetés, mert ízlés-kérdés; a hibás transcript-útvonal viszont nem, mert tény.

**4. Lépéskeret és a fogyasztás közlése az agenttel.** A saját subagent-dispatch-einknél (`delegate_task`, chunk-batch, hosszú feldolgozások) **nincs lépéskeret**, és a modell nem látja, mennyit fogyasztott. A cikk megfigyelése szerint a szám közlése **többet számít, mint maga a szám**, mert a modell körülötte tervez. Ez közvetlenül átvihető: a hosszú futású subagent-promptokba be kell írni a rendelkezésre álló keretet és az aktuális fogyasztást.

**5. Új szál indítása a meglévőbe simulás helyett.** Ez a cikk legközvetlenebbül átvihető tanulsága, és **egybevág a saját tapasztalatunkkal**. A szerzők prototípusa a friss commitot egy steering-üzenetként fűzte be ugyanabba a szálba, és a modell ettől újraolvasta a már megvizsgált fájlokat. Ez ugyanaz a jelenség, amit a saját `delegate_task action='steer'` esetén is látni kell: a futó gyerekbe küldött korrekció **nem ingyenes**, mert a modell a régi kontextust újra feldolgozza. A cikk javaslata az, hogy az új munka **új szálat** kapjon, és a régi futás törlődjön. A mi MEMORY-batch pitfallunk („egy bukott op → a teljes batch bukik”) ugyanezt a mintát mutatja a maga szintjén.

**6. A korábbi munka újrafelhasználása, és csak a delta újraértékelése.** A saját pipeline-jaink jelenleg **teljes újrafeldolgozást** csinálnak: ha egy summary-ban hibát javítunk, az egész postprocess és critique lánc újrafut. A cikk mintája szerint a helyes eljárás a **korábbi értékelés megtartása** és csak a **megváltozott rész** újraértékelése. A gyakorlati haszna akkor jelentkezik, ha egy több tucat epizódot érintő javítást kell végigvinni.

**7. A siker-metrika: kimenet, nem aktivitás.** A saját riportjaink jelenleg **artefaktum-minőséget** mérnek: „LLM score 0,90”, „12 H2”, „5025 szó”, „auto_approved”. Ezek a summary tulajdonságai, nem az, hogy a summary **elvégezte-e a dolgát**. A cikk metrikája négy feltétel együttállását kéri (jelzés, javítás, megerősítés, mergelés). Nálunk a megfelelő analóg négyes lehetne: a summary elkészült, a pipeline zöld, a wiki-be tényleg bekerült (nem csak a raw-ba), és a forrás állításai ellenőrizve vannak. Ezt érdemes metrikaként rögzíteni, mert a jelenlegi „auto_approved” önmagában nem mond semmit a valós kimenetről.

**8. A nem mért képesség őszinte jelölése.** A szerzők azt írják az előrejelzésről, hogy „a legkísérletibb képesség, még mérjük a hatását, de már átmegy a vibes-evalon”. Ez a saját SOUL.md-nk truth-as-correspondence elvének pontos gyakorlata: **a nem mért állítást nem mértként kell megjelölni**, nem eredményként. A saját skill- és pipeline-leírásainkban is meg kell különböztetni a **mért** és a **levezetett** állításokat, ahogy azt a Naveen Rao epizód elemzése is megfogalmazta.

## Összegzés

A cikk egy olyan verifikációs réteget ír le, amely nem a diffet, hanem a **célrendszer állapotát** vizsgálja, és a kimenetét **hivatkozásokkal ellátott ok-okozati láncokra** építi. A legfontosabb tanulság nem a technológia, hanem a mérési fegyelem: a szerzők leírják a prototípus kudarcát, számszerűsítik a latenciakeret túllépését, és nyíltan megjelölik, melyik képességük nincs még mérve.

A saját rendszerünkre a négy legközvetlenebbül átvihető elem: (1) a háromállapotú ítélet (`confirmed` / `plausible` / `refuted`) bevezetése az `injection_assertions.py` már meglévő `advisory` logikájának kiterjesztésével; (2) az **igazolható** hibák blokkolóvá tétele a jelenlegi figyelmeztetés-központú critique helyett; (3) az új munka **új szálon** indítása a meglévő kontextusba való beolvasztás helyett; (4) a siker-metrika átállítása artefaktum-minőségről **tényleges kimenetre**.

A legfontosabb szerkezeti felismerés az, hogy a diff-alapú ellenőrzés és a rendszerállapot-ellenőrzés **két külön réteg**, és az első soha nem fogja elkapni a második hibáit. A mai All-In feldolgozás pontosan ezt mutatta: a szövegbeli MUST HAVE-ok mind teljesültek, miközben három summary hibás útvonalra mutatott. A critique-ünk zöld volt, a rendszer mégsem volt konzisztens.

## Forrás

- **Cikk:** <https://polylane.com/blog/how-we-prevent-slop-from-hitting-prod/>
- **Szerzők:** Vi Tran és Boris Tane
- **Megjelenés:** 2026. szeptember 21.
- **Kulcsszavak:** produkciós hatásbecslés, kontextusgráf, failure trajectory, trajektória-ítélet, confirmed/plausible/refuted, CI latencia-budget, lépéskeret, Toto-2.0-22m, idősor-előrejelzés, p10/p50/p90, megelőzött incidens, agent-alapú code review, slop
- **Alkalmazhatóság:** MAGAS. A cikk a saját minőségbiztosítási pipeline-jaink diff-alapú ellenőrzésének szerkezeti korlátját tárgyalja, és a megoldás három rétege (rendszerállapot-kontextus, hivatkozott láncok, háromállapotú ítélet) közvetlenül átvihető.
- **Megjegyzés a mérési adatokról:** a latenciaadatok (325 futtatás, 2026. szeptember 15-i mediánok) és a siker-metrika (heti 2,3 megelőzött incidens ügyfelenként) a szerzők **saját, önbevalláson alapuló** mérései. A cikk nem közöl független verifikációt, és az előrejelzési képesség hatását a szerzők maguk is méretlennek jelölik. Az itt szereplő számok tehát a Polylane állításai, nem külsőleg ellenőrzött tények.

## Kapcsolódó külső források

- [Polylane](https://polylane.com/), a cég és a termék
- [Toto 2.0: Time Series Forecasting Enters the Scaling Era (arXiv:2605.20119)](https://arxiv.org/html/2605.20119), a cikkben említett `Toto-2.0-22m` modell technikai jelentése (Datadog)
- [DataDog/toto a GitHubon](https://github.com/DataDog/toto), a modellcsalád nyílt forráskódú repója és a BOOM benchmark
- [Datadog/Toto-2.0-22m a Hugging Face-en](https://huggingface.co/Datadog/Toto-2.0-22m), a 22 millió paraméteres checkpoint (88,8 MB, Apache-2.0 licenc)
- [toto-models a PyPI-n](https://pypi.org/project/toto-models), a telepítési csomag (`pip install toto-models`, Python 3.12+)

## Kapcsolódó belső források

- [2026-07-14_hamel_ai_product_evals.md](2026-07-14_hamel_ai_product_evals.md), LLM-termékek eval-rétegződése (unit tesztek, model-alapú eval, trace-ek), a legközvetlenebb módszertani előzmény: a Polylane cikk ugyanannak a gondolatmenetnek a **CI-gate** irányába vitt változata
- [2026-08-21_long_horizon_agent_harness.md](2026-08-21_long_horizon_agent_harness.md), hosszú horizontú agent-harness minták, a lépéskeret és a szálkezelés témájának tágabb kontextusa
- [2026-05-27_cursor_cloud_agent_lessons.md](2026-05-27_cursor_cloud_agent_lessons.md), agent-alapú kódgenerálás tanulságai, a diff-alapú ellenőrzés korlátjának korábbi tárgyalása
- [2026-05-14_harness_as_black_box_agentfield.md](2026-05-14_harness_as_black_box_agentfield.md), a harness mint fekete doboz, a megfigyelhetőség és az állapotkövetés kérdése
- [2026-06-09_addy_osmani_loop_engineering.md](2026-06-09_addy_osmani_loop_engineering.md), a ciklus-alapú agent-működés és a lépésgazdálkodás
- [2026-09-11_arxiv_2604_08407_your_agent_is_mine_llm_router_attacks.md](../tanulmanyok/2026-09-11_arxiv_2604_08407_your_agent_is_mine_llm_router_attacks.md), az agent-láncok biztonsági rétege, a bizonyíték-alapú verifikáció másik aspektusa
- [2026-06-23_agent-native-memory-system.md](2026-06-23_agent-native-memory-system.md), agent-natív memória és az állapot perzisztálása