Наглядный пример, зачем нужны агенты

Расскажу историю длиною в полгода на которой прекрасно прочувствовал все прелести современных инструментов и способов эксплуатации llm.

Идея до жути простая и наверняка встречалась или приходила в голову очень многим, кто начинал задумываться об использовании llm api или после знакомства с rag. В августе 2025 года папа предложил мне создать хороший поисковик-анализатор новостей: ты даешь ему список источников и пожелания того, что хочешь увидеть в ответе, он тебе присылает в выбранный интервал сводку с источниками и отвечает на твои вопросы. Казалось бы, классическая задача чтобы показать всем удачное применение rag, словить аплодисменты и разойтись. Так показалось и мне, и я буквально за 1-2 месяца работая в свободное время собрал вполне достойный прототип. Он умел хорошо искать семантически, просить llm сформировать ответ на основе найденных постов и даже помогал их открывать. В мыслях салюты, шампанское и ai единороги.

Но реальность

Довольно быстро на самотестировании я нашел два серьезных упущения: первое – сложный запрос для такой системы оставался недопустимой роскошью: попытка найти “причины шатдауна правительства США” в лучшем случае приводила меня к заголовкам про Трампа и что-то там про переговоры, а иногда и вовсе такого рода запросы не давали никакой выборки по базе; второй серьезной проблемой стало абсолютное непонимание предметной области, если того же Трампа вектора в базе еще ставят в один ряд с Америкой и политикой, то вот ЦБ РФ может запросто восприниматься как Россия или вообще непонятная модели сущность, а может вообще трактоваться как два отдельных слова. В целом обе эти неприятности подсвечивают один известный изъян всей системы – слишком большое доверие к семантической схожести и вытекающие из нее проблемы: размытие смысла на длинных запросах, непредсказуемое поведение имен собственных, поиск связей по частотному сходству, а не смыслу.

Последняя из перечисленных проблем заставила меня задуматься глубже над самим подходом. Если длинные фразы можно разбить на несколько запросов с той же llm, а неизвестные сущности и аббревиатуры с помощью поиска подменить при запросах в базу используя обычный web поиск, то вот связь уровня “Израиль – нефть – рубль” найти не так просто по самой семантике как ты не переделывай запрос, хотя любому человеку живущему в 2026 абсолютно ясно в чем тут дело. Я начал одновременно делать две вещи: искать и придумывать.

Ищем связи

Семантическая близость – штука хорошая и на ней лишь одной можно построить хороший retrieval, но между объектами существует гораздо большее чем просто упоминания в тексте. Обычный rag выглядит довольно плоско, он хорошо найдет по синонимам какие-то схожие вещи в базе, если прикрутить к нему рефраз и фазу обдумывания (что я и сделал), можно получить даже неплохого помощника в организации порядка в куче разрозненных фактов, но ключевое – он не видит связи между событиями и объектами. Хорошо, есть graph rag и event based rag. Первый связывает данные на основе факта сожительства внутри конкретной системы – то же совместное упоминание, но не в тексте, а в каких-то сущностях конкретного проекта – например документе. Это хорошо сработает, когда есть статичный хорошо организованный источник вроде уголовного кодекса – вот здесь graph rag идеально свяжет статьи, но у нас постоянно меняющаяся система знаний и событий, которые ЖИВУТ – они устаревают, теряют актуальность или же обретают новые смыслы. Graph rag тут неповоротлив по двум причинам, потому что строит жесткие связи, которые часто меняются и потому что абсолютно невозможно представить что в этой системе будет вершиной графа, новость? объект? событие? А что если они начнут смешиваться или выделится объект по типу “экономика”, представляете сколько связей у него будет и как тяжело будет развязывать такие сверхузлы. Что касается event based rag, то это то что я выбрал в качестве нового витка эволюции, как систему разработанную под связывание именно событий и динамического обновления связей. Кратко о подходе можно прочитать в статье https://arxiv.org/abs/2507.13396 она совсем небольшая и идея в целом витала в воздухе в индустрии. Я рассмотрел несколько уже готовых фреймворков, среди которых больше всего мне подходил graphiti – изначально заточенный на коммуникацию с клиентами, но взвесив все доработки, решил писать свой велосипед, тк готовая база уже была.

Дао мягких и жестких связей

Я довольно быстро понял, что самое важное при построении связей, выделить что и как будет связано. Чтобы понять что строить, нужно понять чего хочется. Хороший граф в моем понимании должен обладать следующими свойствами:

