Стандартный совет по построению памяти для ассистента звучит так: поднимите векторную базу. Дальше идёт список из пяти названий и таблица с бенчмарками на миллиард векторов. Для персонального ассистента этот совет почти всегда неверен, и цена его исполнения — отдельный сервис, который нужно запускать, обновлять, бэкапить и синхронизировать с основной базой, где живут сами тексты.
Ниже — где проходит настоящая граница и по какому признаку её видно. Характеристики сторонних продуктов проверялись 26.08.2026; проверьте актуальность.
#Что вообще называют векторной базой
Три разных класса решений носят одно имя, и путаница начинается здесь.
Расширение к существующей базе. Векторы лежат в вашей обычной базе, рядом с текстом, и обслуживаются тем же процессом. Для SQLite это sqlite-vec, для PostgreSQL — pgvector. Отдельного сервиса нет вовсе.
Встраиваемая библиотека. Индекс живёт в памяти процесса или в файле, но это отдельное хранилище со своей жизнью: FAISS, Chroma в файловом режиме, LanceDB. Сервера нет, но синхронизация с основной базой — ваша забота.
Серверная база. Отдельный процесс, часто отдельная машина, сетевой протокол, своя схема, свой бэкап: Qdrant, Weaviate, Milvus. Здесь появляется всё, за что платят инфраструктурой: горизонтальное масштабирование, репликация, фильтрация по метаданным на уровне движка.
Смешивать их в одном сравнении бессмысленно — они решают задачи разного масштаба. Вопрос не «какая база лучше», а «в каком классе вы находитесь».
#Порог, после которого нужен следующий класс
Ориентиры ниже — про личный и командный масштаб, и их стоит проверять на своих данных, а не принимать на веру.
| Признак | Расширение к базе | Встраиваемая | Серверная |
|---|---|---|---|
| Порядок числа векторов | до сотен тысяч | миллионы | десятки миллионов и выше |
| Отдельный процесс | нет | нет | да |
| Фильтрация по владельцу | обычным SQL | вручную | в движке |
| Что бэкапить | один файл базы | база плюс индекс | база плюс кластер |
| Кто чинит рассинхрон | никто, его нет | вы | вы |
Строка про рассинхрон — главная. Когда векторы лежат в другом хранилище, чем тексты, у вас появляется класс ошибок, которого раньше не было: запись удалена, а её вектор остался; запись отредактирована, а вектор старый; индекс пересобран не полностью. Ассистент при этом не падает — он тихо находит призраков. Для персональной памяти это худший из возможных сбоев, потому что выглядит он как «ассистент помнит то, чего не было».
#Почему для личного ассистента почти всегда хватает расширения
Посчитайте свой объём. Активный чат с ассистентом — это единицы тысяч сообщений в год. Личная память в виде отобранных фактов — сотни записей. Даже с архивом переписки за несколько лет вы остаётесь в диапазоне, где поиск ближайших соседей по всей таблице выполняется быстрее, чем модель успевает загрузиться в память.
В Persona это решение принято явно и записано в коде: векторная таблица — виртуальная таблица vec0 внутри той же базы SQLite (миграция 186_vec_memory.sql), а метаданные сообщений лежат в обычной таблице рядом. Отдельного сервиса нет, бэкап — это копирование одного файла, а удаление аккаунта чистит вектор и его метаданные в той же транзакции, что и сообщения (app/auth/account_delete.py). Ни одного из перечисленных выше классов рассинхрона тут не возникает по построению.
Второе следствие того же решения: векторный слой можно вообще не включать. Расширение sqlite-vec не входит в зависимости проекта — если его нет, миграция с vec0 не применяется, а поиск работает на полнотекстовом индексе. Это не деградация функциональности, а нормальный режим по умолчанию, и почему он выбран именно таким, разобрано в разборе гибридного поиска.
#Когда отдельная база действительно нужна
Четыре ситуации, где совет «поставьте расширение и не думайте» перестаёт работать.
Несколько приложений читают один индекс. Как только векторы нужны второму сервису, встроенное решение превращается в узкое место: файл базы не рассчитан на конкурентную запись из разных процессов.
Фильтрация по многим полям одновременно с поиском. Если типичный запрос звучит как «ближайшие соседи среди документов этого проекта, за последний квартал, с определённым тегом», серверные движки делают это внутри индекса, а не постфильтром после выборки. На больших наборах разница принципиальная.
Объём перестал помещаться в память. Точный поиск по всей таблице — линейная операция. Пока векторов сотни тысяч, это доли секунды; на десятках миллионов нужен приближённый индекс с настройкой параметров. Что такое приближённый поиск и чем он платит за скорость — в справке про KNN и ANN. Полезно при этом отдельно померить, где реально упирается ваш поиск: разбор производительности полнотекстового индекса SQLite на миллионах строк показывает, что текстовая часть держится дольше, чем ожидают.
Требуется отказоустойчивость. Репликация, шардирование, живое переключение — этого во встроенных решениях нет и не будет.
Если ни один из четырёх пунктов не про вас, отдельная база добавит вам работы и не добавит качества ответов.
#Что стоит проверить перед выбором
Прежде чем сравнивать продукты, ответьте на три вопроса о своих данных — они отсекают больше вариантов, чем любой бенчмарк.
- Сколько у вас записей на самом деле? Не «сколько будет через три года», а сколько есть. Оценка «через три года» почти всегда завышена на порядок.
- Какая доля ваших запросов вообще выигрывает от поиска по смыслу? Возьмите два десятка реальных вопросов к своему архиву и разметьте, в каких из них ключевые слова точнее. Если таких больше половины — приоритет надо отдать полнотекстовому индексу, а не векторам.
- Кто будет чинить индекс через полгода? Если ответ «я, в свободное время» — берите то, что не требует обслуживания.
Практическая сторона установки расширения к SQLite, схема таблицы и логика отката, когда расширения нет, разобраны в гайде по sqlite-vec. Как этот слой встраивается в общую механику памяти — в статье о том, как работает память у ИИ.
#Где серверные базы объективно лучше
Честно про сильную сторону тех решений, которые я выше советую не брать. Серверные векторные базы решают задачи, которые расширению не по силам: приближённый поиск с настраиваемым компромиссом точности и скорости, фильтрация внутри индекса, распределённое хранение, обновление индекса без остановки чтения, встроенные метрики качества выдачи. Если вы строите поиск по корпоративной базе знаний на сотни тысяч документов и десятки одновременных пользователей — это их территория, и попытка обойтись файлом SQLite там закончится плохо.
Кроме того, у зрелых серверных решений заметно лучше инструменты наблюдения: видно, какие запросы медленные, какая доля индекса просканирована, где деградировала выдача. Во встроенном варианте этого нет — вы наблюдаете за качеством вручную.
#Частые вопросы
#Правда ли, что SQLite не годится для векторного поиска?
Не годится для больших объёмов и конкурентной записи из многих процессов. Для персонального масштаба — годится: расширение sqlite-vec даёт точный поиск ближайших соседей, а данные остаются в одном файле вместе с текстами.
#Чем расширение к базе хуже специализированного движка?
Отсутствием приближённых индексов и фильтрации внутри индекса. Пока данных мало, точный перебор быстрее и точнее любого приближения, поэтому недостаток не проявляется. Проявится он ровно тогда, когда перебор станет заметен по времени.
#Можно ли начать с расширения и потом переехать?
Да, и это разумный порядок. Переезд стоит одной переиндексации: тексты у вас уже есть, векторы пересчитываются заново тем же эмбеддером — а выбор эмбеддера при переезде важнее выбора базы, см. обзор embed-моделей. Обратная последовательность — сначала поднять кластер, потом выяснить, что нужен один файл, — обходится дороже.
#Нужно ли хранить сам текст в векторной базе?
Хранить надо ссылку на текст, а сам текст держать там, где он уже лежит. Дублирование текста в двух хранилищах — это и есть источник рассинхрона: удалили в одном месте, забыли в другом.
#Сколько весит векторный индекс?
Порядок оценивается просто: размерность, умноженная на четыре байта, умноженная на число записей. Для 768 измерений это около трёх килобайт на запись, то есть примерно 30 мегабайт на десять тысяч записей. Индексные структуры добавляют сверху, но на этом масштабе прибавка несущественна.
#Вывод
Если у вас личный или командный архив, один процесс и объём в пределах сотен тысяч записей — берите расширение к той базе, которая у вас уже есть, и не заводите второе хранилище. Если у вас несколько потребителей индекса, фильтрация внутри поиска или объём, не помещающийся в память, — расширение вас не спасёт, берите серверное решение сразу. Промежуточный вариант со встраиваемой библиотекой оправдан реже всего: он уже приносит проблему синхронизации, но ещё не даёт возможностей сервера.