Robocikowo>ROBOCIKOWO
20 maja 2026 · 5 min lekturyHyperEyesmultimodal-search-agentsparallel-tool-calls

HyperEyes: agent, który szuka równolegle, nie seryjnie

HyperEyes: agent, który szuka równolegle, nie seryjnie

Badacze z XiaoHongShu i University of Cambridge opublikowali 8 maja 2026 pracę opisującą HyperEyes — agenta multimodalnego wyszukiwania, który przetwarza wiele bytów naraz zamiast kolejno. Na sześciu testach porównawczych wersja 30B bije najlepszy porównywalny model open-source o 9,9% przy 5,3 raza mniejszej liczbie rund wywołań narzędzi.

Najważniejsze w skrócie

  • HyperEyes-30B: +9,9% accuracy vs najlepszy open-source agent, 5,3× mniej rund narzędzi
  • Nowy benchmark IMEB (300 próbek): HyperEyes bije najlepszy drugi model o 64,0%
  • Kluczowa innowacja: UGS (Unified Grounded Search) — jedno wywołanie narzędzia obsługuje N bytów równolegle
  • Trening dwuetapowy: TRACE (nagrody na poziomie trajektorii) + OPD (korekta na poziomie tokenów z modelu 235B)
  • Kod i dane dostępne publicznie na GitHub: github.com/DeepExperienceAI/HyperEyes

Wąskie gardło seryjnego wyszukiwania

Istniejące agenty AI multimodalne mają jeden wspólny problem: gdy zapytanie dotyczy wielu niezależnych bytów (np. sześciu osób na zdjęciu), agent wywołuje narzędzia po kolei — raz na byt. Przy złożonych pytaniach prowadzi to do dziesiątek rund, narastających opóźnień i większego ryzyka błędu. Autorzy HyperEyes nazywają to „N-run bottleneck" — wąskim gardłem N przebiegów.

Porównanie z DeepEyes-V2 (wcześniejszym modelem tego samego laboratorium) dobrze ilustruje skalę problemu. Przy pytaniu wymagającym zidentyfikowania sześciu osób ze zdjęcia i znalezienia konkretnego faktu biograficznego, DeepEyes-V2 potrzebował 12 rund i i tak zwrócił błędną odpowiedź. HyperEyes wydał jedno zunifikowane zapytanie, objął wszystkich sześciu naraz i dał poprawną odpowiedź po zaledwie 3 rundach.

Jedna akcja, wiele bytów: UGS

Centralnym elementem architektury jest zunifikowana przestrzeń akcji — Unified Grounded Search (UGS). Zamiast sekwencji oddzielnych wywołań narzędzi, agent HyperEyes emituje pojedynczą akcję łączącą lokalizację wizualną (visual grounding) i wyszukiwanie dla wszystkich bytów jednocześnie. To przejście od „wyszukiwania głębiej" (seryjnie, wiele kroków) do „wyszukiwania szerzej" (równolegle, jeden krok). Wynik przekłada się bezpośrednio na efektywność: mniej tokenów zużywanych na koordynację, mniej okazji do kumulacji błędów.

Trening: TRACE + OPD

Sam pomysł na równoległą akcję to dopiero połowa rozwiązania — model musi jeszcze nauczyć się go stosować oszczędnie, bez niepotrzebnych kroków. Tu wchodzi dwuetapowy framework treningu, zwany Dual-Grained Efficiency-Aware RL.

TRACE (Tool-use Reference-Adaptive Cost Efficiency) działa na poziomie całej trajektorii. Po każdej rundzie agent ocenia sekwencję: jeśli odpowiedź była poprawna, nagroda jest pomniejszana proporcjonalnie do liczby użytych kroków narzędzi — im mniej kroków, tym wyższa premia. Próg efektywności jest przy tym stopniowo zaostrzany w kolejnych iteracjach, analogicznie do poprzeczki w skoku wzwyż. Model, który kiedyś dostawał nagrodę za 5 kroków, musi docelowo zmieścić się w 3.

OPD (On-Policy Distillation) uzupełnia TRACE o sygnał na poziomie tokenów. Mechanizm aktywuje się wyłącznie dla błędnych trajektorii — wtedy model uczeń dostaje gęsty sygnał korekcyjny z modelu nauczyciela o parametrach 235B, wyrażony jako dywergencja KL między rozkładami tokenów. Dzięki temu model nie traci wcześniej wypracowanych sprawnych zachowań, a jednocześnie poprawia błędy tam, gdzie sam sobie nie radzi.

Pseudokod algorytmu

Python
Algorithm 1: Dual-Grained Efficiency-Aware RL (TRACE + OPD)

Require: Prompts batch P; Student π_s; Teacher π_teacher; Initial reference l_t

for epoch e = 0, 1, …, E − 1 do
  for prompt q ∈ P do

    // Step 1: Rollout Sampling
    T ← τ^k(q)                          ▷ Sample rollouts from student policy
    for trajectory τ ∈ T do
      acc ← Evaluate(τ);  t_s ← TurnCount(τ)    ▷ acc ∈ {0,1}: count tool turns

    // Step 2: TRACE Reward (Trajectory-level)
    if acc == 1 then
      R_trol ← R^+ − λ_t · t_s           ▷ Reward efficiency, squeeze redundancy
    else
      R_trol ← R^−                        ▷ Penalize redundant searches
    end if

    // Step 3: OPD Distillation (Token-level)
    if acc == 0 then
      L_OPD ← KL(π_s ‖ Teacher)          ▷ Dense correction ONLY on failures
    else
                                          ▷ Protect self-explored efficient behaviors
    end if

  end for

  // Step 4: Joint Optimization & Macro-level Update
  L_final ← L_policy(R_trace) + λ_kl · L_OPD
  θ ← θ − η∇_θ L_final                  ▷ Update student policy
  l_t ← min(l_t, min(T_tol))            ▷ Tighten reference (like a high jump bar)

