Типичная картина: человек полдня выбирает разговорную модель, сравнивает семейства, читает обсуждения, ставит лучшее, что влезло в видеопамять, — и получает ассистента, который прекрасно рассуждает и при этом не может найти собственную заметку двухнедельной давности. Вывод делается неверный: «память не работает».
Память работает. Просто в ассистенте с памятью моделей две, они разного класса, и вторую — ту, что отвечает за поиск, — почти всегда выбирают по остаточному принципу или не выбирают вовсе. Разговорная модель отвечает на вопрос. Embed-модель решает, какие фрагменты вашего архива этот вопрос вообще увидит. Если вторая ошиблась, качество первой не имеет значения: она получит не тот контекст и уверенно ответит не о том.
Этот гайд — про подбор пары. Он нужен, если вы разворачиваете ассистента с памятью у себя. Если вы просто пользуетесь чатом без архива записей, вторая модель вам не нужна, и половину текста можно пропустить.
#Что понадобится
- Запущенный локальный сервер моделей (для определённости дальше — Ollama) либо ключ облачного провайдера. Модель ассистент не приносит с собой: её подключаете вы. Если это ключ облачного провайдера, текст ваших запросов уходит именно ему; если это локальная Ollama на той же машине, переписка остаётся у вас.
- Понимание своего бюджета видеопамяти. Считается арифметикой, разобранной в статье о том, какую модель выбрать под задачу и железо.
- Ваш реальный архив: заметки, переписка, документы — то, по чему предстоит искать. На пустой базе проверить подбор нельзя.
Отдельно про Persona: векторный поиск здесь — опция, по умолчанию выключенная. Из коробки работает поиск по ключевым словам, и для значительной части запросов — по именам, названиям проектов, точным формулировкам — его достаточно. Векторный и гибридный режимы требуют установленного расширения sqlite-vec, подключённой embed-модели и переиндексации; без них система тихо возвращается к поиску по ключевым словам, ничего не ломая. Это стоит знать до того, как вы начнёте искать причину «плохого поиска» в размере чат-модели.
#Шаг 1. Разведите требования к двум моделям
Первое, что нужно сделать, — перестать выбирать «модель» и начать выбирать две. У них разные критерии, и почти ни один не общий.
| Критерий | Разговорная модель | Embed-модель |
|---|---|---|
| Что делает | Формулирует ответ по данному контексту | Превращает текст в вектор для поиска |
| Что важно | Качество языка, следование инструкции, контекст | Качество на вашем языке, размерность вектора |
| Размер | 7–14 миллиардов параметров типично | Сотни миллионов, на порядки меньше |
| Цена ошибки | Ответ хуже сформулирован | Нужный фрагмент вообще не найден |
| Смена модели | Безболезненна | Требует переиндексации всего архива |
Главный вывод из таблицы — в последней строке. Разговорную модель можно менять хоть каждую неделю: память от неё не зависит. Embed-модель меняется вместе с полной переиндексацией архива, потому что векторы, построенные разными моделями, несравнимы между собой. Поэтому вторую выбирают вдумчиво и один раз, а первую — как удобно.
#Шаг 2. Подберите разговорную модель по контексту, а не по «уму»
У ассистента с памятью к разговорной модели есть специфическое требование, которого нет у обычного чата: в каждый запрос подмешиваются найденные фрагменты вашего архива. Это значит, что контекст расходуется быстрее, чем вы привыкли, и расходуется не вами.
Практические ориентиры:
- Смотрите на реально удерживаемый контекст, а не на цифру в карточке. Модель, заявляющая огромное окно, но теряющая факты из середины, в сценарии с памятью подводит систематически: подмешанный фрагмент попадает как раз в середину. Разрыв между заявленным и полезным разобран в материале про заявленный контекст против полезного.
- Проверьте следование инструкции. Модель должна отвечать по предоставленным фрагментам, а не по своим общим знаниям, и признавать, что в архиве ничего не нашлось. Модель, которая в такой ситуации сочиняет правдоподобное, для памяти опаснее, чем модель, которая просто слабее.
- Не гонитесь за рассуждающим режимом. Скрытая цепочка рассуждений съедает контекст, который вам нужен под фрагменты архива.
#Шаг 3. Подберите embed-модель по языку и размерности
Здесь решают два параметра, и оба не про «ум».
Язык. Большинство embed-моделей обучены преимущественно на английском, и на русском их качество заметно ниже. Публичные таблицы качества эмбеддингов англоцентричны и на русский не переносятся — проверять придётся своими запросами по своему архиву. Выбирайте модель, у которой мультиязычность заявлена явно, и всё равно проверяйте.
Размерность вектора. Она определяет размер индекса напрямую: число фрагментов, умноженное на размерность, умноженное на размер числа (4 байта в обычной точности). Для ста тысяч фрагментов и размерности 768 это порядка 300 МБ только под векторы. Разница между размерностью 384 и 1024 — почти трёхкратная разница в размере индекса и в скорости поиска. Сравнение кандидатов по этим двум критериям собрано в обзоре embed-моделей для поиска по памяти.
Установка embed-модели в локальный сервер выглядит так:
ollama pull nomic-embed-text
ollama list
Вторая команда должна показать модель в списке. Дальше её имя указывается в настройках ассистента как модель эмбеддингов.
#Шаг 4. Проверьте чек-лист совместимости
Прежде чем считать пару подобранной, пройдите семь пунктов. Каждый — реальная причина, по которой связка не работает.
- Обе модели видны серверу и отвечают: разговорная — на пробный запрос, embed — на запрос эмбеддинга.
- Размерность вектора embed-модели совпадает с размерностью, под которую создан индекс. Не совпадает — индекс пересоздаётся, а не «дополняется».
- Длина контекста в настройках рантайма выставлена явно и не меньше, чем нужно под подмешиваемые фрагменты плюс диалог.
- Суммарно в память помещаются обе модели одновременно, если вы не хотите ждать выгрузки и загрузки на каждом запросе.
- Расширение векторного поиска установлено, если вы рассчитываете на векторный режим, а не на поиск по ключевым словам.
- Индекс построен по всему архиву, а не только по записям, добавленным после включения векторного режима.
- Режим поиска выставлен осознанно: ключевые слова, векторы или гибрид. Гибридный режим объединяет оба списка результатов; механика — в разборе гибридного поиска по BM25 и векторам.
Пошаговая настройка связки с локальным сервером описана отдельно — в гайде о том, как подключить Ollama к Persona.
#Проверка результата
Подбор считается удачным, если проходит все три проверки. Делайте их на своём архиве, а не на тестовых данных.
Проверка поиска. Возьмите пять записей, содержание которых вы точно помните, и задайте по ним вопросы своими словами — не теми, что написаны в записи. Все пять должны найтись. Если находятся две-три, проблема в embed-модели или в индексе, и менять разговорную модель бессмысленно.
Проверка ответа. Задайте вопрос, ответ на который в архиве есть, и вопрос, ответа на который там заведомо нет. В первом случае ассистент должен ответить по вашим данным, во втором — сказать, что не нашёл. Уверенная выдумка во втором случае — брак разговорной модели, а не памяти.
Проверка нагрузки. Задайте вопрос, под который подмешается много фрагментов сразу. Ответ должен прийти за приемлемое время и не потерять начало диалога. Если теряет — уменьшайте число подмешиваемых фрагментов, а не меняйте модель.
#Что может пойти не так
Поиск «сломался» после смены embed-модели. Он не сломался: старые векторы построены другой моделью и несравнимы с новыми. Нужна полная переиндексация. Это самая частая ошибка.
Векторный режим включён, но ничего не изменилось. Скорее всего, расширение векторного поиска не установлено и система тихо работает по ключевым словам. Проверьте, что режим действительно активен, а не выбран в настройках.
Ассистент отвечает общими словами вместо ваших данных. Фрагменты не доехали до модели: либо ничего не нашлось, либо контекст обрезан. Смотрите, что реально уходит в запрос, прежде чем менять модель.
Обе модели не помещаются в память. Сервер начинает выгружать одну ради другой, и каждый запрос упирается в загрузку. Уменьшайте разговорную модель — embed-модель на порядки меньше, экономить на ней бессмысленно.
Ключ облачного провайдера в базе. Если вы подключаете не локальную модель, а ключ, помните: ключи участников хранятся в базе в открытом виде. Для домашней машины это приемлемо, для общего сервера — повод завести отдельный ключ с ограниченным лимитом.
#Частые вопросы
#Зачем ассистенту с памятью две модели?
Разговорная модель формулирует ответ, embed-модель отвечает за поиск по вашему архиву: она превращает и записи, и запрос в векторы, чтобы находить близкое по смыслу. Это разные задачи с разными требованиями, и одна модель их не совмещает.
#Можно ли обойтись без embed-модели?
Можно, если поиск работает по ключевым словам. Такой режим находит точные слова, имена и названия и для многих запросов достаточен, но не находит формулировки, отличающиеся по словам и совпадающие по смыслу. В Persona поиск по ключевым словам работает по умолчанию, векторный подключается отдельно.
#Что будет, если сменить embed-модель?
Весь индекс придётся построить заново: векторы разных моделей несравнимы между собой. Пока переиндексация не выполнена, поиск будет находить только те записи, которые проиндексированы новой моделью.
#Какого размера должна быть разговорная модель для памяти?
Ориентир тот же, что и для обычного чата, — по объёму видеопамяти. Специфика в другом: контекст расходуется быстрее, потому что в каждый запрос подмешиваются фрагменты архива. Модель с честным средним контекстом здесь полезнее модели с огромным заявленным и плохим удержанием.
#Куда уходят мои данные при таком сценарии?
Туда, куда вы направили модель. При локальной Ollama на вашей машине переписка и содержимое фрагментов остаются у вас. При ключе облачного провайдера текст запроса вместе с подмешанными фрагментами архива уходит этому провайдеру — это стоит учитывать, потому что в фрагментах может оказаться больше личного, чем в самом вопросе.