Чому простіше краще за складніше у сучасних архітектурах AI-агентів
У цій статті розглядаються три аргументи 2024 року проти векторних баз даних, пам’яті типу гіперграф та складності оркестрації, демонструючи, що простіші системи часто досягають кращих результатів, ніж складні стеки агентів.
Прочитавши достатньо матеріалів про агентів ШІ цього року, ще до того, як з’являються будь-які аргументи, стає помітна певна закономірність. Майже все, що пропонується, є додатковим. Додають шар пам’яті, граф, фреймворк оркестрації чи систему пошуку з трьома етапами переранжування. Додають ще агентів, завданням яких є контроль за вже створеними агентами. Під усім цим лежить одна й та сама невисловлена думка: що складність — це прогрес, і якщо ваша система не є більш складною, ніж півроку тому, це означає, що ви відстаєте.
Агент з розробки команд, ймовірно, склав частини цієї самої архітектури та міг у той час обґрунтувати деякі з цих виборів. Тож коли цього року з’явилось кілька досліджень, які стверджували протилежне — що це складне доповнення, ймовірно, не варте всіх зусиль, — їм варто було приділити більше уваги, ніж зазвичай отримують заголовки на кшталт „вам це не потрібно“. Більшість контраргументів у технологічних статтях — це просто зворотний хайп, такий само впевнений та такий само позбавлений доказів. Ці три аргументи були іншими. Кожен з них ґрунтується на чомусь перевіреному: показнику тестування, структурному обґрунтуванні чи прямому описі того, як насправді відбувається робота щодня. Саме цей стандарт варто застосувати тут, і саме до нього буде дотримуватися решта цієї статті.
Наведено три приклади. У кожному з них для вирішення проблеми вдаються до складніших архітектурних рішень, хоча справжня проблема була значно простішою.
Перший випадок: вашому агенту, ймовірно, не потрібна база даних векторів
Використання пам’яті агента для зберігання даних за допомогою бази векторів — це рішення, яке зазвичай приймається за кілька секунд. Хтось формулює вимогу: «Агент має пам’ятати інформацію між сеансами», і автоматичною відповіддю є: заховайте дані, збережіть їх та відтворіть за схожістю. Це є стандартом не тому, що хтось порівнював його з іншими варіантами, а тому, що всі навчальні матеріали саме так це роблять.
Саме цю припущення перевіряє одна з статей цього року — «Your AI Agent Doesn't Need a Vector Database» від Анубхава. Цікавий результат було отримано у тесті LoCoMo: базова система, яка складалася лише з каталогу текстових файлів, пошук у яких здійснювався за допомогою grep, перевершила кілька професійних продуктів для зберігання даних, створених за спеціальною метою, саме у цьому тесті. Це не було сфабриковане порівняння для отримання переваги. Навіть більш складні системи, які поєднували в собі ембеддинги, пошук схожостей та навіть пам’ять у графовій структурі, все одно програли тому, що можна було створити за один полудень.
Як тільки цей результат стає зрозумілим, пояснення вже не здається дивним. Векторна схожість — це техніка пошуку, а не техніка міркування. Вона чудово підходить для знаходження тексту, семантично близького до запиту. Однак вона погано справляється з тими завданнями, які справді вимагають пам’яті, наприклад, з розпізнаванням того, що факт, зафіксований три тижні тому, вже був перевершений оновленням учора, або що два збережені записи прямо суперечать один одному і один з них має мати пріоритет. У векторному індексі немає вбудованого розуміння часу та поняття корекції. Він просто повертає те, що знаходиться найближче у просторі ембеддингів, і залишає моделі самостійно з’ясовувати, чому два з п’яти найкращих результатів не узгоджуються.
Існує ще одна невідповідність, яка стосується скоріше знайомства з процесами, ніж базових можливостей. Моделі мови опанували величезні обсяги навчальних даних, присвятованих роботі з файлами: їх читанню, пошуку вмісту, редагуванню, переліку каталогів, відстеженню ланцюгів імпорту. Це не побічний ефект — це є основою значної частини їхнього навчального корпусу. Логіка, побудована навколо grep та читання файлів, безпосередньо використовує цю вже наявну вмілість. Натомість інтерфейс запитів векторної бази даних — це інструмент, який модель мусить з’ясувати, як ефективно використовувати у конкретному контексті, без такого глибокого попереднього досвіду роботи з файлами. У результаті ви замінюєте навичку, якою модель вже володіє, на ту, яку їй доводиться опановувати «на льоту», і за цю заміну платите завдяки затримкам у вбудовуванні та пошуку даних.
Ось приблизно як можна сформулювати це рішення зараз, після ретельного аналізу замість того, щоб керуватися звичкою:
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
Цикл запису, керування та читання, описаний у цьому матеріалі, потребує конкретизації, адже фраза „просто використовуйте файли“ може звучати недостатньо чітко, поки не буде показано робочий код. Ось версія, яка може працювати вже сьогодні без необхідності використання хостованих сервісів:
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")]
Використовуйте ці три функції як інструменти, нехай модель сама вирішує, коли записувати примітку, коли шукати та коли просто завантажувати цілий файл теми в контекст, оскільки він достатньо короткий, щоб туди поміститися. У результаті отримується система пам’яті без жодних витрат на зберігання даних, без необхідності підтримки чи оплати векторної бази даних, а також з можливістю безпосереднього відкриття стану у текстовому редакторі у разі виникнення проблем. Якщо ця конфігурація зрештою стане недостатньою, причина буде очевидною — вона проявиться у конкретній невдачі: корпус даних буде занадто великим для швидкого пошуку за допомогою звичайних інструментів для роботи з текстом, або ж запит буде складним, який пошук за ключовими словами справді не зможе вирішити. Це набагато краща підстава для впровадження векторного сховища, ніж просте наслідування прикладів з посібників.
Вам не кажуть, що векторні бази даних не мають місця у світі. Суть проблеми є вузькішою: не поспішайте використовувати їх, поки не оціните, наскільки далеко може вас довести більш простий базовий підхід. Спочатку спробуйте завантаження повного контексту та використання файлової системи разом із командою grep. Використовуйте платні продукти з пам’яттю лише тоді, коли вони значно перевершують цей базовий рівень, щоб виправдати їхню вартість як у грошовому вимірі, так і з точки зору можливостей для дебаггінгу, які ви втрачаєте. Більшість завдань, що вимагають використання пам’яті агентів, ніколи не досягають цього рівня.
Другий випадок: гіперграфи також не врятують вашу систему RAG
Якщо векторні бази даних були автоматичним вибором минулого року, то RAG на основі графів став вибором цього року, а гіперграфи є наступним кроком розвитку, який з’являється тоді, коли команда вирішує, що звичайний граф знань все одно недостатньо експресивний. На перший погляд ця ідея здається розумною: звичайна грань графа поєднує саме два вузли, але багато реальних ситуацій включають більше ніж двох учасників одночасно. Уявіть собі сценарій, коли один співробітник затверджує витрати на подорож колеги від імені всього відділу протягом певного бюджетного циклу — цей один факт пов’язує разом п’ятьох різних учасників. Якщо спробувати представити це у вигляді парних граней, доводиться робити вибір: або втратити уявлення про те, що це була одна атомарна подія, або розділити її на кілька бінарних граней, які потім доводиться знову об’єднувати під час запиту. Гіпергрань, здатна одночасно поєднувати будь-яку кількість вузлів, здається рішенням цієї проблеми.
Більш точний спосіб моделювання цього. Тож команди створюють системи RAG з гіперграфами, сподіваючись, що ця додаткова точність призведе до кращого пошуку інформації.Стаття, опублікована цього року письменником на ім’я Дастін під назвою „Гіперграфи не покращать вашу систему RAG. Ось що вони насправді змінюють“, перевірила це припущення на основі реальної реалізації, описаної у дослідженні про гіперграфи в рамках систем RAG, а не лише її анотації. Результат виявився майже кумедним: HyperGraphRAG — система, основною ідеєю якої є важливість нативних гіперребер — насправді зберігає все всередині себе у стандартній базі даних графів за допомогою звичайних бінарних ребер. Ще цікавіше те, що самі автори дослідження демонструють, що така трансляція — розбиття кожного гіперребра на невелику групу бінарних ребер, об’єднаних навколо узагальненого вузла, що представляє подію — не втрачає нічого. Жодна інформація про базову структуру не втрачається під час конвертації. Як ніби більш точне представлення у вигляді гіперграфа та „нудна“ версія з бінарними ребрами можуть бути відновлені одна з одної з точністю до деталей.
ли.Це не якась дрібна примітка щодо реалізації — це підриває всю аргументацію. Якщо нативний гіперребро та кластер бінарних ребер, у якому ролі представлені конкретними елементами, кодують однакову структуру інциденції, і кожен з них може бути легко відновлений з іншого, тоді вибір одного замість іншого насправді не є моделювальним рішенням із наслідками для подальших кроків. Це просто рішення щодо формату зберігання. Коментатор цієї статті, Фелікс Андерсон, сформулював відповідну математику максимально чітко: гіперребро та бінарна гра, у якій ролі представлені конкретними елементами, описують однакову структуру інциденції, а ширина гіпердерева змінюється лише на константний коефіцієнт, коли кількість аргументів обмежена. Ширина гіпердерева — це фактичний показник складності, який визначає, наскільки дорого коштує обробка запиту — це не кількість кроків та не кількість учасників, яких помістили в одне ребро. Якщо зміна формату представлення лише змінює це число на константу, а кожен факт залишається незмінним...
Якщо кількість учасників обмежена (що характерно майже для кожного реального факту — кілька осіб у ланцюзі схвалення, а не тисячі), тоді весь інженерний зусилля, вкладений у перемикання, не має жодного значення з точки зору параметра, який насправді впливає на вартість запиту.Варто чесно розглянути причини, чому так легко впасти в це хибне уявлення. Кількість кроків є інтуїтивно зрозумілою: чим більше вузлів між запитанням та його відповіддю, тим, здається, запит має бути складнішим. Ширина гіпердерева зовсім не є інтуїтивною — вона ґрунтується на теорії задоволення обмежень та складності запитів, і може змінюватися таким чином, який кількість кроків ніколи не вказує, якщо тільки хтось спеціально не перевірить це. Цілком можливо додати структурну складність, яка зменшить кількість кроків для ретельно обраного прикладу запиту, залишивши клас основної складності незмінним або навіть погіршивши його трохи. Добре підібрані приклади з наукової статті можуть виглядати вражаюче, але все одно не говорити нічого значущого про загальний випадок.
Ось порівняння пліч-о-пліч, яке варто розглянути перед тим, як обрати між звичайною графом, реалізованою графом чи нативним сховищем гіперграфів:
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
Жоден із цих аргументів не свідчить про те, що структура графа є марною для RAG. Багатоетапне відновлення даних за допомогою взаємозв’язків справді отримує переваги від структури графа порівняно з простим векторним пошуком — у цьому немає сумнівів. Сумніви стосуються додаткового кроку від звичайного графа до гіперграфа, і якщо подивитися за рекламні обіцянки та перейти до фактичних доказів, чесним висновком є те, що цей крок забезпечує більш охайну модель даних, але вимагає нової категорії інфраструктури для її функціонування, при цьому не впливаючи на показники швидкості обробки запитів. Якщо проблема полягає у якості відновлення даних, рішенням із реальними доказами зазвичай є кращий процес створення графа або розумніша стратегія пошуку в межах існуючого графа — а не використання більш екзотичних типів ребер.
Третій випадок: справжньою перешкодою ніколи не був сам код
Перші два аргументи стосувалися архітектури пошуку, теми, яка належить до знайомої сфери. Третій аргумент є іншим, адже йдеться не про вибір правильного інструменту — а про те, з чого насправді складається робота старшого інженера, і це стосується нас ближче, ніж очікувалося.
Патрік Косс, технічний керівник, який очолює команду з п’яти інженерів у компанії з понад тисячею співробітників, назвав свою статтю «Штучний інтелект не може виконувати 95% моєї роботи (а я — інженер програмного забезпечення)». Початкове твердження майже нагадує зізнання у поразці, перш ніж перетворитися на аргумент: написання коду — це зовсім незначна частина його робочого часу. Його команда дотримується принципу «ти створюєш, ти керуєш», що означає, що відповідальність за системи, якими вони керують, лежить на самих інженерах, а не на окремій групі операційного обслуговування, яка може ставитися до проблем у продакшені як до чужої проблеми. Його ранок починається близько 8:30 з перегляду запитів на інтеграцію коду, а код, який потрапляє в ці запити — більша частина якого написана штучними інтелектом, який виконує основну роботу з формулювання — значно кращий, ніж той, який він переглядав кілька років тому. Він не ставить під сумнів те, чи може штучний інтелект створювати якісний код.
день. Він повністю погоджується з цим твердженням, а потім зауважує, що це ледве що змінює те, чого насправді вимагає від нього його робота.Це саме та деталь, на якій варто зупинитися, адже вона спростовує припущення, яке лежить в основі багатьох міркувань щодо агентських стеків, включаючи численні аргументи в цій галузі: ідею про те, що можливості визначають рівень автоматизації. Зазвичай вважається, що як тільки модель може писати правильний код, створення коду більше не є роботою людини, тож частка „роботи“, яка автоматизується, має відповідати частці роботи, яка раніше вимагала написання коду. Протилежна думка Косса полягає у тому, що ця формула вже давно не спрацьовує — ШІ лише робить цю помилку більш помітною. Роль технологічного лідера ніколи не полягала насамперед у створенні коду. Вона завжди полягала насамперед у координації: виборі того, що потрібно створити, та в порядку цього, веденні переговорів щодо обсягу роботи між зацікавленими сторонами з суперечливими пріоритетами, перегляді та підтримці технічних рішень інших людей, виконанні обов’язків керівника проєкту та навчанні менш досвідчених співробітників.
Це робота з інженерами, а також переклад між тим, чого вимагає зацікавлена сторона, та тим, що система може реалістично підтримувати, не допускаючи збоїв. Жоден із цих аспектів не є прикриттям для роботи з кодуванням. Це організаційна та міжособистісна робота, яка випадково призводить до створення коду — причому цей процес може бути сильно автоматизований — і вона входить до значно ширшого набору обов’язків, які опираються автоматизації саме тому, що не стосуються створення продуктів. Вони стосуються досягнення згоди, знаходження компромісів та забезпечення відповідальності між людьми.Це, можливо, найбільш недооцінене спостереження у цьогорічних дискусіях про агентів — воно має більше значення, ніж будь-яке окреме показник бенчмарку, адже воно пояснює, чому твердження про те, що „модель значно покращила навички програмування“ та „моя робота значно спростилася“, не супроводжуються однаковими змінами у багатьох старших інженерів, навіть у тих, хто активно використовує ці інструменти та отримує від них реальну користь. Те, що оцінки SWE-bench зростають з однозначних цифр до сімдесяти за кілька років, свідчить про справжній та значний прорив у компетентностях. Однак цей прорив не автоматично означає, що робота стане на 70 відсотків легшою, адже спочатку робота ніколи не полягала на 70 відсотків у написанні коду — особливо коли ви достатньо старші, щоб ваша посада також включала керування чергою дежурств та стратегією розвитку, а не лише обробку запитів на зміни коду.
Чесна застереження полягає у тому, що цей аргумент не може бути застосований настільки ж чітко, як перші два. Твердження щодо векторних баз даних та гіперграфів є настільки технічними, що їх можна перевірити за допомогою критеріїв оцінки чи доведень, і саме це й було зроблено раніше. Питання про те, наскільки в роботі старшого інженера більше координації, а наскільки програмування, залежатиме від розміру компанії, рівня зрілості команди, того, наскільки організаційні витрати є справді необхідними чи просто спричиняють проблеми, а також від рівня кваліфікації окремої особи. Команда з п’яти осіб у компанії з тисячою співробітників, яка дотримується принципу „ти створюєш — ти керуєш“, є лише однією з форм роботи, а не загальним правилом для всіх інженерних посад. Проте основна корекція, схоже, залишається актуальною: можливості агента встановлюють верхню межу для того, наскільки частину роботи з написання коду можна теоретично автоматизувати, але вони вказують
Ви майже нічого не знаєте про те, наскільки може бути великою частина, присвятована координації, адже ця частина з самого початку ніколи не обмежувалася швидкістю введення чи якістю коду.Спільна тема
Якщо порівняти ці три випадки, справжній урок не стосується безпосередньо векторних баз даних, гіперграфів чи можливостей агентів. Він стосується неузгодженості між тим, де кожна галузь вважала, що полягає складність, та де вона насправді знаходилася.
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
Жоден з більш складних варіантів за своєю суттю не є поганою ідеєю. Бази даних типу Vector вирішують реальні проблеми у правильному контексті, гіперграфи можуть стати корисними у ситуаціях, які тут не розглядаються, а штучні інтелектуальні агенти справді усувають реальну надмірну роботу з інженерних завдань, що прямо зазначає дослідник, який вивчав третій випадок. Помилкою було прагнення до складності, а не пропуск кроку перевірки того, чи спрямована ця складність на справжню обмеження, а не на ту, яка випадково є найзручнішою для створення вражаючого рішення.
Ця звичка проявляється також далеко за межами роботи з агентами. Додати ще один шар майже завжди простіше, ніж зупинитися та задуматися, чи була проста, неприваблива базова версія коли-небудь належним чином протестована порівняно з нею. Нова абстракція сприймається як видимий прогрес — щось, на що можна вказати та назвати оновленням. Перевірка того, чи вже grep покриває цей випадок, чи справді покращилася складність запиту, чи те, що забирало у вас тиждень часу, справді було тим, чим ви його уявляли, — ця робота є повільнішою та значно менш задовільною, і вона може закінчитися висновком про те, що краще припинити розробку, аніж продовжувати.
Ось стисла версія переліку перевірок, який варто провести для будь-якої стек-технології перед додаванням нового шару:
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?
Жоден із цих аргументів не вимагає скорочення обсягу інженерних робіт в цілому. Вони закликають спрямувати зусилля інженерів на визначення справжньої причини уповільнення роботи ще до створення складного рішення, яке ґрунтується на припущенні, що ви вже знаєте відповідь. Три приклади, наведені тут, не були обрані для створення сенсації. Вони отримали таку назву тому, що хтось виконав непривабливу роботу перевірки, і результати цієї перевірки суперечили загальноприйнятим припущенням. Це значно вища планка, ніж просто яскравий заголовок із рішучою думкою, і саме таку планку варто застосовувати до своїх технологічних стеків у майбутньому.
Пов’язана література
- Розуміння AI-агентів: цілі, інструменти, пам’ять та цикл агента — просте пояснення для початківців про те, чим AI-агенти відрізняються від чат-ботів, з описом основних компонентів, циклу прийняття рішень, рівнів автономії та прикладів використання у реальному світі.
- Розуміння пам’яті AI: контекст, ембеддинги, RAG та параметри моделі — у цій статті пояснюється, як системи AI насправді зберігають інформацію, з урахуванням вікон контексту, ембеддингів, векторних баз даних, технології RAG та параметрів моделі.