Kihagyás

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:

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

Kapcsolódó belső források

Vissza a tetejére