Dlaczego prostsze rozwiązania przewyższają złożone w dzisiejszych architekturach agentów AI
Ten tekst analizuje trzy argumenty z 2024 roku przeciwko bazom danych wektorowym, pamięci hypergrafowej oraz złożoności orkiestracji, pokazując, że prostsze systemy często przewyższają zaawansowane struktury agentów.
Czytając wystarczająco dużo materiałów na temat agentów AI z tego roku, jeszcze przed przedstawieniem jakiegokolwiek konkretnego argumentu wyłania się pewien wzorzec. Prawie wszystko, co proponuje się, ma charakter dodatkowy – dodaje się warstwę pamięci, graf, framework do orkiestracji, a także proces przetwarzania z trzema etapami ponownego sortowania. Dodaje się też kolejne agenty, których zadaniem jest nadzór nad tymi, które już stworzyliśmy. U podstaw niemal wszystkiego leży ta sama, niewypowiedziana przekonanie: że złożoność równa się postępowi, i że jeśli nasz system nie jest bardziej rozbudowany niż pół roku temu, musimy pozostawać w tyle.
Agenctwo zajmujące się budową zespołów najprawdopodobniej skomponowało elementy tej samej architektury i być może wtedy uzasadnił niektóre z tych wyborów. Dlatego gdy w tym roku pojawiło się kilka argumentów przeciwnych, twierdzących, że to skomplikowane rozszerzenie prawdopodobnie nie było warte trudu, zasłużyły one na większą uwagę niż ta, jaką zwykle otrzymują nagłówki typu „nie potrzebujesz tego”. Większość kontrowersyjnych artykułów technologicznych to po prostu przechwytywające uwagę tezy, równie pewne siebie i równie pozbawione dowodów. Te trzy argumenty były inne. Każdy z nich opiera się na czymś sprawdzalnym: wyniku testu wydajności, argumentacji strukturalnej lub prostym opisie tego, jak praca faktycznie przebiega na co dzień. To jest standard, który należy tu zastosować, i to właśnie ten standard będzie przestrzegany w dalszej części tego tekstu.
Poniżej przedstawiono trzy przykłady. W każdym z nich zastosowano bardziej zaawansowaną architekturę, mimo że rzeczywisty problem był o wiele prostszy.
Pierwszy przypadek: twój agent prawdopodobnie nie potrzebuje bazy danych wektorowych
Decyzja o wykorzystaniu pamięci agenta wysyłkowego wspieranej przez bazę danych wektorowych jest zazwyczaj podejmowana w ciągu sekund. Ktoś formułuje wymóg: „agent musi pamiętać informacje między sesjami”, a automatyczną odpowiedzią jest: umieść dane, przechowaj je i odzyskuj na podstawie podobieństwa. Jest to standard, nie dlatego, że ktoś porównał go z innymi rozwiązaniami, ale dlatego, że każdy tutorial robi to w ten sposób.
To założenie zostało dokładnie sprawdzone w artykule z tego roku, „Your AI Agent Doesn’t Need a Vector Database” autorstwa Anubhava. Godny zapamiętania wynik pochodzi z testu LoCoMo: baza referencyjna składająca się jedynie z katalogu plików tekstowych wyszukiwanych za pomocą grep pokonała kilka profesjonalnych produktów pamięciowych stworzonych specjalnie w tym celu, właśnie na tym teście, podczas którego mierzono te produkty. Nie była to sfałszowana porównanie stworzona po to, by osiągnąć określony wynik. Bardziej zaawansowane systemy, niektóre łączące embeddingi, wyszukiwanie podobieństw, a nawet pamięć o strukturze graficznej, nadal przegrywały z czymś, co można było stworzyć w ciągu jednego popołudnia.
Gdy ten fakt zostanie przyjęty, wyjaśnienie przestaje być zaskakujące. Podobieństwo wektorowe to technika wyszukiwania, a nie technika rozumowania. Doskonale radzi sobie z wydobywaniem tekstu semantycznie bliskiego zapytaniu. Słabo radzi sobie natomiast z zadaniami, które naprawdę wymagają pamięci, takimi jak rozpoznanie, że fakt zapisany trzy tygodnie temu został już przezwyciężony przez aktualizację z wczoraj, lub że dwa przechowywane dane są ze sobą wprost sprzeczne i jedno musi mieć pierwszeństwo. Indeks wektorowy nie posiada wbudowanego poczucia czasu ani koncepcji korekty. Po prostu zwraca to, co znajduje się najbliżej w przestrzeni embeddingów, pozostawiając modelowi samodzielne rozwiązanie problemu, dlaczego dwa z pięciu najbardziej pasujących wyników się różnią.
Istnieje druga niespójność, dotycząca raczej znajomości niż surowych możliwości. Modele językowe przyswoiły ogromne ilości danych treningowych skupionych na pracy z plikami: ich czytaniu, przeszukiwaniu, edycji, wyliczaniu katalogów, śledzeniu łańcuchów importu. To nie jest efekt uboczny – stanowi istotę większości treści ich korpusu treningowego. Pętla oparta na grep i czytaniu plików bezpośrednio wykorzystuje tę już istniejącą biegłość modelu. Z kolei interfejs zapytań bazy wektorowej to narzędzie, którego model musi samodzielnie odkryć, jak skutecznie używać w konkretnym kontekście, bez tak głębokiego wcześniejszego kontaktu z plikami. W rezultacie zastępujemy umiejętność, którą model już posiada, taką, którą musi nabyć na bieżąco, płacąc za to kosztem opóźnień związanymi z embeddingiem i wyszukiwaniem.
Oto w przybliżeniu jak można sformułować tę decyzję teraz, po rzetelnym przemyśleniu jej zamiast polegania na nawyku:
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
Cyklu zapisu, zarządzania i odczytu opisany w tym tekście zasługuje na konkretną realizację, ponieważ stwierdzenie „po prostu użyj plików” może brzmieć ogólnikowo, dopóki nie zostanie pokazany jako działający kod. Oto wersja, która może działać już dziś, bez konieczności korzystania z usług hostowanych:
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")]
Podłącz te trzy funkcje jako narzędzia, niech model sam decyduje, kiedy zapisać notatkę, kiedy przeprowadzić wyszukiwanie, a kiedy po prostu załadować cały plik tematyczny do kontekstu, ponieważ jest na tyle krótki, by się zmieścić. W rezultacie otrzymujemy system pamięci bez żadnych kosztów związanych z embeddingiem, bez konieczności utrzymywania bazy wektorowej ani płacenia za nią, a także stan, który można bezpośrednio otworzyć w edytorze tekstu, gdy coś pójdzie nie tak. Jeśli ta konfiguracja okaże się w końcu niewystarczająca, powód będzie oczywisty – pojawi się jako konkretny błąd: zbyt duży korpus, by szybko przeszukiwać go za pomocą zwykłych narzędzi do tekstu, lub pytanie wieloetapowe, na które wyszukiwanie według słów kluczowych naprawdę nie może odpowiedzieć. To o wiele lepsze uzasadnienie dla wprowadzenia magazynu wektorowego niż po prostu naśladowanie tego, co pokazał jakiś tutorial.
Nie mówi się, że bazy danych wektorowych nie mają żadnego zastosowania na świecie. Kwestia jest bardziej precyzyjna: nie sięgaj po taką bazę, zanim faktycznie sprawdzisz, jak daleko zaprowadzi cię mniej efektywny standard. Najpierw wypróbuj ładowanie pełnego kontekstu oraz metodę filesystem-plus-grep. Wdroż produkt z płatną pamięcią tylko wtedy, gdy przewyższy on ten standard na tyle znacząco, by usprawiedliwić jego koszt – zarówno finansowy, jak i utratę możliwości łatwego debugowania. Większość zadań wymagających użycia pamięci przez agenty nigdy nie osiąga takiego poziomu.
Przypadek drugi: hipergrafy również nie uratują twojego systemu RAG
Jeśli bazy danych wektorowych były automatycznym wyborem z zeszłego roku, to RAG oparte na grafach stało się wyborem tego roku, a hipergrafy to rozwiązanie stosowane wtedy, gdy zespół uznaje, że zwykły graf wiedzy nie jest wystarczająco wyraźny. Na pierwszy rzut oka propozycja ta wydaje się rozsądna: zwykły krawędź grafu łączy dokładnie dwa węzły, ale wiele faktów z rzeczywistości dotyczy jednocześnie więcej niż dwóch uczestników. Weźmy na przykład sytuację, w której jeden pracownik zatwierdza wydatki podróżne kolegi w imieniu całego działu w określonym cyklu budżetowym – ten jeden fakt łączy razem pięciu różnych uczestników. Jeśli spróbujemy przenieść to na krawędzie parowe, mamy do wyboru: albo tracimy poczucie, że było to jedno spójne zdarzenie, albo dzielimy je na kilka krawędzi binarnych, które następnie trzeba ponownie połączyć podczas wyszukiwania. Hiperkrawędź, zdolna do łączenia dowolnej liczby węzłów jednocześnie, wydaje się rozwiązaniem idealnym.
Wierniejszy sposób na jego modelowanie. Dlatego zespoły tworzą systemy RAG oparte na hipergrafach, wierząc, że ta dodatkowa wierność przekłada się na lepsze wyszukiwanie.Artykuł opublikowany w tym roku przez autora o imieniu Dustin, zatytułowany „Hypergraphs Won't Make Your RAG System Better. Here's What They Actually Change”, sprawdził tę tezę w oparciu o rzeczywistą implementację przedstawioną w pracy na temat systemów RAG opartych na hipergrafach, a nie tylko jej streszczenie. Wyniki były niemal komiczne: HyperGraphRAG, system, którego podstawowym założeniem jest znaczenie rdzennych hiperkrawędzi, faktycznie przechowuje wszystko wewnętrznie w standardowej bazie danych grafowych, wykorzystując zwykłe krawędzie binarne. Co jeszcze bardziej istotne, sami autorzy pracy pokazali, że ta transformacja – rozbicie każdej hiperkrawędzi na mały zbiór krawędzi binarnych otaczających ustandaryzowany węzeł reprezentujący daną sytuację – nie pomija żadnych informacji. Żadna z elementów podstawowej struktury nie ginie podczas tej konwersji. Rzekomo bardziej dokładna reprezentacja hipergrafów oraz „nudna” wersja oparta na krawędziach binarnych można odtworzyć z siebie wzajemnie z dokładnością do 100%.
ly.To nie jest jakaś błahe uwaga dotycząca implementacji — podważa to cały argument. Jeśli rdzenny hiperkrawędź oraz klastr binarnych krawędzi ucieleśniający rolę kodują tę samą strukturę incydencji, a każdy z nich można łatwo odbudować na podstawie drugiego, to wybór jednego zamiast drugiego nie stanowi rzeczywiście decyzji modelowania o konsekwencjach dalszych. To po prostu wybór formatu przechowywania. Komentator tego artykułu, Felix Anderson, sformułował odpowiednie twierdzenia matematyczne tak klarownie, jak to tylko możliwe: hiperkrawędź oraz binarny graf ucieleśniający rolę opisują tę samą strukturę incydencji, a szerokość hiperdrzewa zmienia się jedynie o stały współczynnik, gdy liczba argumentów jest ograniczona. Szerokość hiperdrzewa to rzeczywista miara złożoności, która określa, jak kosztowne jest wykonywanie zapytania — nie liczba kroków, ani też ilość uczestników umieszczonych w jednej krawędzi. Jeśli zmiana reprezentacji powoduje zmianę tej wartości tylko o stałą, a każdy fakt jest…
Jeśli liczba uczestników jest ograniczona (co dotyczy niemal każdego faktu z rzeczywistości — garstka osób w łańcuchu zatwierdzania, a nie tysiące), to cały wysiłek inżynieryjny włożony w przełącznik nie przynosi żadnych korzyści pod względem tego czynnika, który faktycznie wpływa na koszt zapytania.Warto jasno wyjaśnić, dlaczego tak łatwo popaść w to błędne przekonanie. Liczba skoków jest intuicyjna: im więcej węzłów znajduje się pomiędzy pytaniem a jego odpowiedzią, tym wydaje się, że zapytanie powinno być trudniejsze. Szerokość hiperdrzewa wcale nie jest intuicyjna – wynika z teorii spełniania ograniczeń i złożoności zapytań, i może zmieniać się w sposób, którego liczba skoków nigdy nie zdradzi, chyba że ktoś specjalnie to sprawdzi. Całkowicie możliwe jest dodanie elementów złożoności strukturalnej, które zmniejszą liczbę skoków w jednym starannie wybranym przykładzie zapytania, nie wpływając na podstawową klasę złożoności, a nawet pogorszając ją nieznacznie. Przykłady przedstawione w artykule mogą wyglądać imponująco, ale nadal nie mówią nic znaczącego o przypadku ogólnym.
Oto porównanie side-by-side, które warto przejrzeć przed wyborem pomiędzy zwykłym grafem, grafem ustrukturyzowanym a lokalnym magazynem hipergrafów:
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
Żadne z tych argumentów nie pokazuje, że struktura grafu jest bezwartościowa w kontekście RAG. Wyszukiwanie relacyjne wieloetapowe rzeczywiście czerpie korzyści z struktury grafu w porównaniu ze zwykłą wyszukiwaniem wektorowym — co do tego nie ma wątpliwości. Kwestią sporną jest natomiast dodatkowy krok od zwykłego grafu do hipergrafu, a gdy spojrzy się poza marketingowe obietnice na rzecz rzeczywistych dowodów, uczciwy wniosek brzmi, że taki krok zapewnia model danych wyglądający lepiej, ale wymaga nowej kategorii infrastruktury do jego uruchomienia, przy czym nie wpływa to na wskaźnik określający szybkość lub wolność wykonywania zapytań. Jeśli problemem jest jakość wyszukiwania, rozwiązaniem opartym na rzeczywistych dowodach jest zazwyczaj lepszy proces budowy grafu lub bardziej inteligentna strategia wyszukiwania w ramach istniejącego już grafu — a nie nowy, bardziej egzotyczny typ krawędzi.
Przypadek trzeci: prawdziwym wąskim gardłem nigdy nie był sam kod
Pierwsze dwa argumenty dotyczyły architektury pozyskiwania danych, tematu znajdującego się w dobrze znanym obszarze. Ten trzeci jest inny, ponieważ nie chodzi tu o wybór odpowiedniego narzędzia — chodzi o to, z czego faktycznie składa się praca doświadczonego inżyniera, i dotknął on spraw bliżej niż się spodziewano.
Patrick Koss, kierownik techniczny zarządzający zespołem pięciu inżynierów w firmie z ponad tysiącem pracowników, nazwał swój artykuł „AI can't do 95% of my job (and I'm a software engineer)”. Pierwsze stwierdzenie brzmi niemal jak przyznanie porażki, zanim przeradza się w argument: pisanie kodu to zdecydowanie najmniejszy element tego, jak spędza on swój czas. Jego zespół stosuje model „ty to budujesz, ty to uruchamiasz”, co oznacza, że odpowiedzialność za systemy należące do nich spoczywa na jego własnych inżynierach, a nie na oddzielnym zespole operacyjnym, który mógłby traktować problemy produkcyjne jako problem kogoś innego. Jego poranki zaczynają się około 8:30 od przeglądania pull requestów, a kod pojawiający się w tych PR-ach – w dużej mierze napisany przez agenty AI wykonujące większość pracy nad projektem – jest wyraźnie lepszy niż ten, który przeglądał kilka lat temu. Nie kwestionuje on tego, czy AI może tworzyć dobry kod.
Dzień. Całkowicie przyznaje rację w tym punkcie, a następnie zauważa, że to ledwo co zmienia to, czego jego praca faktycznie od niego wymaga.To właśnie ten szczegół zasługuje na uwagę, ponieważ podważa założenie zakorzenione w wielu rozumowaniach dotyczących architektury agentów, w tym w licznych argumentach przedstawianych w tej dziedzinie: ideę, że możliwości technologiczne determinują stopień automatyzacji. Logika ta zakłada zazwyczaj, że gdy model potrafi pisać poprawny kod, jego tworzenie przestaje być pracą ludzką, więc udział „pracy” automatyzowanej powinien odpowiadać udziałowi tej pracy, która wcześniej wymagała pisania kodu. Koss twierdzi natomiast, że ta zależność została już naruszona długo przed pojawieniem się sztucznej inteligencji – AI jedynie sprawia, że ten błąd staje się bardziej widoczny. Rola kierownika technicznego nigdy nie polegała przede wszystkim na tworzeniu kodu. Zawsze chodziło przede wszystkim o koordynację: wybór tego, co ma zostać stworzone i w jakiej kolejności, negocjacje dotyczące zakresu pracy z interesariuszami o sprzecznych priorytetach, sprawdzanie i popieranie decyzji technicznych innych osób, pełnienie roli łącznika oraz mentoring mniej doświadczonych pracowników.
Praca z inżynierami oraz tłumaczenie pomiędzy tym, czego żąda interesariusz, a tym, co system może w rzeczywistości obsłużyć bez awarii. Nic z tego nie jest ukrytą pracą nad kodem. To praca organizacyjna i międzyludzka, która przypadkowo generuje kod — przy czym jest to proces wysoce automatyzowalny — wchodzący w skład znacznie szerszego zestawu obowiązków, które opierają się automatyzacji właśnie dlatego, że nie dotyczą tworzenia artefaktów. Chodzi o osiąganie porozumień, kompromisów i odpowiedzialności pomiędzy ludźmi.To może być najmniej doceniona obserwacja z tegorocznych dyskusji na temat agentów – ważniejsza niż jakikolwiek pojedynczy wskaźnik, ponieważ wyjaśnia, dlaczego stwierdzenia typu „model znacznie poprawił się w kodowaniu” oraz „moja praca stała się znacznie łatwiejsza” nie idą w parze u wielu doświadczonych inżynierów, nawet tych, którzy aktywnie korzystają z tych narzędzi i czerpią z nich rzeczywistą korzyść. Obserwowanie, jak wyniki SWE-bench rosną z jednocyfrowych wartości do poziomu siedemdziesięciu punktów w ciągu kilku lat, oznacza rzeczywisty i znaczny postęp w umiejętnościach. Jednak ten postęp nie przekłada się automatycznie na pracę o 70 procent lżejszą, ponieważ praca ta od początku nie polegała w 70 procentach na tworzeniu kodu – szczególnie gdy jesteś już na tyle doświadczony, że twoje obowiązki obejmują również zarządzanie zmianami awaryjnymi i planem rozwoju, a nie tylko prośbami o integrację kodu.
Szczerą zastrzeżeniem jest to, że ten argument nie generalizuje się tak klarownie jak pierwsze dwa. Twierdzenia dotyczące baz danych wektorowych i hipergrafów są na tyle techniczne, że można je sprawdzić za pomocą benchmarków lub dowodów, a dokładnie to już wcześniej się stało. Kwestia tego, w jakim stopniu praca inżyniera seniora polega na koordynacji, a w jakim na programowaniu, będzie się zmieniać w zależności od wielkości firmy, dojrzałości zespołu, tego, w jakim stopniu organizacyjne obciążenia są rzeczywiście istotne, a w jakim stanowią jedynie problem, oraz od poziomu doświadczenia danej osoby. Zespół pięciu osób w firmie liczącej tysiąc pracowników, działający według zasady „ty to budujesz, ty to prowadzisz”, to jeden konkretny model pracy, a nie zamiennik dla każdej pozycji inżynierskiej. Mimo to podstawowa korekta wydaje się obowiązywać ogólnie: możliwości agenta ustalają górny limit tego, jak dużą część pracy polegającej na pisaniu kodu można teoretycznie zautomatyzować, ale to jedynie wskazuje…
Prawie nic nie wiadomo na temat tego, jak duża może być część związana z koordynacją, ponieważ ta część od samego początku nie była ograniczana prędkością pisania ani jakością kodu.Wspólny mianownik
Gdy postawi się te trzy przypadki obok siebie, okazuje się, że prawdziwa lekcja nie ma nic wspólnego konkretnie z bazami danych wektorowymi, hipergrafami czy możliwościami agentów. Chodzi tu o niezgodność pomiędzy tym, gdzie każda z tych dziedzin zakładała, że leży trudność, a tym, gdzie ona faktycznie się znajdowała.
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
Ten nawyk występuje również daleko poza dziedziną projektowania agentów. Dodanie kolejnej warstwy jest prawie zawsze łatwiejsze niż zatrzymanie się i zastanowienie, czy prosta, niepozorna baza została kiedykolwiek sprawiedliwie przetestowana w porównaniu z nią. Nowa abstrakcja wygląda jak widoczny postęp – coś, na co można wskazać i nazwać ulepszeniem. Sprawdzanie, czy grep już obejmuje dany przypadek, czy złożoność zapytania rzeczywiście się poprawiła, czy to, co pochłaniało twoją pracę przez cały tydzień, rzeczywiście było tym, za co je uważałeś – to zajęcie jest wolniejsze i o wiele mniej satysfakcjonujące, a może skończyć się wnioskiem, że lepiej przestać rozwijać dalej, zamiast kontynuować.
Oto skrócona wersja listy kontrolnej, którą warto sprawdzić przed dodaniem kolejnej warstwy do dowolnego stacku:
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żynieryjnej ogółem. Przemawia za skierowaniem wysiłków inżynieryjnych na ustalenie, gdzie dokładnie znajduje się wąskie gardło, zanim zostanie opracowane skomplikowane rozwiązanie zakładające, że już znamy odpowiedź. Trzy przykłady omówione tutaj nie zostały wybrane dla efektu szokowego. Otrzymały taką etykietę, ponieważ ktoś wykonał niepozorną pracę weryfikacji, a wyniki tej weryfikacji kłóciły się z domyślnymi założeniami. To znacznie wyższy standard niż górnolotny nagłówek wraz z mocnym zdaniem, i to właśnie taki standard warto stosować do własnych rozwiązań w przyszłości.
Literatura pokrewna
- Zrozumienie agentów AI: cele, narzędzia, pamięć i pętla agenta — Przystępne dla początkujących wyjaśnienie, w jaki sposób agenci AI różnią się od chatbotów, obejmujące podstawowe komponenty, pętlę decyzyjną, poziomy autonomii oraz praktyczne zastosowania w rzeczywistym świecie.
- Zrozumienie pamięci AI: kontekst, wkładki, RAG i wagi modelu wyjaśnione — Ten artykuł objaśnia, w jaki sposób systemy AI faktycznie przechowują informacje, omawiając okna kontekstowe, wkładki, bazy danych wektorowych, RAG oraz parametry modelu.