Ставлення до Agent Stack: сховища векторів, гіперграфи та завдання кодування
Три випадки, коли складніші стеки агентів не виявили справжнього вузького місця: пам’ять агентів, заснована на файлах, виявилася кращою за векторні сховища, гіперграфи RAG та традиційні методи роботи.
Джерела: The Case Against Your Own Agent Stack: What Contrarians Get Right This Year
Бажання додавати ще більше
Якщо прочитати цьогорічні матеріали про штучних агентів, одна річ вирізняється понад усіма окремими твердженнями: поради майже завжди полягають у тому, щоб щось додати. Шар пам’яті. Граф. Фреймворк оркестрації. Систему пошуку з трьома етапами переурочування. Ще більше агентів для контролю за тими, що вже є. За цим стоїть тихе переконання, що складність означає прогрес, і що система, яка не є складнішою, ніж шість місяців тому, відстає.
Чималу частину цієї технологічної стеку, ймовірно, вже створили та захищали ті, хто читає цей текст. Тож варто зупинитися на невеликій групі аргументів, які стверджують протилежне: складний інструмент, який ви додали, ймовірно, ще не заслуговує на своє місце. Більшість контраргументів у технологічних статтях — це просто інвертована реклама, така ж самовпевнена та така ж бідна на докази. Ці три приклади відрізняються тим, що кожен з них ґрунтується на чомусь перевірному — чи то результаті тестування, чи то структурному доведенні, чи то простому описі того, як проходить робочий день людини. Цей стандарт застосовується нижче, а також до будь-якої технологічної стеку, включаючи вашу власну.
Кожен з цих прикладів — це момент, коли галузь прагнула до більшої структурованості, хоча справжня проблема полягала десь у більш незначних аспектах.
Перший приклад: пам’ять агентів та векторні сховища
Пам’ять агента у векторному сховищі зазвичай налаштовується протягом приблизно півхвилини. Хтось зазначив, що агент повинен зберігати інформацію між сеансами, і виникла відповідна реакція: вбудовування даних, їх зберігання та пошук за схожістю. Усі навчальні матеріали працюють саме так, тому це стало стандартом, і ніхто не перевіряв його порівняно з чимось простішим.
Цього року одна стаття провела такий тест. На тестовому майданчику LoCoMo базова конфігурація, що складалася з папки з текстовими файлами та інструменту grep, показала кращі результати, ніж кілька професійних продуктів для зберігання пам’яті, створених за спеціальними завданнями. Порівняння не було симульованим. Системи з вбудованими елементами, пошуком за схожістю та іноді графовою пам’яттю програли конфігурації, підготовка якої займає півдня.
Якщо добре подумати, пояснення здається зрозумілим. Пошук за схожістю знаходить відповіді, але не міркує. Він добре справляється з пошуком тексту, який за значенням близький до запиту. Однак він погано справляється з завданнями, що вимагають пам’яті, наприклад, з розпізнаванням того, що факт з трьох тижнів тому був замінений вчорашнім, або того, що дві збережені інформації суперечать одна одній і одна з них мусить бути обрана. Індекс не має уявлення про час чи про необхідність корекцій, тому він повертає найближчі вектори та залишає модель саму помічати, що два з п’яти лідерів суперечать один одному.
Друга різниця стосується рівня знайомства, а не здібностей. Моделі були навчені на величезних обсягах матеріалів про роботу з файлами: їх відкриття, пошук, редагування, перелік папок, аналіз імпорту. Файли є близькими до первинних даних, на яких вони навчалися, і цикл з використанням grep та читання файлів використовує їх безпосередньо. На відміну від цього, API векторних запитів від постачальника — це те, що модель мусить навчитися ефективно використовувати в межах власного вікна контексту, майже не маючи попереднього досвіду. Це означає заміну вже наявної навички на іншу, яку потрібно опанувати під час виконання завдання, а також додавання затримок, пов’язаних із вбудовуванням даних та їх пошуком.
Посібник з вибору між цими двома варіантами, представлений поруч, виглядає ось так.
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 замість її анотації та виявило щось майже кумедне. 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
Жоден із цих складних рішень не є хибним. Векторні бази даних мають реальні сфери застосування, гіперграфи можуть стати корисними там, де ще ніхто не знайшов їх застосування, а штучні інтелектуальні агенти справді допомагають усунути найважчі аспекти інженерної роботи, що визнає й керівник проєкту з технологій. Помилкою було проігнорувати питання про те, чи спрямована додаткова складність на справжню перешкоду, чи лише на ту, яку найлегше охопити складним рішенням.
Ця звичка поширюється далеко за межі розробки агентів. Додати ще один рівень простіше, ніж запитати, чи коли-небудь базовий варіант був справедливо порівняний з ним. Нова абстракція вважається помітним прогресом, на який можна вказати та назвати його оновленням. Перевірка того, чи 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?
Усе це не означає, що потрібно менше інженерних зусиль. Це означає, що слід спрямувати інженерні зусилля на визначення місця утруднень ще до створення складних систем, які передбачають, що відповідь вже відома. Ці три дослідження не були проведені лише для контраргументу. Вони здійснили непривабливу, але необхідну перевірку, і результати цієї перевірки суперечили стандартним припущенням. Це набагато вищі стандарти, ніж просто смілива думка у гучному заголовку, і саме до них має підтримуватися будь-яка технологічна стек.
Пов’язана література
- Що знаходить агент для порівняння моделей: зміни стилю переважають над незначними налаштуваннями — Аудитор з чорної скриньки порівняв базову модель із фінансовим LoRA: 82% випробувань виявили зміни у довжині та структурі, тоді як заплановані зміни у логіці оцінки ризиків залишилися непоміченими.