• операция по изменению веса ребер или их переопределению должна стремиться по сложности к минимуму

• связи в графе должны расширять знания, а не дублировать частотную связанность

• нужно учитывать жесткие параметры (в первую очередь временной контекст)

• сам подход должен исключать проблему сверхузлов

Обладая такими свойствами графом легко манипулировать для поддержки знаний в актуальном состоянии. Также он даст нам возможность иметь расширенный контекст знаний, а вот по какому принципу выбирать эти знания пишу дальше.

Задача довольно конкретная – понимание новостного контекста, доменное поле можно сузить до… И тут тупик, попытаюсь написать, как мысленно я из него выходил:

Ну начнем с самого очевидного – у новости есть значение актуальности в виде даты публикации. Новости очень часто дублируются в разных источниках, поэтому можно связывать заголовки как дубликаты и оригиналы (есть очень классный проект https://github.com/NyanNyanovich/nyan в котором очень хорошо решается именно эта проблема). Ну вроде какая-то база есть, осталось найти что-то важное. Вроде как в каждой новости есть объект(-ы) и они даже как-то взаимодействуют, выделим их, пригодятся! И теперь остается все связать и получить что не хватает состояния – вот оно новость = состояние объектов в момент времени, если говорить проще то любая новость состоит из событий, а события из отношений объектов. Так я вывел формулу, которой придерживаюсь до сих пор и которая оказывает серьезнейшее влияние на меня самого и мое мировоззрение: ARTICLE – EVENT – ENTITY

Отлично! Поле есть, остается его вспахать уместить в граф. Сложно представить как текст статьи про открытие сезона катков встанет в одну плоскость с каким нибудь объектом вроде OpenAI, получается мы смешаем сущности и их отношения и опять придем к невероятно разросшемуся графу с центральным узлом в виде Дональда Трампа, где связи тяжело как менять так и поддерживать, толк попросту пропадет. Для самого себя 4 месяца назад я сейчас даю огромную подсказку, оглашая слово “плоскость”. Хранить совместно объекты и события с ними создают какую-то, на интуитивном уровне, неприятную циклическую зависимость, хорошо, но что нам мешает хранить их не рядом, но при этом связать между собой? Именно из этого вопроса родилась следующая картинка, которая до сих пор является фундаментом всего проекта.

Что здесь происходит: все “сущности” были отнесены к своим изолированным плоскостям, то есть тексты новостей живут в одной плоскости, события в другой и объекты в третьей, при этом связи сохраняются как между плоскостями, так и внутри них. Связь от одной плоскости к другой я назвал жесткой, потому что они неизменны, например если статья содержит событие, то после публикации никак это событие оттуда не пропадет, точно так же как и объект не пропадет из события. Такие связи помогают хорошо сохранять нить событий и связок, когда в одной статье мы встречаем события А и Б, то условный алгоритм поиска, который нашел событие А выйдет и на событие Б пройдя через общего родителя, тем самым образовав уже “мягкую” связь между этими двумя событиями. Например вот статья, в которой упоминаются два события:

Иран открывает Ормузский пролив для судоходства, сообщил глава МИД страны Аббас Арагчи. «В соответствии с прекращением огня в Ливане, проход для всех коммерческих судов через Ормузский пролив объявляется полностью открытым на оставшийся период прекращения огня», — написал министр в X. (https://www.rbc.ru/politics/17/04/2026/69e22df89a7947d70a5d92db).

В плоскость постов добавится сам пост, в плоскость событий добавятся 2 события с “жесткой” связью к посту, а несколько объектов (Иран, Ормузский пролив, Аббас Арагчи, Ливан) добавятся в свою плоскость с “жесткой” связью к событиям. “Мягкие” связи в такой схеме будут рассчитываться динамически и при работе итогового алгоритма будут суммой всевозможных факторов, в том числе по наличию общих узлов в других плоскостях. Таким образом при поиске новостей про Ливан, очень велика вероятность, что алгоритм набредет на Ормузский пролив или на Аббаса Арагчи, а это именно то, что мы и ждем от умного поиска и то, что никогда не даст только лишь семантический.

Как на данный момент работала система и чего ей не хватало

Вся система в тот момент выглядела как франкенштейн, у которого есть следующие два пайплайна:

Сохранение – запланированный процесс собирает новые посты с источников (только открытые тг каналы). Посты нормализуются, фильтруются по рекламности и отправляются на процессинг. Далее из постов с помощью llm выделяются события и объекты, строятся эмбеддинги и идет сохранение: текстовые данные в векторную БД, связи – в обычную SQL таблицу

Поиск – перефраз запроса, выделение статики (временной интервал). Потом формирование нескольких запросов в базу. Дальше поиск по каждому запросу: находим по семантике -> фильтр релевантных -> добавление в выборку связанных слабыми связями событий -> суммаризация всех найденных статей с помощью llm и попытка ответить на изначальный вопрос пользователя. На деле конечно было применено несколько оптимизаций вроде извлечения тегов и якорей, разные оптимизации под типы запросов (вопрос, поиск по сущности и тд), но это тема для отдельной публикации

Это уже работало неплохо и подход с моделью “пост – событие – сущность” похоже реально хорошо решает задачу. В целом готовое прод решение, но изначально перед проектом стояли следующие приоритеты: качество и удобство. Заказчик проекта (папа) приносил мне множество различных требований, которые я сам бы никогда не предусмотрел, вот некоторые из них:

• Есть посты в которых пишется заголовок и дальше текст по типу “а продолжение читайте на сайте (ссылка)” и нужно брать информацию с этого сайта, а не с поста

• Я хочу создать проект в котором укажу источники и дам ему задание искать информацию по теме и оповещать меня в выбранный интервал

• Все найденные события он должен проверять в зарубежных источниках и выписывать разницу в интерпретациях

Прикинул, какие еще могут быть требования у других пользователей, а еще что требования одного будут противоречить другому… И тут я подумал, что лепить что‑то в один проект гиблое дело, он просто превратится в неподдерживаемый швейцарский нож, а огромная часть «человеческой» функции будет размазана либо в каком‑то супер‑промпте, либо по куче маленьких тяжелоконтролируемых инструментам.

Агенты (самая важная часть статьи)

Несколько недель я использовал агента на openclaw для ведения журнала трат, поиска товаров, напоминаний в календаре и был очень доволен простоте использования и какой-то дружелюбности что ли. Этот опыт подвиг меня попробовать внедрить такого умельца в свой проект. В целом решение пришло быстро и не было сложно в реализации. Я понял, что нужно менять саму модель проекта и подход к пользователю, поэтому основные тезисы были такие:

• гиперперсонализация – зона ответственности агента на стороне пользователя

• надежность сервиса – ответственности модели данных и алгоритмов поиска

• сам сервис перестает быть точкой входа и становится инструментом в руках агента

• из предыдущего пункта вытекает необходимость развернуть сервис в сторону источника правды, набора инструментов и хранилища

И это по мне, самым правильным и очевидным решением было разбить весь проект на минимальные функции и дать к ним доступ агента под соусом авторизации. Что получилось в итоге:

Сервис превратился в понятный для агента источник знаний с минимальным набором хорошо контролируемых инструментов. Агент сам решает, какой запрос задать, какие фильтры по времени публикации поставить, когда этот запрос отправить, также агент может вести свой локальный кэш каких-то просьб от клиента, искать и посылать в базу статьи по своему решению. На агента перекладываются две важнейшие задачи – персонализация и поиск и парсинг источников. Если говорить в терминах очередей сообщений, то важнейшее изменение – смена  push модели на pull. И лично для меня это невероятно важное изменение и подвижка возможно во всей индустрии, которая разделяет ответственность, дает пользователю нереальную свободу и гибкость и, даже с точки зрения бизнеса: зачем пытаться продавать доступ к сервису, следить за тарификацией api llm, избегать преследований антиботов и тд. Можно же продать пользователю доступ к платформе по небольшой цене, это даст хорошо организованное хранилище и mcp сервер для его агентов, а агентов он настроит сам из заготовленных инструкций или купит отдельно. Для меня это в целом новый взгляд на мир!

Было:

Стало:

Еще немаловажным считаю подсветить проблему памяти: она в общем-то никак не решена и входной точкой поиска все равно выступает семантический поиск. Больше всего последнее время я пытаюсь исследовать ассоциативную память и то, как можно прикрутить ее к текущим моделям, но пока задача выглядит очень сложной и достойных результатов у меня нет. Эта статья – рассказать про мой опыт оптимизировать проблему плоского поиска на одной конкретной задаче. В любом случае искренне благодарен за то, что дочитали до этого момента!