Mesterséges intelligenciával generált szöveg

AI-ügynökökkel fejlesztett valós idejű endoszkópos eszközszegmentáció a NVIDIA Holoscanon

A központi szereplő a NVIDIA Holoscan platform és kísérő tárolója, a HoloHub, amelyek segítségével egy AI kódolóügynök mentén valósítottak meg egy valós idejű endoszkópos eszközszegmentációs alkalmazást.

AI Newsroom · 2026. augusztus 19. · 5 perc olvasás

Az NVIDIA bemutatja, hogyan lehet AI kódolóügynökökkel, az engineerrel közös iteratív munkafolyamatban egy valós idejű endoszkópos eszközszegmentációs alkalmazást fejleszteni a Holoscan platformon. A fejlesztés során a HoloHub példák, dokumentáció és a Holoscan CLI szolgáltatták a megosztott eszközöket és futtatási felületet, így az ügynök és a mérnök ugyanazokat a parancsokat használva dolgozhatott.

Cél és kiinduló állapot

A cél egy end-to-end endoszkópos eszközszegmentációs alkalmazás létrehozása volt: valós idejű inferencia, a maszkok élő megjelenítése és statisztikai elemzések renderelése. A fejlesztés alapjaként újrahasznosították a MONAI endoscopic tool segmentation modellt és egy Holoscan minta videót, és meggyőződtek arról, hogy a meglévő monai_endoscopic_tool_seg alkalmazás helyben fut. A fejlesztői környezethez az ügynökök az alábbiakat kapták:

Holoscan CLI végrehajtási jogosultsággal (./holohub wrapper)
HoloHub tárház dokumentációval (agents.md) és példákkal
HoloHub fejlesztési készségek (például holohub-app-lifecycle és holohub-debug-build-run)

Módszer: iteratív, ellenőrizhető lépések

A teljes cél kisebb, felülvizsgálható iterációkra lett bontva, például: a környezet megfelelő-e; a modell és videó futtatható-e külön alkalmazásban; a vizualizáció hasznos információt ad-e; az átfutási idő ismételten mérhető-e; a renderelési áteresztő képesség javítható-e funkciók visszaesése nélkül.

Iteráció 1 — Minimális működő alkalmazás

Az első prompt a kívánt végeredőt írta le, korlátozva a modell- és adatújrahasznosítást: hozzon létre egy új Python HoloHub alkalmazást, használja a MONAI modellt és a minta adatokat, jelenítse meg a modellek által előállított maszkot, lefedettséget és idősorokat HoloViz réteggel, ne módosítsa a modell súlyait és a minta videót hozzon működőképessé. Az ügynök átnézte a releváns példákat (monai_endoscopic_tool_seg, endoscopy_tool_tracking, surgical_scene_recon), generálta a projektvázat ./holohub create paranccsal, implementálta az alkalmazás gráfját, futtatási módjait, teszteket és dokumentációt, majd ./holohub run-nal felépítette és elindította az alkalmazást. A létrejött alkalmazás összekapcsolta a videólejátszót, előfeldolgozást, TensorRT inferenciát, postprocesszort, telemetriát és HoloViz overlay-t; minden képkockán lefutott az inferencia és a maszk utófeldolgozása. Az ügynöki feldolgozási idő kb. 40 perc volt. A fejlesztő ugyanazon CLI-vel ellenőrizte a futó alkalmazást: ./holohub run endoscopy_tool_segmentation_dashboard visual --language python. A vizuális felülvizsgálat után világos lett, hogy az overlay mérőszámai tisztább megjelenítést igényelnek.

Iteráció 2 — Ismételhető benchmarking

A második iteráció a vizuális demóból ismételhető mérési eszközt tett: bővítették a mérőszámokat (eszközterület, maszk mozgás, temporális IoU stabilitásra, élentrópia, FPS, körbefoglaló doboz pozíció) és eltávolították az állandó értékeket. Hozzáadtak egy benchmark módot, amely tényleges késleltetést rögzít és Pythonban ábrázolja az eredményeket, exportálva a build mappába, valamint interaktívan megjelenítve, ha a környezet támogatja. Az ügynök három futtatási módot hozott létre, amely a Holoscan CLI-vel felfedezhető és futtatható:

visual: interaktív teljes lejátszás
smoke: gyors, 60 képkockás headless felvétel
benchmark: 300 képkocka offscreen feldolgozása és mérések exportja A benchmark a Holoscan Data Flow Trackinget használta a videólejátszótól az előfeldolgozáson, inferencián, telemetrián, offscreen HoloViz-en át a renderelt-keret sinkig. Az ügynöki feldolgozási idő kb. 20 perc volt.

Iteráció 3 — Latencia vizsgálata és optimalizálás

A harmadik prompt azt vizsgálta, hogy a mélytanuló modell minden képkockán fut-e, és milyen lehetőségek vannak a késleltetés csökkentésére. Az ügynök megerősítette, hogy az inferencia még mindig minden képen lefutott. Bár mérlegelte a maszkok szomszédos képeken való újrahasznosítását, végül a kisebb kockázatú dashboard-overhead eltávolítását választotta:

újrahasznosította a HoloViz input specifikációkat és statikus koordináta tensorokat, miközben a szöveget és dinamikus geometriát frissítette minden képkockán
a 10-értékű GPU->host telemetria másolását aszinkron módon két pinelt pufferben végezte és a korábbi befejezett értékekkel renderelt Összehasonlítva az első implementációval, az optimalizált verzió gyorsabb lett minden öt mért futásban. A mérési eredmények:
Renderelt áteresztő képesség: 204.0 FPS -> 306.9 FPS (50.5% növekedés)
Átlagos alkalmazás-út latencia: 4.891 ms -> 3.247 ms (33.6% csökkenés)
P95 alkalmazás-út latencia: 6.273 ms -> 4.554 ms (27.4% csökkenés) Az ügynöki feldolgozási idő ehhez kb. 30 perc volt.

Zárás és átadás

A végső kézbesítésnél az ügynök elkötelezte a megvalósítást és megőrizte a benchmark logokat. A fejlesztők újrafuttatták az alkalmazást és a teszteket, ellenőrizték az ábrákat és a headless teszteredményeket. A commit hash és a függőségi verziók megőrzése ./holohub env-check és ./holohub env-info paranccsal történt.

Ablációs vizsgálat: milyen erőforrások számítanak?

A szerzők összehasonlították ugyanazzal a kódolóügynökkel és sandbox környezettel három konfigurációt; a vizsgálat utolsó futtatása Aug. 1-én történt, Codex 0.146.0 és GPT-5.6 Sol mellett. Eredmények:

CLI + skills + docs/examples: ügynöki feldolgozási idő 40 perc, tokenhasználat 11M, eredmény: külön alkalmazás standard Holoscan operátorokkal
CLI + docs/examples (nincs skills): feldolgozás 65 perc, 20M token; az ügynökök több próbálkozást igényeltek, többet használtak generikus Bash eszközöket és néha felesleges host-oldali telepítéseket végeztek
docs/examples (nincs agents.md, nincs skills): feldolgozás 40 perc, 15M token; a kód minősége alatta maradt (például a 3rd party modell konfigurációja helytelenül beágyazva, Dockerfile nem használta a HoloHub alapképet, és a Holoscan optimalizált operátorai nem kerültek kihasználásra — emiatt ez a verzió 2.6x lassabb volt) A kombinált CLI + skills + docs/examples konfiguráció adta a leghatékonyabb és leggazdaságosabb fejlesztési élményt.

Következtetések

A bemutatott kooperatív fejlesztési ciklus egy mérhető prototípust eredményezett: az alkalmazás end-to-end fut, több futtatási móddal és automatizált tesztekkel, a modell súlyainak megőrzésével és reprodukálható benchmark adatokkal. A fő tanulság, hogy a megosztott CLI műveletek, a projekt-specifikus skills és a példadokumentáció együtt teremtenek egy hatékony mérnök–ügynök együttműködést; a fejlesztő a célok meghatározására, korlátozások felállítására, és a bizonyítékok értékelésére koncentrálhat.