end for

IMEB — nowy benchmark efektywności multimodalnej

Istniejące testy porównawcze dla agentów multimodalnych mierzą wyłącznie trafność odpowiedzi. Autorzy zauważyli, że to niepełny obraz — model może być celny, ale kosztowny (wiele rund). Dlatego stworzyli IMEB (Image Multi-Entity Benchmark): 300 ręcznie przygotowanych próbek z zadaniami wymagającymi jednoczesnej identyfikacji wielu bytów na obrazie, z dziedzin humanistycznych i naukowych.

Obok samego benchmarku wprowadzili metrykę CAS (Companion Assessment Standard), która mierzy efektywność jako stosunek trafnych zwrotów informacyjnych do liczby użytych kroków narzędzi — coś w rodzaju „przydatna informacja na jeden krok". Wersja 30B HyperEyes osiąga 7,6 raza lepszą efektywność informacyjną niż modele seryjne w tej metryce.

Wyniki na sześciu benchmarkach

Na standardowych testach multimodalnego wyszukiwania HyperEyes-30B osiąga najlepsze wyniki wśród modeli open-source. Przewaga jest największa tam, gdzie liczy się efektywność przy wielu bytach — szczegóły w tabeli poniżej.

BenchmarkHyperEyes-30BHyperEyes-235BŚrednio rund narzędzi
MMSearch64,11,9
FVQA58,01,9
IMEB (wielo-bytowy)17,132,21,9
Wyniki HyperEyes na sześciu benchmarkach multimodalnego wyszukiwania (open-source SOTA)

Testy robustnosci (10 losowych permutacji kolejnosci bytow) potwierdzaja stabilnosc modelu — wyniki w sekcji „Odpornosc na kolejnosc encji” ponizej.

K (permutacja)Wynik IMEBOdchyłka od średniej
K=1…10stabilny< 1 pkt
Średnia17,1
Stabilność na IMEB przy 10 losowych permutacjach kolejności bytów (K=1…10)

Diagram techniczny

Poniższy diagram pokazuje przepływ przetwarzania w HyperEyes: od wejścia multi-entity przez UGS i równoległe wywołania narzędzi do odpowiedzi, oraz obydwa poziomy treningu (TRACE + OPD) składające się na joint loss.

MetrykaDeepEyes-V2HyperEyes-30B
Średnia liczba rund narzędzi7–101,9
Trafność na zadaniu wielo-bytowymniskawyższa
CAS (informacja / krok)1,0×7,6×
Tryb wywołania narzędzisekwencyjnyrównoległy (UGS)
Akumulacja błędu w kolejnych krokachtakznacząco mniejsza
Porównanie DeepEyes-V2 (seryjny) z HyperEyes (równoległy) na zadaniu wielo-bytowym

Dlaczego to ważne?

Większość badań nad agentami multimodalnymi skupia się na tym, żeby model był trafniejszy — więcej poprawnych odpowiedzi. HyperEyes przesuwa punkt ciężkości: trafność jest ważna, ale bez kontroli kosztu wnioskowania agent nie nadaje się do zastosowań produkcyjnych. Każde wywołanie narzędzia wiąże się z latencją, kosztem API i ryzykiem błędu akumulowanego w kolejnych krokach.

Platforma XiaoHongShu — chiński serwis łączący media społecznościowe z e-commerce, z ponad 300 milionami miesięcznych użytkowników — ma bezpośredni interes w tym, żeby wyszukiwanie wizualne działało szybko i tanio przy dużej skali. To wyjaśnia, dlaczego efektywność została potraktowana jako „first-class training objective", a nie jako opcjonalna metryka. Podejście UGS może znaleźć zastosowanie wszędzie tam, gdzie zapytania użytkowników dotyczą wielu obiektów naraz: wyszukiwanie produktów wizualnych, analiza dokumentów złożonych, pytania biograficzne, wieloentytyjne rozumowanie medyczne.

Niezależnie od samego modelu, IMEB i metryka CAS to propozycja nowego standardu oceny agentów — pomijającego słabość dotychczasowych benchmarków, które premiowały jedynie trafność, ignorując koszt jej osiągnięcia.

Co dalej?

  • Kod i dane treningowe dostępne publicznie (github.com/DeepExperienceAI/HyperEyes) — umożliwia replikację i adaptację przez społeczność open-source
  • Benchmark IMEB jest otwarty do porównań; kolejne prace mogą go rozszerzyć o zadania z większą liczbą bytów lub inne domeny (np. wideo, dokumenty wielostronicowe)
  • Autorzy sugerują, że integracja HyperEyes z systemami wyszukiwania e-commerce (np. XiaoHongShu) jest naturalnym kolejnym krokiem — choć nie podają konkretnego harmonogramu wdrożenia produkcyjnego

Źródła

Udostępnij ten artykuł