Kwestionowanie Agent Stack: magazyny wektorowe, hipergrafy i zadania kodowania

Popyt na dodawanie coraz więcej

Przeczytajcie materiały z tego roku na temat agentów AI i jedna rzecz rzuca się w oczy ponad wszelkimi indywidualnymi twierdzeniami: porady prawie zawsze sugerują dodanie czegoś nowego – warstwy pamięci, grafu, frameworku do orkiestracji, pipeline’u do wyszukiwania z trzema etapami ponownego sortowania. Więcej agentów do nadzorowania tych, które już masz. U podstaw tego stanowiska leży ciche przekonanie, że rozwiniętość oznacza postęp, a system, który nie robi nic bardziej zaawansowanego niż sześć miesięcy temu, pozostaje w tyle.

Znaczna część tego zestawu została prawdopodobnie stworzona i broniona przez każdego, kto czyta to tekst. Dlatego warto zatrzymać się na niewielkiej grupie argumentów, które twierdzą coś przeciwnego: skomplikowana funkcja, którą dodałeś, najprawdopodobniej nie zasłużyła na swoje miejsce. Większość kontrowersyjnych artykułów technologicznych to po prostu przekonywanie w odwrotnej formie – równie pewne siebie, ale równie słabo uzasadnione dowodami. Te trzy przypadki różnią się tym, że każdy z nich opiera się na czymś sprawdzalnym, czy to wyniku testów wydajności, dowodzie strukturalnym, czy prostym opisie tego, jak wygląda dzień pracy danej osoby. Ten standard obowiązuje poniżej, a także w odniesieniu do każdego zestawu, włączając w to twój własny.

Każdy z tych przypadków to sytuacja, w której branża dążyła do większej struktury, mimo że prawdziwy problem leżał gdzieś w mniej oczywistym miejscu.

Pierwszy przypadek: pamięć agentów i magazyny wektorowe

Pamięć agenta w magazynie wektorowym zazwyczaj jest gotowa w ciągu około pół minuty. Ktoś zauważył, że agent powinien przechowywać dane między sesjami, i powstała odpowiednia procedura: wstawienie danych, ich przechowanie oraz odzyskiwanie na podstawie podobieństwa. Wszystkie tutoriale działają w ten sposób, więc stało się to standardem, a nikt nie sprawdzał go w porównaniu z czymś prostszym.

Jeden z artykułów z tego roku przeprowadził takie testy. W teście LoCoMo zestaw bazowy składający się z foldera plików tekstowych i narzędzia grep osiągnął lepsze wyniki niż kilka profesjonalnych produktów do przechowywania pamięci. Porównanie nie było sfabrykowane. Systemy wykorzystujące wstawianie danych, wyszukiwanie na podstawie podobieństwa, a czasami także pamięć grafową, przegrały z rozwiązaniem, które wymaga całego popołudnia na konfigurację.

Po ponownym przemyśleniu wyjaśnienie wydaje się jasne. Wyszukiwarka podobieństw znajduje odpowiedzi, ale nie rozumuje. Dobrze radzi sobie z wybieraniem tekstu o znaczeniu zbliżonym do zapytania. Słabo radzi sobie z kwestiami związanymi z pamięcią, takimi jak rozpoznawanie, że fakt sprzed trzech tygodni został zastąpiony tym z wczoraj, lub że dwie zapisane informacje są sprzeczne i jedna musi przeważyć. Indeks nie ma pojęcia o czasie ani o konieczności korekt, więc zwraca najbliższe wektory i pozostawia modelowi zadanie zauważenia, że dwa z pięciu najważniejszych wyników są ze sobą sprzeczne.

Drugi problem dotyczy znajomości tematu, a nie umiejętności. Modele zostały wytrenowane na ogromnych ilościach materiałów dotyczących pracy z plikami: otwierania, wyszukiwania, edytowania, wyświetlania folderów, analizy importów. Pliki są bliskie naturalnemu materiałowi używanemu w danych treningowych modeli, a pętla z grep w połączeniu z odczytem plików wykorzystuje to bezpośrednio. Natomiast API do zapytań wektorowych dostarczane przez producenta to coś, czego model musi nauczyć się używać skutecznie w ramach własnego okna kontekstowego, przy niewielkim wcześniejszym kontakcie z tym narzędziem. W ten sposób umiejętność, którą model już posiada, jest zastępowana inną, którą musi nabyć w trakcie wykonywania zadania, co dodatkowo powoduje opóźnienia w procesie embedowania i wyszukiwania.

