Руководство по интеграции
Обновлено: 2026-07-06
*Дисклеймер: Данный материал носит исключительно информационный характер и не является финансовой рекомендацией.*
## Какой метод поиска лучше всего подходит для систем памяти: векторный, графовый или гибридный?
Графовые методы памяти (GraphRAG, Graphiti, HippoRAG) оптимальны для задач с явными связями и "многопрыжковыми" запросами, поскольку они эффективно моделируют отношения и временные контексты. Векторный поиск (например, на BERT-эмбеддингах) прост и быстр, хорошо справляясь с семантическими запросами, но может “туннельно мыслить” на более сложных вопросах. Гибридные схемы (BM25 + dense + ранжирование) объединяют сильные стороны, используя BM25 для точного поиска по ключевым словам и dense-поиск для семантического соответствия, а методы ранжирования, такие как RRF или кросс-энкодеры, повышают полноту результатов. На практике гибридный подход часто обеспечивает наилучший Recall.
| Подход | Преимущества | Ограничения | Примеры/реализации |
|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Векторный поиск | * Высокая скорость и простота (аннотация токенов + ANN)
* Хорош для семантических совпадений | * Склонен пропустить длинные/структурные зависимости, «туннельное зрение» (ловушка близости)
* Требует хороших эмбеддингов | Поиск по эмбеддингам (FAISS, HNSWlib); Dense Retriever; MemGPT, TiM |
| Графовый поиск (GraphRAG) | * Улавливает многопрыжковые связи и онтологии
* Модель памяти ближе к «человеческому» (связные ассоциации) | * Сложность построения и обновления (KG), медленнее обновление
* Требует экстракции сущностей/отношений; может быть тяжеловесен (Neo4j, Faiss) | Graphiti/Zep (динамический KG); HippoRAG (PPR + KG) |
| Гибридный поиск | * Объединяет точность BM25 + семантику dense
* RRF-фьюжн дополнительно повышает полноту результата
* Чаще всего даёт лучший Recall на практике | * Сложнее реализовать (несколько индексов)
* Дополнительный оверхед при ранжировании (кросс-энкодер) | Схемы: BM25 + Dense + RRF/кросс-энкодер |
### Рекомендации по выбору метода поиска
Для локального движка, особенно на Python и с минимальными зависимостями, рекомендуется гибридная схема. Это включает хранение ключевых слов (например, с использованием FTS5 SQLite или Whoosh) и эмбеддингов (с использованием ANN-индексов). Опциональное применение RRF-фьюжна для результатов поиска может значительно повысить их полноту при минимальных затратах. Графовые решения (Neo4j, Graphiti) обеспечивают выигрыш в очень сложных сценариях, но требуют больше зависимостей. Простой GraphRAG без внешнего сервиса можно реализовать, сохраняя связи в SQLite или небольшом RDF-хранилище. В целом, оптимальный баланс Recall и простоты обеспечивает комбинация BM25 и dense-поиска, с опциональным кросс-энкодером для критичных задач.
### Бенчмарки памяти: LoCoMo, LongMemEval, MemBench
Основные датасеты для оценки долгосрочной памяти — LoCoMo (2024) и LongMemEval (2024). LoCoMo разработан для имитации очень длинных диалогов (до 9 тысяч токенов, 300 ходов) с вопросами и суммаризацией, оцениваясь метриками F1 и BLEU. LongMemEval фокусируется на персональной памяти через 5 способностей, используя до 115 тысяч токенов истории и оценивая точность ответа (через GPT-4o) и Recall@K/NDCG. MemBench (2025) представляет собой новую коллекцию сценариев (фактическая и рефлексивная память, «участие» против «наблюдения») с мульти-метриками: точность запоминания, Recall и эффект «ёмкости».
### Сравнение бенчмарков памяти
| Бенчмарк | Год | Задачи | Метрики | Текущие лидеры и результаты |
|--------------|------|------------------------------------------------------------------------------|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| LoCoMo | 2024 | Очень длинные диалоги (9k токенов); QA (однороль, многопрыжковое), суммаризация | F1 / BLEU-1 по ответам; recall retrieval | MemoryOS (Zhang 2025): F1 ≈36.2%, BLEU-1 ≈42.1% (GPT-4o-mini); пред. SOTA ≈29% |
| LongMemEval | 2024 | Chat-ассистент (500 вопросов, ~115k токенов истории); 5 типов умений | Точность ответов (GPT-4 judge), Recall@K, NDCG@K при извлечении | Zep (Graphiti): точность ≈63.8% (GPT-4o-mini); офлайн (GPT-4o) 91.8%, ChatGPT 57.7% |
| MemBench | 2025 | Многоуровневые сценарии: фактическая/рефлексивная память; «участие/наблюдение» | Точность ответа, Recall извлечения, эффективность, ёмкость | Пока нет единого лидера; лучшие механизмы дают до ≈0.7–0.8 accuracy (слабый рост при росте истории) |
### Оценка Recall и точности в системах памяти
Для адекватной оценки систем памяти важно измерять как финальный ответ, так и качество извлечения данных. LoCoMo использует F1/BLEU, а LongMemEval – оценку ответов через GPT-4 и Recall@K/NDCG для промежуточного поиска. MemBench, помимо Accuracy, вводит Recall (долю найденных релевантных фрагментов) и показатель ёмкости. Рекомендуется собирать Recall@K (количество релевантных фрагментов в топ-K) и общую точность ответа. Важно измерять Recall извлечения, потому что это позволяет понять, насколько полно система восстанавливает нужную информацию, независимо от того, насколько хорошо LLM интерпретирует эту информацию в окончательном ответе.
### Лёгкие on-device эмбеддеры
Для локальной работы на CPU критичен компромисс между скоростью и качеством. MiniLM (22М параметров) является самым быстрым (~15 мс на 1000 токенов), но качество ниже (~78% топ-5 Recall на BEIR). BGE-small (33М) чуть медленнее, но предлагает лучшее качество (~80–85% Recall). Nomic Embed (137М) более точен (~86% Recall), но в ~3 раза медленнее (~42 мс на 1k токенов). FastEmbed (ONNX) позволяет запускать BGE-small и MiniLM на CPU без тяжелых зависимостей с высокой производительностью. Оптимальным выбором для локальных продуктов является BGE-small-v1.5 через FastEmbed как баланс качества и скорости.
### Сравнение лёгких эмбеддеров
| Модель | Параметры | Размер | Задержка кодирования (CPU) | Примерная точность (топ-5 Recall) | Замечания |
|-------------------------|-----------|--------|----------------------------|-----------------------------------|-----------------------------------------------------------------------------|
| MiniLM-L6-v2 | 22M | ~90MB | ~14.7 мс на 1000 токенов | ~78.1% | Очень быстрая, малый размер; качество уступает крупным |
| BAAI/bge-small-en-v1.5 (через FastEmbed) | 33M | 133MB | ≈15–20 мс на 1000 т. (ONNX) | ~80–85% (между MiniLM и E5) | Хороший баланс; FastEmbed использует ONNX и оптимизации |
| nomic-embed-text-v1.5 | 137M | 274MB | ~41.9 мс на 1000 т. | ~86.2% | Высокое качество, но медленный на CPU |
| E5-Base-v2 / Mid-size | 220M | 818MB | ~20–22 мс на 1000 т. | ~83–84% | Хорошая альтернатива, но развернута (не «легкая» модель) |
| FastEmbed (ONNX) | – | – | Зависит от базовой модели (использует ONNX) | – | Лёгкая обёртка; дефолт BGE-small; нет тяжёлых PyTorch-зависимостей |
### Рекомендации по выбору on-device эмбеддера
Для локальных (edge) приложений наилучшим выбором является `BAAI/bge-small-en-v1.5` через FastEmbed (Apache-2.0). Эта модель обладает хорошим балансом легкости (33M параметров) и производительности на CPU, без существенной потери качества по сравнению с более крупными моделями. MiniLM-L6-v2 подходит, если скорость является критическим приоритетом из-за очень ограниченных ресурсов. Если качество имеет решающее значение и доступны дополнительные ресурсы, Nomic Embed v1.5 может быть использован, но его производительность на CPU будет заметно ниже.
### ANN-индексы для SQLite
Интеграция ANN-индексов в SQLite возможна через расширения, такие как `sqlite-vss`, `sqlite-vec` или внешние библиотеки, например, HNSWlib и Faiss. `sqlite-vss` (на базе Faiss) предоставляет поиск в виде расширения СУБД, но его развитие замедлилось. `sqlite-vec` – это новое C-расширение, которое легко устанавливается (через pip) и поддерживает различные алгоритмы (IVF, DiskANN), обеспечивая масштабируемость до миллионов векторов. HNSWlib (Apache-2.0) – быстрая библиотека для графов HNSW, очень эффективна для больших объемов (до 10^7–10^8 векторов), но требует отдельного хранения индекса. Faiss (MIT) – самая производительная библиотека с поддержкой GPU/CPU, но она тяжеловесна и требует больших объемов RAM. Для "одного файла" SQLite-решения, `sqlite-vec` является предпочтительным, поскольку хранит данные внутри базы данных, в отличие от HNSWlib и Faiss, которые требуют внешнего управления индексами.
### Сравнение ANN-индексов для SQLite
| Решение | Интеграция | Лицензия | Плюсы | Минусы |
|----------------|-----------------------------------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| sqlite-vss | SQLite-расширение (Faiss) | MIT | * Прямо внутри SQLite; использует проверенный Faiss
* Поддерживает различные индексы (Flat, IVF) | * Сложно собирать/устанавливать (C++, Faiss)
* Не активно развивается, нет обновлений |
| sqlite-vec | SQLite-расширение (C) | Apache-2.0 + MIT | * Лёгкая установка (pip); чистый C (кроссплатформенность)
* Поддержка HNSW, IVF, DiskANN, квантизации
* Простое хранение (внешний вид обычных таблиц) | * Индексирование (DiskANN) может быть медленным на больших данных
* Пока предверсия (меняются возможности) |
| hnswlib | Библиотека (Python/C++) | Apache-2.0 | * Очень быстрый поиск (HNSW граф); простая интеграция Python
* Поддержка update/delete, многопоток; масштабные индексы (миллионы) | * Хранение вне SQLite (отдельный файл/память)
* Зависимость от C++; на больших GPU не использует (только CPU) |
| Faiss | Библиотека (C++/Python) | MIT | * Высокая производительность; GPU-ускорение
* Поддержка многих методов (IVF, HNSW, OPQ) | * Тяжёлая сборка, большие бинарники
* Тоже хранится вне SQLite; больший overhead (сильная память) |
### Рекомендации по ANN-индексам для SQLite
Для локальной системы на Python оптимальным решением являются SQLite-расширения. `sqlite-vec` – отличный выбор: он имеет лицензию Apache/MIT, легко устанавливается через pip, полностью написан на C и сохраняет все данные в одном файле, поддерживая различные ANN-алгоритмы. Это позволяет хранить до миллионов векторов и использовать HNSW или IVF без внешних сервисов. Если требуется максимальная скорость для десятков миллионов векторов, можно рассмотреть HNSWlib или Faiss (MIT), но в этом случае индексы будут храниться вне SQLite.
### Реранкинг и гибридный скоринг
Реранкинг улучшает точность ответов, но увеличивает время задержки. RRF (Reciprocal Rank Fusion) – это простой способ объединения кандидатов (например, от BM25 и dense-поиска), который повышает полноту (recall) с незначительными затратами. Кросс-энкодеры делают ранжирование более точным, совместно оценивая запрос и документ, но на CPU это может быть медленно (~60–100 мс для 20 пар). На GPU кросс-энкодеры работают значительно быстрее (в 10–15 раз). Практические обзоры показывают, что кросс-энкодеры добавляют задержку около 100–150 мс на CPU, в то время как RRF почти бесплатен и эффективно объединяет результаты. В контексте персональной памяти увеличение выигрыша от кросс-энкодеров часто незначительно, и простое смешение BM25 и dense-поиска оказывается достаточным.
### Сравнение методов реранкинга и гибридного скоринга
| Метод | Улучшение Recall/качества | Стоимость (латентность) | Особенности |
|-----------------------|------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RRF (ранж. фьюжн) | Небольшое повышение релевантности за счёт объединения списков | ≈0 (не требует инференсов моделей) | Простая схема, не требует обучения; хорошо работает при сильно отличающихся списках (sparse vs dense) |
| Cross-Encoder | Существенное улучшение финального ранжирования и точности ответа | Высокая: +60–100 мс (20 пар) на CPU (или 10–15× меньше на GPU) | Очень точный (учитывает связь query-doc), но тяжелый; на CPU лучше брать маленькие модели (miniLM) |
| Bi-Encoder (начальный поиск) | Основной поиск (семантический). Нужен как база перед ранжированием. | Быстрый (обычно <10 мс на 1 запрос) | Векторный/лексический поиск (NCCL, Faiss, SQLite) |
### Рекомендации по реранкингу для локальных систем
Для систем персональной памяти реранкинг даёт ограниченный прирост качества. RRF-фьюжн следует применять всегда, так как он обеспечивает дешёвое объединение результатов sparse и dense-поиска. Кросс-энкодеры лучше использовать только в крайних случаях, когда критически важна точность ответа, особенно при наличии GPU (что даёт ускорение в 10–15 раз). На CPU же экономичнее обойтись без них, чтобы избежать увеличения задержки (до 100–150 мс для 20 кандидатов). Для локальных продуктов рекомендуется сосредоточиться на качественном initial retrieval (BM25 + HNSW) и опциональном RRF. Если ресурсы позволяют, можно добавить лёгкий кросс-энкодер (например, ms-marco-MiniLM-L6-v2) только для финальной пары «ответ-вопрос».
*Дисклеймер: Данный материал носит исключительно информационный характер и не является финансовой рекомендацией.*
## Какой метод поиска лучше всего подходит для систем памяти: векторный, графовый или гибридный?
Графовые методы памяти (GraphRAG, Graphiti, HippoRAG) оптимальны для задач с явными связями и "многопрыжковыми" запросами, поскольку они эффективно моделируют отношения и временные контексты. Векторный поиск (например, на BERT-эмбеддингах) прост и быстр, хорошо справляясь с семантическими запросами, но может “туннельно мыслить” на более сложных вопросах. Гибридные схемы (BM25 + dense + ранжирование) объединяют сильные стороны, используя BM25 для точного поиска по ключевым словам и dense-поиск для семантического соответствия, а методы ранжирования, такие как RRF или кросс-энкодеры, повышают полноту результатов. На практике гибридный подход часто обеспечивает наилучший Recall.
| Подход | Преимущества | Ограничения | Примеры/реализации |
|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Векторный поиск | * Высокая скорость и простота (аннотация токенов + ANN)
* Хорош для семантических совпадений | * Склонен пропустить длинные/структурные зависимости, «туннельное зрение» (ловушка близости)
* Требует хороших эмбеддингов | Поиск по эмбеддингам (FAISS, HNSWlib); Dense Retriever; MemGPT, TiM |
| Графовый поиск (GraphRAG) | * Улавливает многопрыжковые связи и онтологии
* Модель памяти ближе к «человеческому» (связные ассоциации) | * Сложность построения и обновления (KG), медленнее обновление
* Требует экстракции сущностей/отношений; может быть тяжеловесен (Neo4j, Faiss) | Graphiti/Zep (динамический KG); HippoRAG (PPR + KG) |
| Гибридный поиск | * Объединяет точность BM25 + семантику dense
* RRF-фьюжн дополнительно повышает полноту результата
* Чаще всего даёт лучший Recall на практике | * Сложнее реализовать (несколько индексов)
* Дополнительный оверхед при ранжировании (кросс-энкодер) | Схемы: BM25 + Dense + RRF/кросс-энкодер |
### Рекомендации по выбору метода поиска
Для локального движка, особенно на Python и с минимальными зависимостями, рекомендуется гибридная схема. Это включает хранение ключевых слов (например, с использованием FTS5 SQLite или Whoosh) и эмбеддингов (с использованием ANN-индексов). Опциональное применение RRF-фьюжна для результатов поиска может значительно повысить их полноту при минимальных затратах. Графовые решения (Neo4j, Graphiti) обеспечивают выигрыш в очень сложных сценариях, но требуют больше зависимостей. Простой GraphRAG без внешнего сервиса можно реализовать, сохраняя связи в SQLite или небольшом RDF-хранилище. В целом, оптимальный баланс Recall и простоты обеспечивает комбинация BM25 и dense-поиска, с опциональным кросс-энкодером для критичных задач.
### Бенчмарки памяти: LoCoMo, LongMemEval, MemBench
Основные датасеты для оценки долгосрочной памяти — LoCoMo (2024) и LongMemEval (2024). LoCoMo разработан для имитации очень длинных диалогов (до 9 тысяч токенов, 300 ходов) с вопросами и суммаризацией, оцениваясь метриками F1 и BLEU. LongMemEval фокусируется на персональной памяти через 5 способностей, используя до 115 тысяч токенов истории и оценивая точность ответа (через GPT-4o) и Recall@K/NDCG. MemBench (2025) представляет собой новую коллекцию сценариев (фактическая и рефлексивная память, «участие» против «наблюдения») с мульти-метриками: точность запоминания, Recall и эффект «ёмкости».
### Сравнение бенчмарков памяти
| Бенчмарк | Год | Задачи | Метрики | Текущие лидеры и результаты |
|--------------|------|------------------------------------------------------------------------------|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| LoCoMo | 2024 | Очень длинные диалоги (9k токенов); QA (однороль, многопрыжковое), суммаризация | F1 / BLEU-1 по ответам; recall retrieval | MemoryOS (Zhang 2025): F1 ≈36.2%, BLEU-1 ≈42.1% (GPT-4o-mini); пред. SOTA ≈29% |
| LongMemEval | 2024 | Chat-ассистент (500 вопросов, ~115k токенов истории); 5 типов умений | Точность ответов (GPT-4 judge), Recall@K, NDCG@K при извлечении | Zep (Graphiti): точность ≈63.8% (GPT-4o-mini); офлайн (GPT-4o) 91.8%, ChatGPT 57.7% |
| MemBench | 2025 | Многоуровневые сценарии: фактическая/рефлексивная память; «участие/наблюдение» | Точность ответа, Recall извлечения, эффективность, ёмкость | Пока нет единого лидера; лучшие механизмы дают до ≈0.7–0.8 accuracy (слабый рост при росте истории) |
### Оценка Recall и точности в системах памяти
Для адекватной оценки систем памяти важно измерять как финальный ответ, так и качество извлечения данных. LoCoMo использует F1/BLEU, а LongMemEval – оценку ответов через GPT-4 и Recall@K/NDCG для промежуточного поиска. MemBench, помимо Accuracy, вводит Recall (долю найденных релевантных фрагментов) и показатель ёмкости. Рекомендуется собирать Recall@K (количество релевантных фрагментов в топ-K) и общую точность ответа. Важно измерять Recall извлечения, потому что это позволяет понять, насколько полно система восстанавливает нужную информацию, независимо от того, насколько хорошо LLM интерпретирует эту информацию в окончательном ответе.
### Лёгкие on-device эмбеддеры
Для локальной работы на CPU критичен компромисс между скоростью и качеством. MiniLM (22М параметров) является самым быстрым (~15 мс на 1000 токенов), но качество ниже (~78% топ-5 Recall на BEIR). BGE-small (33М) чуть медленнее, но предлагает лучшее качество (~80–85% Recall). Nomic Embed (137М) более точен (~86% Recall), но в ~3 раза медленнее (~42 мс на 1k токенов). FastEmbed (ONNX) позволяет запускать BGE-small и MiniLM на CPU без тяжелых зависимостей с высокой производительностью. Оптимальным выбором для локальных продуктов является BGE-small-v1.5 через FastEmbed как баланс качества и скорости.
### Сравнение лёгких эмбеддеров
| Модель | Параметры | Размер | Задержка кодирования (CPU) | Примерная точность (топ-5 Recall) | Замечания |
|-------------------------|-----------|--------|----------------------------|-----------------------------------|-----------------------------------------------------------------------------|
| MiniLM-L6-v2 | 22M | ~90MB | ~14.7 мс на 1000 токенов | ~78.1% | Очень быстрая, малый размер; качество уступает крупным |
| BAAI/bge-small-en-v1.5 (через FastEmbed) | 33M | 133MB | ≈15–20 мс на 1000 т. (ONNX) | ~80–85% (между MiniLM и E5) | Хороший баланс; FastEmbed использует ONNX и оптимизации |
| nomic-embed-text-v1.5 | 137M | 274MB | ~41.9 мс на 1000 т. | ~86.2% | Высокое качество, но медленный на CPU |
| E5-Base-v2 / Mid-size | 220M | 818MB | ~20–22 мс на 1000 т. | ~83–84% | Хорошая альтернатива, но развернута (не «легкая» модель) |
| FastEmbed (ONNX) | – | – | Зависит от базовой модели (использует ONNX) | – | Лёгкая обёртка; дефолт BGE-small; нет тяжёлых PyTorch-зависимостей |
### Рекомендации по выбору on-device эмбеддера
Для локальных (edge) приложений наилучшим выбором является `BAAI/bge-small-en-v1.5` через FastEmbed (Apache-2.0). Эта модель обладает хорошим балансом легкости (33M параметров) и производительности на CPU, без существенной потери качества по сравнению с более крупными моделями. MiniLM-L6-v2 подходит, если скорость является критическим приоритетом из-за очень ограниченных ресурсов. Если качество имеет решающее значение и доступны дополнительные ресурсы, Nomic Embed v1.5 может быть использован, но его производительность на CPU будет заметно ниже.
### ANN-индексы для SQLite
Интеграция ANN-индексов в SQLite возможна через расширения, такие как `sqlite-vss`, `sqlite-vec` или внешние библиотеки, например, HNSWlib и Faiss. `sqlite-vss` (на базе Faiss) предоставляет поиск в виде расширения СУБД, но его развитие замедлилось. `sqlite-vec` – это новое C-расширение, которое легко устанавливается (через pip) и поддерживает различные алгоритмы (IVF, DiskANN), обеспечивая масштабируемость до миллионов векторов. HNSWlib (Apache-2.0) – быстрая библиотека для графов HNSW, очень эффективна для больших объемов (до 10^7–10^8 векторов), но требует отдельного хранения индекса. Faiss (MIT) – самая производительная библиотека с поддержкой GPU/CPU, но она тяжеловесна и требует больших объемов RAM. Для "одного файла" SQLite-решения, `sqlite-vec` является предпочтительным, поскольку хранит данные внутри базы данных, в отличие от HNSWlib и Faiss, которые требуют внешнего управления индексами.
### Сравнение ANN-индексов для SQLite
| Решение | Интеграция | Лицензия | Плюсы | Минусы |
|----------------|-----------------------------------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| sqlite-vss | SQLite-расширение (Faiss) | MIT | * Прямо внутри SQLite; использует проверенный Faiss
* Поддерживает различные индексы (Flat, IVF) | * Сложно собирать/устанавливать (C++, Faiss)
* Не активно развивается, нет обновлений |
| sqlite-vec | SQLite-расширение (C) | Apache-2.0 + MIT | * Лёгкая установка (pip); чистый C (кроссплатформенность)
* Поддержка HNSW, IVF, DiskANN, квантизации
* Простое хранение (внешний вид обычных таблиц) | * Индексирование (DiskANN) может быть медленным на больших данных
* Пока предверсия (меняются возможности) |
| hnswlib | Библиотека (Python/C++) | Apache-2.0 | * Очень быстрый поиск (HNSW граф); простая интеграция Python
* Поддержка update/delete, многопоток; масштабные индексы (миллионы) | * Хранение вне SQLite (отдельный файл/память)
* Зависимость от C++; на больших GPU не использует (только CPU) |
| Faiss | Библиотека (C++/Python) | MIT | * Высокая производительность; GPU-ускорение
* Поддержка многих методов (IVF, HNSW, OPQ) | * Тяжёлая сборка, большие бинарники
* Тоже хранится вне SQLite; больший overhead (сильная память) |
### Рекомендации по ANN-индексам для SQLite
Для локальной системы на Python оптимальным решением являются SQLite-расширения. `sqlite-vec` – отличный выбор: он имеет лицензию Apache/MIT, легко устанавливается через pip, полностью написан на C и сохраняет все данные в одном файле, поддерживая различные ANN-алгоритмы. Это позволяет хранить до миллионов векторов и использовать HNSW или IVF без внешних сервисов. Если требуется максимальная скорость для десятков миллионов векторов, можно рассмотреть HNSWlib или Faiss (MIT), но в этом случае индексы будут храниться вне SQLite.
### Реранкинг и гибридный скоринг
Реранкинг улучшает точность ответов, но увеличивает время задержки. RRF (Reciprocal Rank Fusion) – это простой способ объединения кандидатов (например, от BM25 и dense-поиска), который повышает полноту (recall) с незначительными затратами. Кросс-энкодеры делают ранжирование более точным, совместно оценивая запрос и документ, но на CPU это может быть медленно (~60–100 мс для 20 пар). На GPU кросс-энкодеры работают значительно быстрее (в 10–15 раз). Практические обзоры показывают, что кросс-энкодеры добавляют задержку около 100–150 мс на CPU, в то время как RRF почти бесплатен и эффективно объединяет результаты. В контексте персональной памяти увеличение выигрыша от кросс-энкодеров часто незначительно, и простое смешение BM25 и dense-поиска оказывается достаточным.
### Сравнение методов реранкинга и гибридного скоринга
| Метод | Улучшение Recall/качества | Стоимость (латентность) | Особенности |
|-----------------------|------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RRF (ранж. фьюжн) | Небольшое повышение релевантности за счёт объединения списков | ≈0 (не требует инференсов моделей) | Простая схема, не требует обучения; хорошо работает при сильно отличающихся списках (sparse vs dense) |
| Cross-Encoder | Существенное улучшение финального ранжирования и точности ответа | Высокая: +60–100 мс (20 пар) на CPU (или 10–15× меньше на GPU) | Очень точный (учитывает связь query-doc), но тяжелый; на CPU лучше брать маленькие модели (miniLM) |
| Bi-Encoder (начальный поиск) | Основной поиск (семантический). Нужен как база перед ранжированием. | Быстрый (обычно <10 мс на 1 запрос) | Векторный/лексический поиск (NCCL, Faiss, SQLite) |
### Рекомендации по реранкингу для локальных систем
Для систем персональной памяти реранкинг даёт ограниченный прирост качества. RRF-фьюжн следует применять всегда, так как он обеспечивает дешёвое объединение результатов sparse и dense-поиска. Кросс-энкодеры лучше использовать только в крайних случаях, когда критически важна точность ответа, особенно при наличии GPU (что даёт ускорение в 10–15 раз). На CPU же экономичнее обойтись без них, чтобы избежать увеличения задержки (до 100–150 мс для 20 кандидатов). Для локальных продуктов рекомендуется сосредоточиться на качественном initial retrieval (BM25 + HNSW) и опциональном RRF. Если ресурсы позволяют, можно добавить лёгкий кросс-энкодер (например, ms-marco-MiniLM-L6-v2) только для финальной пары «ответ-вопрос».