Персональная база знаний на 106K векторов за 256ms: nomic-embed-text + LanceDB на Mac M4

Почему 256 миллисекунд — это много, и почему это мало

Представьте: у вас 106 тысяч документов — заметки, статьи, PDF, переписки. Вы хотите найти все про "миграцию базы данных в продакшене". Не по ключевым словам, а по смыслу. Классический поиск по ключевым словам пропустит документ, где написано "перенос БД на боевой сервер". Семантический поиск поймет, что это одно и то же.

Проблема в скорости. Большинство решений либо медленные (сотни миллисекунд на десятках тысяч векторов), либо требуют GPU, либо жрут память как не в себя. Особенно на Mac — где нет CUDA, а Metal иногда ведет себя как капризный подросток.

Я перебрал варианты:

• ChromaDB — удобно, но медленно на больших объемах
• Pinecone — платно и в облаке (мой код никуда не поедет)
• Weaviate — монстр, который хочет всю память
• Qdrant — быстрый, но требует отдельного сервера
• DuckDB с VSS — многообещающе, пока не упрешься в ограничения

Решение: nomic-embed-text + LanceDB = скорость без компромиссов

После недель тестов и разочарований я остановился на этой связке. Вот почему:

Ключевой момент: LanceDB хранит векторы в формате, оптимизированном для поиска. Не просто массив чисел в SQL-столбце, а специальные структуры данных с IVF индексами.

Миграция с DuckDB VSS: боль, которую стоило пережить

Сначала я использовал DuckDB с расширением VSS. Работало, но было три проблемы:

1. Индексы занимали в 3-4 раза больше места, чем данные
2. Поиск по 50K векторов занимал 800-900ms
3. При добавлении новых данных нужно было перестраивать индекс

LanceDB решает все три проблемы. Индекс строится один раз и обновляется инкрементально. Размер на диске — примерно 1.5x от размера сырых векторов. И самое главное — скорость.

Пошаговый план: от нуля до 106K векторов

1 Установка и настройка окружения

Сначала ставим зависимости. Важный момент: для Mac M1/M2/M3/M4 нужно установить PyTorch с поддержкой Metal Performance Shaders.

# Создаем виртуальное окружение
python -m venv .venv
source .venv/bin/activate

# Устанавливаем PyTorch для Apple Silicon
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu

# Основные зависимости
pip install lancedb sentence-transformers duckdb

# Для nomic-embed-text
pip install nomic

Проверяем, что Metal работает:

import torch
print(torch.backends.mps.is_available())  # Должно быть True
print(torch.backends.mps.is_built())      # Должно быть True

2 Подготовка данных и создание эмбеддингов

Допустим, у вас есть папка с документами. Вот как их обработать:

import os
from pathlib import Path
import lancedb
from nomic import embed
import duckdb
from datetime import datetime

class KnowledgeBase:
    def __init__(self, db_path="knowledge_base.lancedb"):
        self.db = lancedb.connect(db_path)
        self.duckdb_con = duckdb.connect(":memory:")
        
    def create_embeddings(self, texts):
        """Создаем эмбеддинги через nomic-embed-text"""
        # Используем CPU, потому что на MPS бывают проблемы
        # с batch inference в nomic
        output = embed.text(
            texts=texts,
            model='nomic-embed-text-v1.5',
            task_type='search_document',
            dimensionality=768
        )
        return output['embeddings']
    
    def process_documents(self, documents_folder):
        """Обрабатываем все документы в папке"""
        all_texts = []
        metadata = []
        
        for file_path in Path(documents_folder).glob("**/*.txt"):
            with open(file_path, 'r', encoding='utf-8') as f:
                text = f.read()
                
            # Разбиваем на чанки по 500 токенов (примерно 2000 символов)
            chunks = self._split_into_chunks(text, 2000)
            
            for i, chunk in enumerate(chunks):
                all_texts.append(chunk)
                metadata.append({
                    'file_path': str(file_path),
                    'chunk_index': i,
                    'file_size': os.path.getsize(file_path),
                    'processed_at': datetime.now().isoformat()
                })
        
        return all_texts, metadata
    
    def _split_into_chunks(self, text, chunk_size):
        """Простое разбиение текста на чанки"""
        chunks = []
        for i in range(0, len(text), chunk_size):
            chunks.append(text[i:i+chunk_size])
        return chunks

3 Создание и индексация таблицы в LanceDB

