- június 22-én Onur Solmaz (közreműködők: ben burtenshaw és shaun smith) bemutatta, hogyan lehet helyi nyelvi modelleket használni az OpenClaw nyílt forráskódú adattárának (repo) hibáinak és pull requestjeinek (PR) valós idejű triázsára. A cikk célja az volt, hogy megmutassa: kis- és közepes méretű, nyílt súlyú modellek helyileg futtatva elegendő pontossággal és jelentősen jobb késleltetéssel képesek kiszűrni a fenntartók számára releváns bejegyzéseket — feltéve, hogy a rendszer biztonságosan van konfigurálva és van hozzá megfelelő hardver (a szerző például egy NVIDIA GB10-es, 128 GB egységes memóriás gépen dolgozik, „DGX Spark” néven említve).
Módszer — agentes megközelítés és korlátozott parancskörnyezet
A csapat nem egyszerűen egy statikus osztályozót használt (mint BERT-szerű modelleknél gyakori), hanem egy agent-hajtású megoldást épített, ahol a helyi modell — például gemma-4-26b-a4b vagy qwen3.6-35b-a3b — strukturált kimenettel címkéz PR-eket és issue-kat. Az agent (konkrétan a pi-harnessre épülő "localpager-agent") megkapja a PR címét, leírását és egy kivágott diff-részletet, és opcionálisan olvasó jellegű műveleteket végezhet a tárolt kódbázison.
A biztonság és determinisztika miatt a csapat nem adott teljes bash-hozzáférést a modelleknek. Ehelyett egy korlátozott, csak-olvasó parancsokat engedő shellt használnak, a reposhellt, amely például ls, find, cat, grep, rg, git status --short és hasonló parancsokat engedélyez. Így a modell képes helyben ellenőrizni csomagmetadatot vagy fájlstruktúrát (például egy extension package.json-át), de nem tud a környezetet módosítani vagy külső hálózati hívásokat indítani.
Konkrét példaként egy session során a qwen3.6-35b-a3b osztályozta az openclaw/openclaw#84621 PR-t ("Fix Kimi tool-call rewriting stop reason handling"). A modell kezdetben a coding_agent_integrations címkét fontolgatta, de a reposhell-lel végzett read-only ellenőrzés (ls, cat) feltárta, hogy a módosított útvonal az @openclaw/kimi-provider bővítményhez tartozik, így a végső címkék inference_api és tool_calling lettek, a coding_agent_integrations pedig kifejezetten kizárásra került.
Felépítés — adatfolyam és orchestration
A bejövő PR-eket és issue-kat az openclaw/gitcrawl használatával helyi tükörként kezelik; az elemek normalizálva bekerülnek a localpager saját SQLite adatbázisába. Új elem esetén a localpager létrehoz egy osztályozási feladatot; egy worker veszi át a feladatot, összeállít egy GitHub-kontekstd objektumot (cím, szöveg, címkék, szerző, állapot, opcionálisan kommentek, változott fájlok, kivágott diffek) — a modellnek így általában nincs szüksége közvetlen GitHub-hozzáférésre. A prompt ezt a kontextust kapja, majd a localpager-agent vagy használ reposhellt a kiegészítő vizsgálathoz, vagy közvetlenül ad vissza strukturált, JSON-formátumú osztályozási eredményt (final_json).
A klaszterozás után az eredmény visszakerül az SQLite adatbázisba, és a felhasználó által beállított értesítési szabályok alapján (például: értesítszen engem ezekről a témákról, de ezeket hagyja figyelmen kívül) a rendszer Discord-üzenetet küld. A címkézés maga agentikus, az értesítések determinisztikus szabályok alapján történnek, hogy csökkentsék a felesleges inferenciákat és a hibalehetőségeket.
Modellek, hardver és teljesítmény
A helyi modellek közül a szerzők gemma-4-26b-a4b és qwen3.6-35b-a3b modelleket tesztelték. A hardver egy NVIDIA GB10-os gép, amely 128 GB egységes memóriával rendelkezik, és a szerző említ egy DGX Spark néven használt kis dobozt, amely képes nagy párhuzamosságra. A gemma-t vLLM-mel és NVFP4 kvantizációval szolgáltatták, prefix cachinggel, FP8 KV cache-sel és egyéb optimalizációkkal a jobb átviteli sebesség érdekében.
A teljesítményt egy 330 soros, kézzel-kurátált értékelő készleten mérték. Minden elemre több referenciamegjelölés készült (öt annotáció: 3× GPT-5.5 és 2× Opus 4.8), és a legtöbb elfogadott címke csak konszenzus utján született meg. A kísérlet során nem kellett finomhangolni a gemma vagy qwen promptokat az alaphasználathoz. Az aggregált eredmények (közepes értékek és a gemma/qwen esetén futásonkénti szórás) a következők voltak:
-
gemma-4-26b-a4b (26B, aktív paraméter: ~4B)
- Precision: 0.716 ± 0.010
- Recall: 0.905 ± 0.004
- F1: 0.800 ± 0.008
- Exact match: 0.410 ± 0.014
- False positives: 227.0 ± 10.5
- False negatives: 60.0 ± 2.6
- Wall seconds / row: 1.41 ± 0.04
- Output tok/s per worker: 25
- Aggregált output tok/s: 402.6
- Concurrency: 16
-
qwen3.6-35b-a3b (35B, aktív paraméter: ~3B)
- Precision: 0.831 ± 0.007
- Recall: 0.818 ± 0.006
- F1: 0.824 ± 0.002
- Exact match: 0.540 ± 0.014
- False positives: 105.7 ± 6.4
- False negatives: 115.3 ± 4.0
- Wall seconds / row: 13.51 ± 0.79
- Output tok/s per worker: 50
- Aggregált output tok/s: 145.3
- Concurrency: 4
-
DeepSeek-V4-Flash (referencia, 284B, aktív paraméter: ~13B, futtatva egyszer)
- Precision: 0.938
- Recall: 0.714
- F1: 0.811
- Exact match: 0.509
- False positives: 30
- False negatives: 181
- Wall seconds / row: 144.14
- Output tok/s per worker: 13
- Aggregált output tok/s: 13
- Concurrency: 1
Ebből látható, hogy Gemma alacsonyabb késleltetés mellett jobb visszahívási arányt (recall) adott, míg Qwen nagyobb precizitást és pontosabb egyezéseket (exact match) produkált, DeepSeek pedig kevés hamis pozitívot, de túl lassú volt valós idejű használatra a tesztelt hardveren.
Fontos megjegyzés, hogy ezek a throughput- és wall-clock számok a cikkben közölt konkrét konfigurációk és optimalizációk eredményei; nem feltétlenül jelentenek abszolút maximumokat.
Valós idejű mérés és audit
A szerzők azt is bemutatják, hogyan tartják nyomon a helyi osztályozó teljesítményét: nem csak a lokális modellek futnak, hanem időnként egy SOTA felhőmodell (például GPT-5.5) is lefut az OpenClaw cron-jában kétóránként, hogy auditálja a helyi eredményeket és kiszámítsa a hamis pozitív/negatív eseteket. Az OpenClaw ügynök a sandboxolt futtatás után egy gép által olvasható fájlt frissít, egy script beolvassa a Codex/GPT-5.5 által kiosztott címkéket, és listázza a false positive/negative eseteket. Ez a periódikus auditálás kutatási céllal történt, és a cikk megjegyzi, hogy ez a folyamat költségeket jelent (például a szerző becslése szerint körülbelül 40k GPT-5.5 token/2 óra futtatásonként, ami API-árazáson néhány centbe kerül futásonként).
Mit tanulhatunk ebből?
A szerzők szerint az issue/PR triázs egy tipikus "nagy áteresztőképességű triázs" feladat, ahol érdemes megfontolni helyi agentes osztályozók használatát: gyorsak, olcsók (ha a hardver már adott) és megfelelnek a biztonsági követelményeknek, ha a hozzáférést a reposhell-szerű korlátozással szabályozzuk. A gemma-4-26b-a4b és a qwen3.6-35b-a3b jó alapot adnak az azonnali prototipizáláshoz, finomhangolás nélkül is.
A megközelítés általánosítható más területekre is, többek között hírek kategorizálására, közösségi posztok szűrésére (X / Reddit), ügyfélszolgálati feladatok triázsára, moderációs fellebbezések kezelésére és kutatási figyelésre (pl. arXiv témák szűrése).
Záró gondolatok
A poszt bemutat egy gyakorlati "Pi + korlátozott shell + final_json" receptet agentikus osztályozáshoz helyben futó modellekkel. A tapasztalatok szerint a kezdeti lokális rendszer zajos lehet (túl sok irreleváns címke), ezért érdemes nagyobb modelleket és aprólékos címkedefiníciót használni az elfogadható értesítési jelleg eléréséhez. A helyi és a felhő alapú modellek kombinálása auditálási fázisként praktikus átmeneti stratégia a gyakorlatban.
Függelék: Footnotes és megjegyzések
- A blogbejegyzés megjegyzi: a „free” jelző itt a sörre vonatkozó értelemben értendő — tehát a módszer ingyenes lehet, ha a hardver már rendelkezésre áll; az elektromos áram költségeit és a kezdeti hardvert nem számolják ide.
- A szerzők korábban DeepSeek-V4-Flash modellt is használtak címkézéshez, de végül nem az lett a fő helyi agent, mert nem volt elég determinisztikus és túl nagy volt a latenciajukon futtatva.
- A teljes témalista és konfigurációk az OpenClaw projekten belül érhetők el (a poszt hivatkozik a konfigurációs fájlokra).