Przewodnik decyzyjny dotyczący obu opcji, przedstawiony obok siebie, wygląda następująco.

WHEN A FILESYSTEM + GREP BASELINE IS ENOUGH        WHEN YOU ACTUALLY NEED A VECTOR STORE
------------------------------------------------   ------------------------------------------------
Single-agent or small-team memory                  Retrieval across a corpus too large to
                                                    fit or scan in context at all
Facts that change over time and need               Cross-document semantic search where
correction, not just accumulation                  keyword overlap is genuinely weak
Memory the model itself writes,                    Centralized memory shared by many agents
manages, and re-reads in its own loop               that needs access control and auditing
Debuggable state, plain text you can                Multi-hop or relational reasoning across
open, diff, and edit by hand                        thousands of entities where similarity
                                                     search is doing real narrowing work

Jak wygląda pętla oparta na plikach

„Po prostu użyj plików” brzmi niejasno, dopóki nie chodzi o kod. Ta wersja nie wymaga żadnej usługi hostowanej.

import os
import subprocess
from datetime import datetime
MEMORY_DIR = "agent_memory"
def write_memory(topic: str, content: str) -> str:
    os.makedirs(MEMORY_DIR, exist_ok=True)
    path = os.path.join(MEMORY_DIR, f"{topic}.md")
    timestamp = datetime.utcnow().isoformat()
    with open(path, "a", encoding="utf-8") as f:
        f.write(f"\n## {timestamp}\n{content}\n")
    return path
def recall(query: str) -> str:
    # ripgrep if you have it, grep -r works fine too
    result = subprocess.run(
        ["rg", "-i", "-C", "2", query, MEMORY_DIR],
        capture_output=True, text=True
    )
    return result.stdout or "no matches"
def list_topics() -> list[str]:
    if not os.path.isdir(MEMORY_DIR):
        return []
    return [f[:-3] for f in os.listdir(MEMORY_DIR) if f.endswith(".md")]

Podaj modelowi te trzy funkcje jako narzędzia i pozwól mu zdecydować, kiedy zapisać dane, kiedy wyszukać informacje oraz kiedy załadować cały plik z krótkim tematem. Rezultatem jest pamięć bez kosztów związanych z embedowaniem, bez bazy danych do utrzymywania czy opłacania, a także z możliwością otwarcia stanu w dowolnym edytorze w przypadku problemów. Gdy ten podejście w końcu się wyczerpie, przyczyna będzie konkretna – na przykład zbyt duży zbiór danych, który nie da się szybko przeszukać, lub pytanie wieloetapowe, na które wyszukiwanie według słów kluczowych nie może odpowiedzieć. To uzasadnia użycie magazynu wektorowego znacznie lepiej niż kopiowanie instrukcji z tutoriali.

To wszystko nie oznacza, że bazy danych wektorowych nie powinny istnieć. Oznacza to jedynie, że nie należy się do nich uciekać, zanim nie sprawdzi się nudna baza odniesienia. Najpierw wypróbuj pełny kontekst, system plików wraz z narzędziem grep, a produkt z płatną pamięcią przyjmij tylko wtedy, gdy znacząco przewyższy tę bazę odniesienia, aby pokryć jego koszt oraz stratę możliwości debugowania. Większość pamięci agentów nigdy nie musi osiągać takiego poziomu.

Przypadek drugi: hipergrafy w RAG

W zeszłym roku standardem była baza danych wektorowych. W tym roku jest to RAG oparte na grafach, a hipergrafy pojawiają się wtedy, gdy zespół uważa, że zwykły graf wiedzy nie jest w stanie wystarczająco oddać określonych relacji. Ten przypadek wydaje się rozsądny. Zwykły krawędź łączy dwa węzły, ale wiele faktów obejmuje większą liczbę uczestników. Weźmy na przykład zatwierdzenie wydatku: jedna osoba podpisuje raport kolegi, który jest pokrywany z kwartalnego budżetu marketingowego, w imieniu zespołu finansowego. To już pięć stron w jednym fakcie. Jeśli próbujemy przekształcić to w pary, albo stracimy charakter pojedynczego zdarzenia, albo fakty rozpadną się na kilka binarnych krawędzi, które zapytania muszą ponownie połączyć. Hiperkrawędź łączy dowolną liczbę węzłów jednocześnie, więc wydaje się to najbardziej wiernym sposobem przechowywania takich faktów, i zespoły tworzą systemy RAG oparte na hipergrafach, oczekując, że to poprawi dokładność wyszukiwania.

