Чи справді запланованим AI-агентам потрібна векторна база даних?

Запланований AI-агент може жити в n8n і запускатися щоранку о шостій, щоб розібрати нічні звернення до підтримки, або бути сценарієм Make, який готує щотижневий звіт для клієнта. Рано чи пізно виникає та сама стіна: агент прокидається порожнім і не знає, що сталося вчора. Інструкції про те, як дати агенту пам'ять, майже завжди починаються однаково: векторна база даних, конвеєр embeddings і індекс, який треба тримати синхронізованим із даними.

Перш ніж усе це будувати, розробник Abdeljabbar Elassali в аналізі на dev.to ставить простіше запитання: чи справді запланованому агенту потрібна векторна база даних? На його думку, для більшості задач автоматизації чесна відповідь: ні, поки що ні, а можливо, й ніколи.

Пошуковий індекс це не пам'ять

Векторна база зберігає embeddings і повертає записи, найближчі за змістом до запиту. Якщо запитати, у яких минулих запусках ішлося про суперечки щодо повернення коштів, вона знайде семантично схожі записи навіть тоді, коли в жодному з них немає слова refund. Це корисно, пише він, і на цьому її завдання вичерпується. База не вирішує, що варто запам'ятати, і не прибирає застарілі факти; що зберігається, що потрапляє в prompt і що видаляється, це архітектура, яку будують навколо неї.

Що насправді потрібно запланованому агенту

На старті запуску агенту потрібні незмінні факти роботи (ім'я клієнта, голос бренду, пороги), місце, де зупинився попередній запуск (останній оброблений ID тікета, курсор), уподобання, які рідко змінюються, і засвоєні уроки, як-от постачальник, чиї рахунки завжди потребують другої перевірки. Три з чотирьох категорій це пошук за ключем: агенту не потрібно щось схоже на ім'я клієнта, йому потрібне саме ім'я. Пропускати такі факти через конвеєр embeddings означає платити за виклик embedding на кожному читанні й додавати затримку. Його правило: якщо пам'ять вміщається на одному екрані й кожне згадування має відомий ключ, векторна база не дає нічого.

Коли пошук за схожістю виправдовує себе

Вектори з'являються тоді, коли архів великий і неструктурований, а запит на згадування розмитий. Elassali розрізняє векторний пошук і окрему векторну базу: pgvector у вже наявному Postgres покриває більшість задач агента, а Pinecone, Qdrant, Weaviate і Milvus створені для високих обсягів запитів, гібридного пошуку та складних фільтрів. Справжня пам'ять агента, додає він, має чотири завдання: зберігання, вилучення, відбір і гігієну; векторна база лише один із можливих бекендів для половини другого завдання. Як скорочення він називає Vilix AI, хмарний шар пам'яті, що підключається до інструментів через MCP і супроводжує агента в n8n, Make, Claude, Codex, Cursor і OpenClaw, пропонуючи безкоштовний план і 7-денний Pro-тріал. Висновок автора: починайте з того, що агент справді запитує, а векторний пошук додавайте лише тоді, коли розмите згадування стане вимірюваною потребою.