Weaviate — векторная база данных с модулями для RAG и гибридного поиска

Где Weaviate уместен в стеке ИИ

• RAG (retrieval-augmented generation): хранение эмбеддингов чанков и быстрый top-k отбор релевантов для LLM.
• Семантический поиск: по базам знаний, тикетам, логам, каталогу товаров, коду.
• Индивидуальная «память» ассистентов: векторные заметки с фильтрами по времени/тегам/пользователям.
• Антидубли/кластеризация: поиск похожих объектов (описания, изображения через мультимодальные эмбеддинги).

Ключевая ценность — гибкость и контроль: можно развернуть on-prem, в облаке команды или использовать управляемый сервис.

Базовые понятия и модель данных

• Коллекция (класс) — логическая таблица объектов. У каждого объекта есть схема: набор свойств (атрибутов) и один или несколько векторных представлений.
• Объект — запись с id, набором свойств и вектором(ами).
• Вектор(ы) — эмбеддинги от выбранной модели. Возможны несколько векторных пространств для одной коллекции.
• Метаданные/фильтры — ключ-значение поля со строгими типами для отбора кандидатов до сравнения векторов.
• Модули — плагины для получения эмбеддингов, гибридного sparse-сигнала, переранжирования (reranker), Q&A и др.

Поисковые режимы: dense, sparse и гибрид

• Dense (векторный) поиск — классический ANN по косинусу/евклиду/другим метрикам; хорош, когда значение несут смысловые связи.
• Sparse (ключевые слова) — разрежённые векторы/лексические признаки; полезны для терминов, артикулов, имён собственных.
• Гибридный dense+sparse — объединение семантики и точных терминов. В проде часто даёт лучший Recall@k и NDCG на смешанных корпусах.

Рекомендация: при наличии терминов/артикулов, технических обозначений включайте гибрид; в чистых текстовых знаниях достаточно dense + переранжирование.

Паттерн RAG с Weaviate

1. Подготовка корпуса: чистка, дедуп, чанкинг (обычно 400–1200 токенов, перекрытие 50–150), метаданные (источник, дата, язык, права).
2. Эмбеддинги: выберите модель (моно/мультиязычную), нормализуйте векторы при необходимости.
3. Запись: upsert объектов в коллекцию: vector + properties.
4. Запрос: эмбеддинг запроса → top-k поиск с фильтрами по метаданным.
5. Переранжирование: кросс-энкодер/ранжировщик на 20–200 кандидатах → 5–10 лучших чанков.
6. Генерация: подайте чанки в LLM, требуйте цитирования источников и проверяйте faithfulness (см. Evals).
7. Эксплуатация: мониторинг латентности/качества, инкрементальные обновления, кэш top-k для частых запросов.

Метаданные и фильтры: «срезаем воду» ещё до ANN

• Фильтруйте по разделу/языку/дате/типу до векторного сравнения — это экономит миллисекунды и токены в контексте (см. FinOps).
• Нормализуйте значения: фиксированные списки, единые форматы времени, аккуратные теги доступа.
• Продумайте схему заранее: не храните в метаданных гигантские массивы/строки — это бьёт по памяти и фильтрации.

Производительность и SLO

• Латентность: меряйте p50/p95/p99 поиска отдельно от времени переранжирования. Для интерактивного RAG ищите 100–300 мс на ANN + фильтры.
• Throughput: планируйте RPS, пики и параллелизм запросов. Трассируйте «запрос → ретрив → генерация» на уровне запроса.
• Recall@k/NDCG: держите «золотой» набор запросов и регулярно гоняйте offline-evals (см. Evals).

Экономика и эксплуатация (FinOps)

• Размерность векторов выбирайте под модель эмбеддингов — не «с запасом».
• k держите умеренным (5–10); «про запас 20+» обычно лишь раздувает латентность и контекст у LLM.
• Кэш: храните эмбеддинги вопросов и top-k результатов для частых запросов. Инвалидируйте при переиндексации.
• Инкрементальные апдейты вместо «редких крупных» заливок — сглаживают пиковые затраты и скачки качества.

Расширенные приёмы оптимизации — на странице Cost optimization LLM.

Сравнение с альтернативами

Примечание: выбор часто гибридный — «горячий» слой в Weaviate/managed, «холодные» архивы в объектном хранилище.

Лучшие практики внедрения

• Делайте дедуп перед индексацией; не тащите шаблонные «хвосты» документов.
• Применяйте гибрид на корпусах с терминами/артикулами; добавляйте переранжирование для «узких» вопросов.
• Разносите языки/домены по коллекциям либо явно маркируйте lang/domain и фильтруйте на запросе.
• Ведите версионирование эмбеддингов: новая модель → новый индекс/namespace; смешение эмбеддингов ухудшает Recall@k.
• Для приватных данных используйте строгие фильтры прав, не подмешивайте чужие пространства.
• Наблюдаемость: метрики p95, hit-rate кэшей, доля «пустых» выдач, тревоги на падение Recall@k.

Ограничения и риски

• Смешение эмбеддингов разных моделей в одной коллекции снижает качество — держите согласованность.
• Слабые метаданные → много «шумных» кандидатов, растут k и контекст у LLM.
• Отсутствие переранжирования на неоднозначных запросах — модель берёт релевантные, но не лучшие чанки.
• Нулевая наблюдаемость — улучшения «на глаз» вместо метрик.

Мини-чек-лист запуска в прод

1. Цели: p95 поиска, Recall@k, доля ответов с цитатами у LLM.
2. Схема метаданных: язык, дата, раздел/продукт, права доступа.
3. Выбор модели эмбеддингов и размерности; подготовка «золотого» набора запросов.
4. Чанкинг 400–1200 токенов, перекрытие 50–150; дедуп, нормализация.
5. Кэш эмбеддингов и top-k; лимит k по сценариям.
6. Переранжирование «по требованию»; гибридный поиск, если корпус терминный.
7. Мониторинг: латентность, hit-rate, Recall@k/NDCG, «пустые» выдачи.
8. Процедура переиндексации при смене модели эмбеддингов.

Мини-глоссарий

• ANN — приближённый поиск ближайших соседей.
• Эмбеддинг — векторное представление текста/объекта.
• Гибридный поиск — комбинирование dense и sparse сигналов.
• Переранжирование — доранжирование топ-кандидатов «тяжёлой» моделью.
• Recall@k / NDCG — полнота и качество ранжирования.

См. также

• Pinecone
• Vector index
• Retriever
• Model serving
• Cost optimization LLM
• Evals