Inny artykuł sprawdził to przypuszczenie na podstawie kodu źródłowego pracy o hypergrafach RAG, a nie jej streszczenia, i odkrył coś niemal komicznego. HyperGraphRAG, stworzony w celu promocji rdzennych hiperkrawędzi, przechowuje wszystko w zwykłej bazie danych grafowych z binarnymi krawędziami. Sami autorzy pokazują, że przekształcenie każdej hiperkrawędzi w kilka binarnych krawędzi wokół ustandaryzowanego węzła reprezentującego daną sytuację nie powoduje żadnych strat, dzięki czemu każdą z tych form można dokładnie odbudować na podstawie drugiej.

To szczegół decyduje o całym rozumowaniu. Załóżmy, że naturalny hiperbrzeg oraz ucieleśniony klastr brzegów binarnych mają dokładnie tę samą strukturę incydencji, a jeden z nich może bez trudu odtworzyć drugi. W takim przypadku wybór między nimi nie ma żadnych konsekwencji modelowych i sprowadza się jedynie do wyboru formatu przechowywania. Jeden z komentatorów zwięźle podsumował matematykę: obie formy reprezentują tę samą strukturę incydencji, a szerokość hiperdrzewa zmienia się o stałą tylko wtedy, gdy liczba argumentów jest ograniczona. To właśnie szerokość hiperdrzewa określa, jak kosztowna jest zapytanie. Liczba skoków nie ma na to wpływu, podobnie jak liczba uczestników umieszczonych w jednym brzegu. Przekonwertuj swoją reprezentację, przesuń tę wartość o stałą, utrzymuj każdy fakt przy ograniczonej liczbie uczestników (pięć osób zatwierdzających wydatek, a nie pięćset), a trudność zapytania pozostanie taka sama.

Dlaczego to myli ludzi

To błąd, który łatwo popełnić. Liczba skoków wydaje się naturalna, ponieważ większa liczba węzłów pomiędzy pytaniem a odpowiedzią sugeruje trudniejsze zapytanie. Szerokość hiperdrzewa jest znacznie mniej intuicyjna – należy do teorii zadowalania ograniczeń i złożoności zapytań i różni się od liczby skoków w sposób, który nie będzie widoczny bez dokładniejszego przyjrzenia się. Można dodać strukturę, która zmniejsza liczbę skoków dla konkretnego zapytania, nie wpływając lub jedynie lekko negatywnie wpływając na klasę złożoności, do której należy to zapytanie. Przykłady zastosowania przedstawione w artykule mogą wyglądać imponująco, ale nadal nie ujawniają nic o miarze, która rządzi przypadkiem ogólnym.

Zanim zdecydujemy się na zwykły graf, graf ustrukturyzowany lub specjalistyczny magazyn hipergrafów, taka porównanie jest pomocne.

REPRESENTATION          WHAT IT ADDS                     WHAT IT ACTUALLY CHANGES
---------------------   -------------------------------  --------------------------------
Plain binary graph       Simplest to build and query      Baseline; loses atomicity of
                         with standard graph tooling      multi-participant facts
Reified binary graph     Recovers atomicity via an        Same incidence structure as a
(event node + roles)     explicit "event" node             hyperedge; hypertree width
                                                            shifts by a constant only
Native hypergraph        Hyperedges as first-class         No reduction in query
store                    objects, arguably cleaner          complexity class over a
                         to write against                   reified graph; new storage
                                                             engine to run and maintain

