Вопросы к стеку агентов: векторные хранилища, гиперграфы и задачи кодирования
Три случая, когда более сложные стеки агентов не смогли выявить настоящий узкий место: память агентов на основе файлов оказалась эффективнее векторных хранилищ, гиперграфных систем 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 с рассмотрения pull-реквестов. Приходящий код, большая часть которого написана с помощью ИИ, явно лучше того, что он рассматривал два года назад. Он не сомневается в том, что ИИ способен писать хороший код; он полностью это принимает, но затем отмечает, насколько мало это меняет в той работе, которую он на самом деле выполняет.
Это ставит под сомнение распространённое предположение при рассмотрении стеков агентов, согласно которому именно функциональные возможности определяют темпы автоматизации. Согласно этой логике, если модель генерирует правильный код, то для его написания больше не требуется человек, а автоматизация работы соответствует той части процесса, которая связана с созданием кода. Руководитель технической команды утверждает, что такая формула никогда не была верна, и искусственный интеллект лишь делает недостатки заметными. Его работа заключалась не столько в написании кода, сколько в координации: выборе того, что нужно создать, и в каком порядке, ведении переговоров о объёмах работ с людьми, у которых противоречивые приоритеты, проверке решений, принятых другими, их поддержке, обслуживании устройств для срочных сообщений, наставничестве у младших инженеров и посредничестве между требованиями заинтересованных сторон и тем, что система может безопасно обеспечить. Ни одна из этих задач не является задачей по написанию кода.
Возможно, это самый упускаемый из виду аспект в дискуссиях среди инженеров в этом году, даже более важный, чем любые показатели эффективности, поскольку он объясняет, почему значительно лучшие результаты тестов на кодирование и гораздо прощая работа не сопровождаются друг другом у многих старших инженеров, даже у энтузиастов-ежедневных пользователей. Рост оценок SWE-bench с однозначных цифр до семидесятых в течение нескольких лет — это реальный и значительный шаг. Однако это не приводит к сокращению объема работы на 70%, потому что написание кода никогда не составляло 70% работы, особенно когда в обязанности входит чередование дежурств, планирование разработки и рассмотрение pull-реквестов.
Одно ограничение: третий пункт менее эффективно применяется к другим настройкам, чем первые два. Утверждения о векторных базах данных и гиперграфах можно проверить с помощью эталонов или доказательств. Разделение времени старшего инженера между координацией и написанием кода варьируется в зависимости от размера компании, уровня зрелости команды, от того, является ли дополнительная работа проявлением дисфункций или необходимой для выполнения задач, а также от стажа самого сотрудника. Команда из пяти человек в компании из тысячи с политикой «создай и запусти» — это один тип работы, который не отражает все инженерные должности. Направление корректировок в целом остается верным. Ограничения возможностей агентов определяют, насколько можно автоматизировать процесс написания кода, но они почти ничего не говорят о процессе координации, который никогда не зависел от скорости ввода или качества кода.
Общая закономерность
Если разместить три примера рядом друг с другом, становится ясно, что урок касается не столько векторных баз данных, гиперграфов или возможностей искусственного интеллекта, сколько разницы между тем, где, по мнению специалистов, находилась узкая точка, и тем, где она на самом деле была.
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% случаев были обнаружены изменения в длине и структуре, тогда как предполагаемое изменение в логике оценки рисков осталось незамеченным.