Почему векторные базы данных не подходят для масштабирования агентских систем памяти
Векторные системы поиска и извлечения информации (RAG) выглядят привлекательно при демонстрации: передайте запрос, получите похожие фрагменты, вставьте их в контекст – готово. Но когда дело доходит до масштабирования и совместной работы нескольких агентов со временем, эта система начинает давать сбои.
Проблемы векторного подхода:
- Смешение поиска и согласования: RAG предполагает, что вся информация является аддитивной, конфликты отсутствуют, а агенты не перезаписывают друг друга. На практике это приводит к потере причинно-следственных связей и намерений изменений.
- Отсутствие истории изменений: Векторы представляют собой статические снимки состояния, которые не могут показать эволюцию смысла или происхождение данных.
- Потеря контроля над изменениями: Без версии вы теряете контроль над тем, кто изменил данные последним и почему эти изменения были сделаны.
Как решает проблему версия SQL?
Версия SQL предлагает подход, аналогичный системе управления версиями Git, но адаптированный для структурированных данных. Основные преимущества:
- Хеширование записей: Каждая запись имеет уникальный хэш-код, который позволяет отслеживать её историю изменений.
- Директория направленного графа (DAG): Изменения образуют граф зависимостей, где каждая модификация связана с родительским состоянием.
- Контроль конфликтов через явное слияние: Конфликты разрешаются явно, сохраняя историю изменений и предотвращая потерю данных.
Пример использования
Представьте двух агентов, одновременно обновляющих одну и ту же запись клиента. Один добавляет новый адрес, другой помечает аккаунт как неактивный. В системе RAG оба обновления исчезают в пространстве вложений, и неизвестно, какое изменение победит. Версия SQL сохраняет обе модификации как отдельные коммиты, позволяя выбрать стратегию разрешения конфликта либо автоматически, либо вручную.
