К содержанию
hegai.media
Новости

Почему «мозг компании» для LLM сложнее, чем поиск по векторной базе

Почему «мозг компании» для LLM сложнее, чем поиск по векторной базе

Компании, которые внедряют LLM, часто пытаются собрать единый слой контекста из внутренних данных: от warehouse-схем и wiki до обсуждений в Slack и рабочих правил, которые нигде формально не зафиксированы. На первых тестах такой подход обычно выглядит убедительно. Но демонстрационный прототип с embedding-поиском и подстановкой top-k фрагментов в prompt быстро начинает сбоить, когда дело доходит до реальной эксплуатации.

Как пишет Towards Data Science, промышленная система такого типа, это не просто vector database, а целый набор процессов. Они постоянно синхронизируют источники, нормализуют данные в типизированные объекты, индексируют их разными способами и собирают нужный контекст в пределах token budget во время запроса. Авторы отдельно отмечают базовые ограничения, которые приходится учитывать: tenancy, права доступа, актуальность данных и стоимость обработки.

В материале подчеркивается, что синхронизация данных не бывает разовой задачей. Таблицы удаляются, страницы редактируются, каналы архивируются, меняются права пользователей. Особенно сложной авторы называют обработку удалений. Данные могут исчезать как минимум шестью разными способами, и любая ошибка в логике приводит к тому, что система продолжает уверенно ссылаться на объекты, которых уже не существует.

Отдельно разбирается структура хранения контекста. Вместо набора разрозненных коннекторов предлагается описывать каждый источник как иерархическую datamap-модель с типами сущностей и связями между ними. Поведенческие данные тоже становятся частью контекста. Например, query logs помогают понять, какие таблицы действительно используются, а проверенные рабочие запросы оказываются полезнее для retrieval, чем сами schema-метаданные.

Ключевые факты

  • Авторы описывают ingestion как непрерывный reconciliation loop, а не пакетную загрузку данных.

  • Система использует typed context items с идентичностью, построенной из tenant, type и path.

  • Для bounded collections и unbounded streams требуются разные механики удаления данных.

  • Query logs используются для выявления реально используемых таблиц и joins, а проверенные запросы становятся retrievable-объектами.

Вопросы и ответы

Почему prototype на vector search перестает работать после первых тестов?

Потому что в реальной эксплуатации контекст постоянно меняется: таблицы удаляются, wiki-страницы редактируются, Slack-каналы архивируются, а права доступа обновляются. Авторы описывают ingestion не как разовую загрузку, а как непрерывный reconciliation loop с учетом tenancy, access control, актуальности данных и token budget.

Что именно предлагают хранить вместо «набора коннекторов» к источникам данных?

Авторы предлагают иерархическую datamap-модель, где каждый объект хранится как typed context item с идентичностью из tenant, type и path. Это позволяет единообразно связывать warehouse-схемы, документы, сообщения и рабочие правила в одном контекстном слое.

Как система понимает, какие данные реально полезны для retrieval?

Для этого используются query logs: по ним выявляют таблицы и joins, которые сотрудники действительно используют. Проверенные рабочие запросы затем становятся retrievable-объектами и могут быть ценнее для LLM, чем сами schema-метаданные.

Контекст по теме