Почему в современных архитектурах ИИ-агентов простота превосходит сложность
В этой статье рассматриваются три аргумента 2024 года против векторных баз данных, памяти типа гиперграф и сложности оркестрации, показывающие, что более простые системы зачастую превосходят сложные стеки агентов.
Прочитав достаточно материалов об ИИ-агентах в этом году, становится очевиден определённый паттерн ещё до того, как появляются какие-либо аргументы. Почти все предложения сводятся к дополнению существующей структуры: добавляется слой памяти, граф, фреймворк оркестрации или система поиска с тремя этапами переранжирования. Также добавляются новые агенты, задача которых — контролировать уже существующие агенты. В основе почти всего этого лежит одна и та же негласная предпосылка: что сложность равносильна прогрессу, и если ваша система не стала более сложной по сравнению с полугодием назад, значит, вы отстаёте.
Вероятно, команда, занимающаяся разработкой агентов для сборки конструкций, уже создавала элементы похожей архитектуры и тогда могла обосновать некоторые из своих выборов. Поэтому, когда в этом году появились работы с противоположными аргументами, утверждающими, что такие сложные дополнения, скорее всего, не стоили усилий, им следовало уделить больше внимания, чем обычно получают заголовки вроде «этого не нужно». Большинство контраргументов в технической литературе — это просто обратный хайп, такой же уверенный, но столь же лишённый доказательств. Эти три аргумента были иными. Каждый из них основан на чём-то проверяемом: результатах тестирования, структурных аргументах или простом описании того, как на самом деле происходит работа в повседневной практике. Именно этот стандарт следует применять здесь, и именно ему будет соответствовать вся остальная часть этой статьи.
Ниже приведены три примера. В каждом случае для решения задачи прибегали к более сложной архитектуре, хотя на самом деле проблема была гораздо менее значимой.
Первый случай: вашему агенту, скорее всего, не нужна векторная база данных
Решение о использовании памяти агента для хранения данных с помощью векторного хранилища обычно принимается за секунды. Кто-то формулирует требование: «Агент должен помнить информацию между сессиями», и автоматическим ответом становится: сохранить данные в виде векторов, хранить их и восстанавливать по сходству. Это стандартный подход не потому, что кто-то сравнивал его с альтернативами, а потому что все учебные материалы показывают именно такой способ.
Именно эту гипотезу проверяется одна из статей этого года — «Вашему ИИ-агенту не нужна векторная база данных», авторства Анубхава. Заслуживающий внимания результат получен в ходе тестирования на базе критериев 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, основная идея которой заключается в том, что собственные гиперрёбра имеют ключевое значение, на самом деле хранит всю информацию внутри стандартной базы данных графов с использованием обычных бинарных рёбер. Что ещё более показательно, сами авторы статьи демонстрируют, что такая трансляция — разбиение каждого гиперрёбра на небольшой кластер бинарных рёбер, связанных с узлом, представляющим соответствующее событие — не приводит к потере ничего. Никакая информация из исходной структуры не теряется в процессе преобразования. Предположительно более точное представление в виде гиперграфа и «скучная» версия с бинарными рёбрами могут быть восстановлены друг из друга с полной точностью.
ly.Это не какая-то незначительная примечание к реализации — это подрывает всю аргументацию. Если нативный гиперребро и кластер бинарных рёбер, представляющий роли, кодируют одну и ту же структуру инцидентности, причём каждый из них можно легко воссоздать из другого, то выбор одного вместо другого на самом деле не является моделировочным решением с последующими последствиями. Это просто выбор формата хранения. Комментатор этой статьи, Феликс Андерсон, сформулировал соответствующую математику максимально ясно: гиперребро и бинарная граф, представляющая роли, описывают одну и ту же структуру инцидентности, а ширина гипердрева изменяется лишь на константный коэффициент при ограниченной аритметике. Ширина гипердрева — это реальная мера сложности, определяющая стоимость выполнения запроса; это не количество шагов и не количество участников, помещённых в одно ребро. Если смена представлений изменяет этот показатель лишь на константу, а каждый факт...
Если количество участников ограничено (что характерно для практически всех реальных ситуаций — несколько человек в цепочке утверждения, а не тысячи), то весь инженерный труд, затраченный на переключение, не приносит никакой пользы с точки зрения фактора, который на самом деле влияет на стоимость запроса.Стоит объективно рассмотреть, почему так легко впасть в это заблуждение. Количество прыжков кажется интуитивным показателем: чем больше узлов между вопросом и его ответом, тем сложнее, кажется, должен быть запрос. Однако ширина гипердрева совсем не является интуитивной величиной — она основана на теории удовлетворения ограничений и сложности запросов, и может изменяться таким образом, который никогда не указывается количеством прыжков, если только кто-то специально не проверит это. Вполне возможно добавить структурную сложность, которая снизит количество прыжков для тщательно выбранного примера запроса, не затрагивая при этом основной класс сложности, или даже ухудшить его немного. Приведенные в статье примеры могут казаться впечатляющими, но при этом не говорить ничего значимого о общем случае.
Вот сравнение сторона в сторону, которое стоит рассмотреть перед выбором между обычной графом, реифицированным графом или нативным хранилищем гиперграфов:
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?
Всё это не означает, что в целом следует заниматься меньшим объёмом инженерной работы. Это означает, что необходимо сосредоточить усилия инженеров на выявлении реального места узкого места, прежде чем создавать сложное решение, предполагающее, что ответ уже известен. Три приведённых здесь примера были выбраны не для создания эффекта шока. Они получили такой статус потому, что кто-то выполнил непримечательную работу по проверке, и результаты этой проверки противоречили общепринятым предположениям. Это гораздо более высокий стандарт, чем просто яркая заголовочная строка с резким мнением, и именно к такому стандарту следует стремиться при работе со своими технологическими стеками в будущем.
Связанная литература
- Понимание ИИ-агентов: цели, инструменты, память и цикл действий агента — простое для новичков объяснение того, чем ИИ-агенты отличаются от чат-ботов, с описанием основных компонентов, цикла принятия решений, уровней автономии и практических применений.
- Понимание памяти ИИ: контекст, эмбеддинги, RAG и параметры модели — в этой статье разбирается, как именно ИИ-системы хранят информацию, с упором на окна контекста, эмбеддинги, векторные базы данных, технологию RAG и параметры модели.