Сначала сформулируйте нагрузку

Запишите число vectors, размерность, прирост в сутки, QPS, p95 latency, долю обновлений, фильтры и число tenants. Без этих данных сравнение продуктов превращается в перечень функций.

PostgreSQL или отдельный движок

pgvector сохраняет транзакции, SQL, backup и привычную эксплуатацию. Специализированная база обычно предлагает больше search-функций и независимое масштабирование. Цена отдельного кластера включает мониторинг, миграции и новую компетенцию команды.

Exact и approximate search

Exact nearest neighbor даёт точный baseline, но плохо масштабируется. HNSW обычно предлагает сильный speed/recall trade-off ценой памяти и более тяжёлой сборки. IVFFlat дешевле по памяти и быстрее строится, но требует обучения и настройки lists/probes.

Фильтры меняют результат

ANN может сначала найти соседей, а затем отфильтровать их - в итоге вернётся меньше k документов. Проверяйте pre-filter, post-filter и iterative scans на ваших tenant и permission-фильтрах. Фильтрация - часть качества, а не только безопасности.

Hybrid search и reranking

Если нужны артикулы, имена и точные формулировки, проверьте BM25/sparse retrieval, fusion и reranker. Встроенная поддержка сокращает код, но не отменяет eval-набор и контроль latency.

Multitenancy и доступ

Сравните shared collection с tenant filter, отдельные partitions и отдельные collections. Нужны доказуемая изоляция, quotas, encryption, audit и удаление данных клиента. Один общий ANN-индекс может влиять на recall разных tenants.

Надёжность и переносимость

Проверьте snapshots, point-in-time recovery, replication, rolling upgrade, export и восстановление на чистом кластере. Архив без регулярного restore drill нельзя считать резервной копией.

Считайте TCO и exit plan

Включите RAM индекса, реплики, storage, egress, ingestion, reranking, инженеров и простой миграции. Проведите небольшой bake-off на одинаковом корпусе и заранее зафиксируйте формат экспорта vectors и metadata.

С чего начать внедрение?
С узкого сценария, измеримого baseline и набора реальных запросов. Сначала зафиксируйте качество и ограничения, затем меняйте один параметр за эксперимент.
Какие метрики считать обязательными?
Качество результата, p95 latency, ошибки, стоимость и отдельные метрики ключевого этапа. Среднее значение без сегментов и percentiles скрывает провалы.
Можно ли выбрать параметры по документации?
Документация задаёт безопасный baseline, но финальные параметры выбирают по собственному корпусу, нагрузке и eval-набору.
Как обновлять систему без риска?
Версионировать конфигурацию, запускать shadow-сравнение, затем canary и иметь заранее проверенный rollback target.
Почему нужен набор отрицательных примеров?
Он показывает, умеет ли система отказываться и не поднимать нерелевантные результаты только потому, что они ближайшие среди доступных.
Что сохранять для расследования?
Версии компонентов, trace ID, параметры запроса, IDs доказательств, решения фильтров и агрегированные метрики с соблюдением правил доступа и retention.
← Все статьи блога