Изначальная задача была простой: пользователь задает список источников и пожелания, а система в выбранный интервал присылает сводку новостей и отвечает на вопросы. За 1–2 месяца появился прототип с семантическим поиском, LLM-ответами и открытием найденных постов, но сложные запросы и имена собственные быстро показали пределы семантической близости: длинные формулировки размывались, аббревиатуры вроде ЦБ РФ распознавались нестабильно, а причинные связи между событиями не находились.

Вместо плоского RAG автор перешел к модели ARTICLE — EVENT — ENTITY: статья фиксирует состояние объектов в момент времени, события описывают отношения объектов, а сущности живут отдельно от текстов и событий. Тексты новостей, события и объекты разнесены по разным «плоскостям»; связи между плоскостями считаются жесткими, а связи внутри плоскостей могут пересчитываться динамически. Это должно помогать находить не только похожие тексты, но и связанный контекст: например, выйти от Ливана к Ормузскому проливу через общее событие и набор сущностей.

Рабочая система собирала посты из открытых Telegram-каналов, нормализовала их, фильтровала рекламность, выделяла через LLM события и объекты, сохраняла тексты в векторную БД, а связи — в SQL. На поиске она перефразировала запрос, выделяла временной интервал, делала несколько запросов к базе, добавляла связанные события и суммаризировала найденные статьи. Затем автор решил не наращивать сервис как универсальный «швейцарский нож», а разделить ответственность: агент отвечает за персонализацию, выбор источников, парсинг и расписание запросов, а сервис становится авторизованным хранилищем, MCP-сервером и набором контролируемых инструментов.