Вот где начинается магия:

    def create_table(self, table_name="documents"):
        """Создаем таблицу с векторами и метаданными"""
        # Проверяем, существует ли таблица
        if table_name in self.db.table_names():
            print(f"Таблица {table_name} уже существует")
            return self.db.open_table(table_name)
        
        # Создаем схему таблицы
        schema = lancedb.schema([
            lancedb.field("vector", lancedb.vector(768)),
            lancedb.field("text", lancedb.string()),
            lancedb.field("file_path", lancedb.string()),
            lancedb.field("chunk_index", lancedb.int32()),
            lancedb.field("file_size", lancedb.int64()),
            lancedb.field("processed_at", lancedb.string())
        ])
        
        # Создаем пустую таблицу
        table = self.db.create_table(table_name, schema=schema)
        
        # Создаем IVF_PQ индекс для ускорения поиска
        # num_partitions=256 - оптимально для 100K+ векторов
        # num_sub_vectors=96 - компромисс между точностью и скоростью
        table.create_index(
            num_partitions=256,
            num_sub_vectors=96,
            index_type="IVF_PQ",
            metric="cosine"
        )
        
        return table

4 Заполнение базы и поиск

Теперь заполняем базу данными:

    def populate_database(self, documents_folder):
        """Основной пайплайн заполнения базы"""
        # 1. Читаем документы
        texts, metadata = self.process_documents(documents_folder)
        print(f"Найдено {len(texts)} чанков")
        
        # 2. Создаем эмбеддинги батчами по 32
        # чтобы не перегружать память
        all_embeddings = []
        batch_size = 32
        
        for i in range(0, len(texts), batch_size):
            batch = texts[i:i+batch_size]
            embeddings = self.create_embeddings(batch)
            all_embeddings.extend(embeddings)
            print(f"Обработано {min(i+batch_size, len(texts))}/{len(texts)}")
        
        # 3. Подготавливаем данные для LanceDB
        data = []
        for idx, (text, meta, emb) in enumerate(zip(texts, metadata, all_embeddings)):
            data.append({
                "vector": emb,
                "text": text,
                "file_path": meta['file_path'],
                "chunk_index": meta['chunk_index'],
                "file_size": meta['file_size'],
                "processed_at": meta['processed_at']
            })
        
        # 4. Записываем в таблицу
        table = self.create_table()
        table.add(data)
        
        return len(texts)
    
    def search(self, query, limit=10, filters=None):
        """Семантический поиск по базе"""
        # Создаем эмбеддинг для запроса
        query_embedding = self.create_embeddings([query])[0]
        
        # Выполняем поиск
        table = self.db.open_table("documents")
        
        # Базовый поиск
        results = table.search(query_embedding).limit(limit).to_list()
        
        # Если нужны фильтры
        if filters:
            filtered_results = []
            for result in results:
                if self._apply_filters(result, filters):
                    filtered_results.append(result)
            results = filtered_results
        
        return results
    
    def _apply_filters(self, result, filters):
        """Применяем фильтры к результатам"""
        for key, value in filters.items():
            if key in result:
                if isinstance(value, list):
                    if result[key] not in value:
                        return False
                elif result[key] != value:
                    return False
        return True

Метрики производительности: холодные цифры

Я тестировал на MacBook Pro M4 с 16GB RAM. Вот результаты:

256 миллисекунд — это с учетом:

• Создания эмбеддинга для запроса (45ms)
• Поиска по индексу (180ms)
• Формирования результатов (31ms)

Для сравнения: тот же поиск в DuckDB VSS занимал 800-900ms. В ChromaDB — около 1200ms. В PostgreSQL с pgvector — больше 2000ms.

Оптимизации, которые реально работают

Размерность имеет значение

Nomic-embed-text позволяет уменьшать размерность эмбеддингов. По умолчанию 768, но можно уменьшить до 512 или даже 256:

output = embed.text(
    texts=["Пример текста"],
    model='nomic-embed-text-v1.5',
    task_type='search_document',
    dimensionality=256  # В 3 раза меньше!
)

Это экономит память и ускоряет поиск, но снижает точность примерно на 3-5%. Для персональной базы знаний — приемлемо.

Правильные индексы в LanceDB

Ключевые параметры при создании индекса:

table.create_index(
    num_partitions=256,      # Больше разделов = быстрее поиск, но больше памяти
    num_sub_vectors=96,      # Больше = точнее, но медленнее
    index_type="IVF_PQ",     # Product Quantization для сжатия
    metric="cosine"          # Косинусное расстояние для текстов
)

Для 100K векторов 256 разделов — оптимально. Для 1M векторов нужно 1024 раздела.

Батчинг при создании эмбеддингов

Не создавайте эмбеддинги по одному. Батчи по 32-64 дают 2-3x ускорение:

# ПЛОХО: 106000 отдельных вызовов
for text in texts:
    embedding = create_embedding([text])

# ХОРОШО: ~3313 батчей по 32
text_batches = [texts[i:i+32] for i in range(0, len(texts), 32)]
for batch in text_batches:
    embeddings = create_embedding(batch)

Интеграция с DuckDB для сложных фильтров

LanceDB отлично ищет векторы, но для сложных SQL-запросов по метаданным лучше использовать DuckDB:

def hybrid_search(query, date_filter=None, file_types=None):
    # 1. Семантический поиск в LanceDB
    vector_results = kb.search(query, limit=50)
    
    # 2. Загружаем результаты в DuckDB для фильтрации
    kb.duckdb_con.execute("""
        CREATE TEMP TABLE search_results AS
        SELECT * FROM (
            VALUES 
                (?, ?, ?, ?),
                ...
        ) t(id, file_path, chunk_index, score)
    """, params)
    
    # 3. Применяем сложные SQL-фильтры
    if date_filter:
        kb.duckdb_con.execute("""
            DELETE FROM search_results 
            WHERE file_path IN (
                SELECT file_path FROM documents_metadata 
                WHERE created_at < ?
            )
        """, [date_filter])
    
    # 4. Возвращаем финальные результаты
    final_results = kb.duckdb_con.execute("""
        SELECT * FROM search_results 
        ORDER BY score DESC 
        LIMIT 10
    """).fetchall()
    
    return final_results

Это дает лучшее из двух миров: скорость векторного поиска и гибкость SQL.

Ошибки, которые совершают все

Что делать, когда 106K векторов станет мало

Мой стек масштабируется до 1-2 миллионов векторов без проблем. Дальше нужно думать о:

1. Шардировании: Разделить базу по темам или типам документов
2. Иерархическом поиске: Сначала искать в категории, потом в ней
3. Уменьшении размерности: С 768 до 256 измерений
4. Квантовании: Хранить векторы в int8 вместо float32

Для квантования в LanceDB есть встроенная поддержка:

table.create_index(
    num_partitions=1024,
    num_sub_vectors=64,
    index_type="IVF_PQ",
    metric="cosine",
    pq_codebook="int8"  # Квантование в 8 бит
)

Это экономит 75% памяти ценой небольшой потери точности (1-2%).

Сравнение с другими решениями

Почему не ChromaDB? Она удобнее для старта, но на 100K+ векторов начинает тормозить. К тому же LanceDB использует Apache Arrow, что дает лучшую интеграцию с экосистемой данных.

Почему не Pinecone? Потому что это облако. Ваши данные уходят на чужие серверы. Месяц бесплатно, потом платно. И латентность сети добавляет свои 50-100ms.

Почему не pgvector? PostgreSQL — отличная СУБД, но не оптимизирована для векторного поиска. Даже с индексами HNSW она медленнее LanceDB в 3-5 раз.

Если вам нужен GUI для отладки векторных запросов, посмотрите VectorDBZ. Инструмент показывает, что происходит внутри векторной БД.

Интеграция с LLM для RAG

Собственно, ради этого все и затевалось. Вот минимальный RAG-пайплайн:

def rag_query(query, llm_client):
    # 1. Семантический поиск
    search_results = kb.search(query, limit=5)
    
    # 2. Формируем контекст
    context = "\n\n".join([r['text'] for r in search_results])
    
    # 3. Промпт с контекстом
    prompt = f"""Используй следующий контекст для ответа на вопрос:
    
    Контекст:
    {context}
    
    Вопрос: {query}
    
    Ответ:"""
    
    # 4. Запрос к LLM (например, через Ollama)
    response = llm_client.generate(prompt)
    
    return {
        'answer': response,
        'sources': [r['file_path'] for r in search_results]
    }

Если вы работаете с мультимодальными данными (документы с картинками и таблицами), вам пригодится мультимодальный RAG с Llama Nemotron.

Производительность на разных железах

Я тестировал на трех конфигурациях:

Вывод: Apple Silicon отлично справляется. M4 особенно хорош благодаря улучшенному Neural Engine.

Что дальше?

106K векторов — только начало. Следующие шаги:

• Добавить инкрементальное обновление (новые документы без перестроения всего индекса)
• Реализовать гибридный поиск (векторный + полнотекстовый)
• Добавить кластеризацию документов для автоматической категоризации
• Экспорт в EdgeVec для поиска прямо в браузере

Самое главное — эта система работает здесь и сейчас. Не нужно ждать, пока Nvidia выпустит новые GPU или пока Pinecone сделает бесплатный тариф побольше. Установили, настроили, пользуетесь.

И последнее: не зацикливайтесь на точности. 99% точности поиска против 95% — разница, которую заметит только бенчмарк. Для персональной базы знаний важно, чтобы система была быстрой и всегда под рукой. А 256ms на 106K векторов — это как раз про скорость.