To nie czyni struktury graficznej bezużyteczną w RAG. Wyszukiwanie relacyjne wieloetapowe rzeczywiście odnosi korzyści z grafów w porównaniu z prostym wyszukiwaniem wektorowym, i nikt temu nie zaprzecza. Kwestia dotyczy dodatkowego kroku od grafu do hipergrafu. Gdy dowód zastąpi argumentację, taki krok pozwala na stworzenie bardziej uporządkowanych modeli danych, wprowadza nowy rodzaj infrastruktury do obsługi i nie wpływa na to, czy zapytania są szybkie, czy wolne. Jeśli funkcja wyszukiwania jest słaba, rozwiązaniem opartym na dowodach jest zazwyczaj lepsza konstrukcja grafu lub bardziej inteligentna strategia wyszukiwania w już istniejącym grafie, a nie bardziej egzotyczny typ krawędzi.

Przypadek trzeci: jaka naprawdę jest praca starszego inżyniera

Oba poprzednie przypadki dotyczą architektury wyszukiwania. Ostatni różni się, ponieważ nie chodzi o wybór narzędzia, lecz o to, z czego składa się praca starszego inżyniera.

Kierownik techniczny prowadzący zespół pięciu osób w firmie liczącej ponad tysiąc pracowników napisał, że sztuczna inteligencja nie może wykonać 95% jego obowiązków. Zaczyna od tego, co brzmi jak ustępstwo: pisanie kodu zajmuje zdecydowanie najmniejszą część jego czasu. Jego zespół działa według zasady „ty to budujesz, ty to uruchamiasz”, co oznacza, że obsługę systemów pełnią jego własni inżynierowie, a nie oddzielna grupa operacyjna, która mogłaby traktować produkcję jako sprawę kogoś innego. Jego poranek zaczyna się o 8:30 od przeglądania wniosków o włączenie kodu do projektu. Kod, który przychodzi – w dużej mierze napisany przez agenty sztucznej inteligencji – jest wyraźnie lepszy od tego, który przeglądał dwa lata wcześniej. Nie kwestionuje faktu, że sztuczna inteligencja potrafi pisać dobry kod. Pełnie to akceptuje, a następnie zauważa, jak mało to zmienia w pracy, którą faktycznie wykonywać musi.

To kwestionuje powszechnie przyjęte założenie w rozważaniach na temat stosów agentów, mianowicie że to właśnie możliwości określają tempo automatyzacji. Jeśli model generuje poprawny kod, to według tej logiki programowanie przestaje wymagać udziału człowieka, a automatyzacja zadania odpowiada temu etapowi, w którym tworzony jest kod. Lider techniczny twierdzi, że to założenie nigdy nie było prawdziwe, a sztuczna inteligencja jedynie ujawnia istniejące błędy. Jego praca nie polegała głównie na pisaniu kodu – chodziło przede wszystkim o koordynację: wybór tego, co należy stworzyć i w jakiej kolejności, negocjacje dotyczące zakresu z osobami o sprzecznych priorytetach, sprawdzanie i popieranie decyzji podjętych przez innych, obsługa urządzeń komunikacyjnych, mentoring młodszych inżynierów oraz pośredniczenie pomiędzy żądaniami interesariuszy a tym, co system może bezpiecznie obsłużyć. Żadna z tych czynności nie stanowi zadań związanych z programowaniem.

To może być najbardziej przeoczony aspekt w dyskusjach na temat agentów w tym roku, ważniejszy niż jakikolwiek wskaźnik, ponieważ wyjaśnia, dlaczego znacznie lepsze wyniki w testach kodowania oraz o wiele łatwiejsza praca nie idą w parze u wielu doświadczonych inżynierów, nawet u entuzjastycznych użytkowników codziennych. Wzrost wyników SWE-bench z jednocyfrowych wartości do poziomu siedemdziesięciu w ciągu zaledwie kilku lat to rzeczywiście duży krok naprzód. Nie oznacza to jednak 70% mniej pracy, ponieważ tworzenie kodu nigdy nie stanowiło 70% obowiązków, szczególnie gdy rola obejmuje również zmiany w trybie on-call, plan rozwoju oraz prośby o aktualizacje kodu.

