Rozwój agentów AI w repozytoriowych drzewach RTL NVIDII
NVIDIA Research zaprezentowała HORIZON 4 lipca 2026 roku jako samodzielną platformę do rozwoju agentów AI w projektowaniu sprzętu, traktującą pracę nad RTL jako ewolucję kodu na poziomie repozytorium, a nie jednorazową generację. To istotne, ponieważ przesuwa projektowanie agentów z tworzenia wiarygodnego kodu na akceptację wykonywalną, gdzie commity w git pełnią rolę twardych punktów kontrolnych. Według podsumowania artykułu na MarkTechPost, system osiągnął 100% ukończenia wszystkich ocenianych zestawów benchmarkowych RTL.
HORIZON NVIDII zamienia RTL w pętlę agenta natywną dla git
HORIZON postrzegam raczej jako historię o przepływie pracy niż o modelu. Zespół badawczy z NVIDIA Research nie twierdzi, że większy model nagle rozwiązał projektowanie sprzętu. Mówią, że jednostka pracy była źle dobrana. Zamiast prosić model o gotową odpowiedź w Verilogu, HORIZON umieszcza zadanie w izolowanym drzewie roboczym git, edytuje pliki, uruchamia ewaluatory i zapisuje postęp dopiero po pozytywnym wyniku bramki.
To rozróżnienie ma znaczenie dla zespołów półprzewodnikowych i EDA, ponieważ wiarygodny RTL jest tani, ale RTL przechodzący testy jest drogi. Moduł może wyglądać poprawnie i nadal zawieść w zachowaniu resetu, obsłudze szerokości bitów lub przypadkach brzegowych symulatora. HORIZON czyni repozytorium, a nie prompt, powierzchnią operacyjną.
Główny wynik jest mocny: 100% ukończenia w ChipBench, RTLLM, Verilog-Eval i CVDP w artykule o HORIZON na arXiv, przy czym w artykule zaznaczono, że jeden pozostały przypadek wynikał z wady narzędzia benchmarkowego, a nie z błędu agenta. Ale ważniejsze stwierdzenie jest architektoniczne: pętla oparta na informacji zwrotnej z wykonywalnych testów.
Jak parafrazuje źródłowe podsumowanie, „agentyczne projektowanie sprzętu nie jest rozwiązane”. Ta ostrożność jest ważna. Artykuł raportuje kamień milowy, a nie zamknięcie tematu.
Jak wiązka Markdown staje się pakietem projektowym
Wejściem dla operatora jest uporządkowana wiązka Markdown z czterema częściami: cel, wskazówki domenowe, specyfikacja ewaluatora i predykat akceptacji. Podoba mi się to podejście, ponieważ zmusza zespół do spisania, co oznacza sukces, zanim agent zacznie edytować kod.
W praktyce wiązka staje się pakietem projektowym zawierającym politykę agenta, wykonywalny ewaluator, regułę akceptacji, zachowanie wersjonowania i umiejętności domenowe. Dla RTL ewaluator może obejmować kompilację, symulację, asercje i ekstrakcję pokrycia. Innymi słowy, HORIZON nie tylko generuje kod; generuje kod w środowisku, które może go odrzucić.
To użyteczny wzorzec dla niestandardowych agentów AI poza sprzętem. W jednym z wdrożeń dla klientów największym trybem awarii nie była jakość modelu. To brak wykonywalnego warunku przejścia. Jeśli jedynym kryterium jest „wygląda dobrze”, agent zacznie dryfować. Jeśli kryterium brzmi „przechodzi ten zestaw testów”, pętla staje się zarządzalna.
Artykuł na arXiv zawiera też ważną uwagę implementacyjną: to samo gniazdo używane do symulacji w RTL mogłoby w innych domenach pomieścić testy jednostkowe, proweratory twierdzeń, profilery lub narzędzia syntezy. Dlatego te badania są równie istotne dla szerszych integracji AI w przedsiębiorstwach co dla zespołów chipowych.
Co ewolucja na poziomie repozytorium oznacza dla zespołów sprzętowych
Oto część, którą spodziewam się, że liderzy inżynieryjni przejmą najpierw. Git w HORIZON nie jest tylko logowaniem. To płaszczyzna sterowania. Różnice pokazują proponowaną zmianę stanu, commity oznaczają zaakceptowane punkty kontrolne, a notatki zachowują dowody z ewaluatora. To operacyjnie czystsze niż doklejanie osobnego magazynu pamięci do stosu agenta i liczenie na jego spójność.
Widziałem projekty automatyzacji przepływów AI kończące się niepowodzeniem, ponieważ każde uruchomienie zostawia częściowe edycje, nieśledzone próby i niejednoznaczne wyniki testów. Pętla HORIZON jest bardziej rygorystyczna: sprawdź zmiany w stage, uruchom ewaluator, zacommituj jeśli przechodzi, zaloguj jeśli nie. To ułatwia rollback, odtworzenie i audyt.
Dla zespołów sprzętowych zastosowania w krótkim terminie są dość bezpośrednie:
- generowanie RTL ze specyfikacji w języku naturalnym
- uzupełnianie kodu w istniejących modułach
- modyfikacja i ponowne wykorzystanie modułów
- generowanie bodźców testowych, checkerów i asercji
- debugowanie na podstawie informacji zwrotnej z symulatora
Te kategorie ściśle odpowiadają kategoriom w CVDP i RTLLM-2.0. Odpowiadają też temu, jak agenci automatyzacji AI są wdrażani w rzeczywistych środowiskach inżynieryjnych: nie jako uniwersalni kopiloty, lecz jako wykonawcy w zamkniętych pętlach.
Jest też kąt ekonomiczny. Raport podaje, że dziewięć kategorii CVDP zużyło 203,9 miliona tokenów, czyli 97,1% całkowitego zużycia tokenów, podczas gdy około 91% wszystkich tokenów stanowiły dane wejściowe z cache'u. To sugeruje, że problem kosztów się przesunął. Gdy poprawność jest wysoka, zespoły przestają dyskutować o tym, czy agent potrafi rozwiązać zadanie, a zaczynają pytać, ile iteracji potrzeba, by zrobić to tanio.
Skąd pochodzą zyski benchmarkowe — i gdzie nie pochodzą
Liczba 100% wymaga kontekstu. Skumulowany wskaźnik przejścia HORIZON w pierwszej iteracji wyniósł 47,8%, a nie 100%. Końcowy wynik osiągnięto dzięki iteracyjnej naprawie. To cecha, nie słabość, ale zmienia sposób, w jaki benchmarkowałbym rozwój agentów AI wewnętrznie.
Jeśli zespół śledzi tylko Pass@1, przeoczy to, do czego ten system jest zbudowany. HORIZON jest zaprojektowany do odroczenia części debugowania na późniejsze iteracje. Na łatwiejszych zestawach, takich jak RTLLM-2.0 i Verilog-Eval-v2, zbieżność nastąpiła w ciągu dwóch iteracji. Na trudniejszych kategoriach ogon był długi. Generowanie checkerów CVDP CID 013 zaczęło się od 3,8% i wspięło na 100% w iteracji 19. Uzupełnianie kodu CID 002 potrzebowało 82 iteracji i 56,0 miliona tokenów.
To rozpiętość to prawdziwy sygnał operacyjny. Niektóre zadania są niemal gotowe do rutynowej automatyzacji. Inne są technicznie rozwiązywalne, ale na tyle kosztowne, że przed wdrożeniem w skali chciałoby się lepszą architekturę integracji AI.
Myślę też, że szczegół stałego modelu ma znaczenie. Artykuł podaje, że GPT-5.3 pozostał niezmienny przez całą kampanię. HORIZON rejestruje przejścia stanów przy użyciu języka półmarkowskiego, ale nie trenuje nowej polityki RL w trakcie działania. Oznacza to, że poprawa wydajności wynika z projektu pętli, dyscypliny ewaluacji i pamięci repozytorium, a nie z aktualizacji wag online.
Dla zespołów korporacyjnych rozpatrujących usługi automatyzacji przepływów AI, to przenośna lekcja. Lepsze pętle często pokonują więcej majsterkowania przy modelu.
Ograniczenia: przejście testu nie jest tożsame z rozwiązaniem projektu
To moment, w którym artykuł jest zaskakująco uczciwy. Przejście widocznego testu nie jest tożsame z spełnieniem pełnego zamiaru projektowego. Autorzy wprost wskazują na ryzyko reward hackingu i over-solving. Jeśli ewaluator widzi tylko część specyfikacji, agent może optymalizować pod widoczny test, a nie rzeczywiste wymaganie.
Ten problem nie jest unikalny dla RTL. Pojawia się w repozytoriach oprogramowania, automatyzacjach wsparcia i agentach narzędzi wewnętrznych. Jeśli predykat akceptacji jest płytki, metryka sukcesu też będzie płytka.
Innym ograniczeniem jest czas realizacji. HORIZON wydaje się najsilniejszy tam, gdzie informacja zwrotna jest stosunkowo szybka: kompiluj, symuluj, asercja, powtórz. Artykuł zauważa, że pętle zorientowane na PPA mogą trwać dni lub tygodnie. W tym ustawieniu ta sama struktura natywna dla repozytorium może wciąż pomóc, ale ekonomia i logika planowania zmieniają się całkowicie.
Co więc zespoły powinny obserwować dalej? Po pierwsze, czy kolejne prace dodają ukryte testy, losowe kontrole i weryfikację formalną, by zmniejszyć reward hacking. Po drugie, czy te pętle natywne dla repozytorium zachowają swoją dyscyplinę, gdy ewalutory staną się wolniejsze, szersze i droższe niż dzisiejsze zestawy benchmarkowe.
Polecane lektury
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation