Расскажу историю длиной в полгода, на которой я ясно ощутил все плюсы и ограничения современных инструментов работы с LLM.

Простая идея с глубокими последствиями

В августе 2025 года мой отец предложил создать поисковик-анализатор новостей: задаёшь список источников и запрос — система присылает сводку с ответами и ссылками. Казалось, это классическая задача для RAG: собрал, показал, получил аплодисменты. Я за 1–2 месяца в свободное время собрал рабочий прототип. Он умел искать по смыслу, генерировать ответы на основе найденных постов и даже помогал открывать статьи. В мыслях — салюты, шампанское, AI-единороги.

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

При тестировании выявились две серьёзные проблемы. Во-первых, сложные запросы вроде «причины шатдауна правительства США» давали мимо: либо находили только упоминания Трампа, либо вообще ничего. Во-вторых, система плохо понимала сущности: ЦБ РФ мог трактоваться как два отдельных слова или вообще как неизвестная абстракция. Обе проблемы указали на один фундаментальный изъян — чрезмерная зависимость от семантической близости. Это ведёт к размытию смысла на длинных запросах, непредсказуемому поведению имён собственных и поиску по частоте, а не по смыслу.

Особенно остро встал вопрос связей. Например, связь «Израиль — нефть — рубль» очевидна для любого, кто живёт в 2026 году, но её не найти через семантический поиск, как бы вы ни переформулировали запрос. Я начал искать альтернативы.

Ищем связи

Семантический поиск хорош, но он не видит связей между событиями и объектами. Обычный RAG — плоская система: он находит схожие тексты, но не понимает, как они связаны. Есть Graph RAG и Event-based RAG. Первый строит связи на основе совместного упоминания в документах. Это работает для статичных источников, вроде Кодекса, но не для динамичных новостей, где связи меняются, а сущности устаревают или приобретают новые значения.

Graph RAG слишком неповоротлив: он строит жёсткие связи, а в мире новостей сложно определить, что будет узлом — новость, событие или объект. А если появится сверхузел вроде «экономика», граф станет неуправляемым. Поэтому я выбрал Event-based RAG — подход, заточенный под динамические события и их связи. Подробнее — в статье arxiv.org/abs/2507.13396. Я рассмотрел готовые фреймворки, но в итоге решил написать свою реализацию — база уже была, а graphiti не подходил под мои задачи.

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

Я понял: ключевое — понять, что и как связывать. Цель — построить граф, который:

• легко обновлять (минимум усилий на изменение весов или рёбер);
• расширяет знания, а не дублирует частотную связанность;
• учитывает временной контекст;
• избегает сверхузлов.

Такой граф можно поддерживать в актуальном состоянии и использовать для расширенного контекста. Но как его построить?

Новость — это состояние объектов в момент времени. Проще: новость = событие = отношения объектов. Так родилась формула, которая до сих пор лежит в основе проекта: ARTICLE - EVENT - ENTITY.

Теперь нужно было разместить это в графе. Если хранить всё вместе, получится перепутанный клубок. Например, текст про катки и OpenAI окажутся в одной плоскости, а Трамп — центральным узлом с тысячами связей. Это неработаемо.

Решение — разделить данные на изолированные плоскости: статьи, события, объекты. Связи между плоскостями — жёсткие (неизменные): статья содержит событие, событие включает объекты. Внутри плоскостей — мягкие связи, которые рассчитываются динамически.

Например, статья:

Иран открывает Ормузский пролив для судоходства, сообщил глава МИД страны Аббас Арагчи. «В соответствии с прекращением огня в Ливане, проход для всех коммерческих судов через Ормузский пролив объявляется полностью открытым на оставшийся период прекращения огня», — написал министр в X. (источник).

В системе: статья попадает в плоскость постов, два события — в плоскость событий (с жёсткой связью к статье), объекты (Иран, Ормузский пролив, Аббас Арагчи, Ливан) — в плоскость объектов (с жёсткой связью к событиям). При поиске по «Ливан» алгоритм может найти «Ормузский пролив» через общее событие — именно это и нужно от «умного» поиска.

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

К тому моменту система напоминала франкенштейна с двумя пайплайнами:

Сохранение: по расписанию собираются посты из открытых Telegram-каналов. Они нормализуются, фильтруются и обрабатываются: из них LLM выделяет события и объекты, строятся эмбеддинги. Тексты идут в векторную БД, связи — в SQL.
Поиск: запрос перефразируется, выделяется временной интервал. Формируется несколько подзапросов, идёт семантический поиск, фильтрация, добавление слабо связанных событий, затем LLM суммирует найденные статьи и отвечает на вопрос.

Были и оптимизации: извлечение тегов, якорей, разные стратегии под типы запросов. В целом — почти готовое решение. Но изначальные цели — качество и удобство — не были достигнуты полностью.

Заказчик (опять же, папа) выдвигал требования, о которых я не подумал:

• если в посте есть «читайте дальше на сайте», система должна парсить внешнюю ссылку;
• нужно задавать тему и получать оповещения по расписанию;
• события надо проверять в зарубежных источниках и сравнивать интерпретации.

Я понял: впихивать всё в один проект — путь к неподдерживаемому швейцарскому ножу. Либо всё в одном промпте, либо в куче мелких инструментов — и везде потеря контроля.

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

Я несколько недель использовал агента на OpenClaw: он вёл учёт трат, искал товары, напоминал о событиях. Был впечатлён простотой и «дружелюбностью» интерфейса. Решил внедрить агента в свой проект. Решение пришло быстро:

• гиперперсонализация — зона ответственности агента пользователя;
• надёжность — задача модели данных и поисковых алгоритмов;
• сервис перестаёт быть точкой входа и становится инструментом в руках агента;
• следовательно, сервис должен быть источником знаний, хранилищем и набором инструментов.

Я разбил проект на минимальные функции и открыл к ним доступ через авторизацию. Результат:

Сервис стал понятным источником знаний с контролируемыми инструментами. Агент сам решает, какой запрос задать, с какими фильтрами, когда отправить, может вести локальный кэш, искать и добавлять статьи. На него легли две ключевые задачи: персонализация и парсинг источников.

Смена парадигмы — с push на pull. Это принципиально: ответственность разделена, пользователь получает свободу. С точки зрения бизнеса: зачем продавать доступ к API, следить за тарифами, бороться с ботами? Лучше продавать доступ к платформе — хранилищу и MCP-серверу для агентов. Агенты пользователь настраивает сам: из шаблонов или покупает отдельно. Для меня это — новый взгляд на мир.

Ограничения и открытые вопросы

Статья упрощает некоторые проблемы. Например, безопасность источников: если разрешить внешним пользователям добавлять данные, злоумышленник может заспамить систему. Для «семейного» проекта это не критично, но в продакшене нужна защита.

Вторая проблема — память. Она не решена. Входная точка поиска — всё ещё семантический поиск. Я исследую ассоциативную память, но пока без значимых результатов.

Эта статья — рассказ о попытке уйти от плоского поиска в конкретной задаче. Искренне благодарю за внимание и за то, что дочитали до конца.

Расскажу историю длиною в полгода на которой прекрасно прочувствовал все прелести современных инструментов и способов эксплуатации 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 сервер для его агентов, а агентов он настроит сам из заготовленных инструкций или купит отдельно. Для меня это в целом новый взгляд на мир!

P.S. Эта статья избегает довольно многие проблемы, как минимум самая важная из них - отдавать на out-source заполнение источников довольно опасно и злоумышленник может попробовать накидать тонну треш контента или чего похуже. Эта проблема требует отдельного решения, но если проект сделан “для семьи” то ничего страшного в этом нет.

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