Jedna uwaga: trzeci punkt ma mniej oczywisty związek z pozostałymi ustawieniami niż pierwsze dwa. Twierdzenia dotyczące baz danych wektorowych i hipergrafów można sprawdzić za pomocą benchmarków lub dowodów. Podział tygodnia starszego inżyniera pomiędzy koordynację a pisanie kodu zmienia się w zależności od wielkości firmy, dojrzałości zespołu, tego, czy dodatkowe obowiązki wynikają z dysfunkcji, czy są istotne dla funkcjonowania, oraz od stopnia doświadczenia samego pracownika. Zespół pięciu osób w firmie liczącej tysiąc pracowników, która stosuje politykę „stwórz i uruchom”, to jeden rodzaj pracy i nie reprezentuje wszystkich stanowisk inżynierskich. Kierunek korekty wydaje się nadal ogólnie słuszny. Możliwości agentów ograniczają stopień automatyzacji procesu pisania kodu, a prawie nic nie mówią o aspekcie koordynacji, który nigdy nie zależał od szybkości pisania ani jakości kodu.

Wspólny wzorzec

Umieść trzy tezy obok siebie, a lekcja nie dotyczy konkretnie baz danych wektorowych, hipergrafów ani możliwości sztucznej inteligencji. Chodzi o różnicę pomiędzy tym, gdzie dane pole uważało, że znajduje się wąskie gardło, a tym, gdzie ono faktycznie się znajdowało.

CASE                WHERE COMPLEXITY WAS ADDED         WHERE THE REAL BOTTLENECK WAS
------------------  ----------------------------------  --------------------------------
Agent memory         Vector embeddings, similarity       Whether the model can use a
                     search, sometimes a graph layer      retrieval method it already
                     on top of that                        has deep fluency with
RAG structure         Native hyperedges, a new             The complexity class governing
                      storage engine, more                  query cost, which the fancier
                      elaborate graph modeling               structure barely touches
"How much of the      An assumption that model             Whether the job was ever
job gets automated"   capability alone predicts             mostly about the thing the
                       the automatable fraction              model is good at

Żadna z tych zaawansowanych opcji nie jest błędna ze względu na swoje istnienie. Bazy danych wektorowych mają rzeczywiste zastosowania, hipergrafy mogą okazać się przydatne w obszarach, których nikt jeszcze nie odkrył, a agenci AI rzeczywiście ułatwiają pracę inżynierską, co przyznaje lider technologiczny. Błędem było pominęcie pytania, czy dodatkowa złożoność adresuje rzeczywisty wąskie gardło, czy tylko to, wokół którego najłatwiej oprzeć skomplikowane rozwiązanie.

To nawykan rozciąga się daleko poza inżynierię agentów. Dodanie kolejnego warstwy jest łatwiejsze niż zastanowienie się, czy podstawowa wersja została kiedykolwiek sprawiedliwie porównana z nią. Nowa abstrakcja uważana jest za widoczny postęp, na który można wskazać i nazwać go ulepszeniem. Sprawdzenie, czy grep już pełni tę funkcję, czy rzeczywiście zmniejszyła się złożoność zapytań, czy to, co pochłaniało cały tydzień, to rzeczywiście to, co przypuszczaliśmy, zajmuje więcej czasu, jest trudniejsze i czasami skutkuje decyzją o zaprzestaniu dalszej pracy nad projektem.

Lista kontrolna przed dodaniem kolejnej warstwy

Krótki wykaz, który warto sprawdzić w każdej strukturze przed dodaniem kolejnej warstwy:

1. Have I benchmarked the boring baseline, not just assumed it loses?
   (full-context, grep, a plain graph, a human doing the coordination)
2. Does the new structure change the metric that actually governs cost
   or quality, or does it just look more sophisticated on a diagram?
3. Am I reaching for this because a benchmark or proof told me to,
   or because it's what the tutorials and the funded products default to?
4. If I strip this layer back out, what specifically breaks?
   If I can't name it precisely, I probably don't need the layer yet.
5. Am I solving the bottleneck I actually have, or the bottleneck
   that's most interesting to build a sophisticated solution for?

Nic z tego nie przemawia za mniejszą ilością pracy inżynierskiej. Przemawia za tym, by poświęcić wysiłek inżynierski na znalezienie miejsca, gdzie znajduje się wąskie gardło, zanim zbuduje się skomplikowany system, zakładający, że odpowiedź jest już znana. Te trzy elementy nie zostały stworzone wyłącznie dla kontrastu. Przeprowadzono nudne, ale konieczne sprawdzenia, a wyniki tych sprawdzeń kłóciły się z domyślnymi założeniami. To znacznie wyższy standard niż szybka opinia z głośnym nagłówkiem, i to właśnie do niego powinien dążyć każdy system.