В этом материале
Повторная оценка по полным векторам меняет порядок кандидатов Hamming, но не возвращает отсутствующие среди них релевантные документы.
Бинарное квантование в pgvector помогает формировать кандидатов, но не заменяет проверку итоговой релевантности исходной метрикой векторов. Сохраняйте оригинальные данные, если схема предусматривает shortlist по Hamming и последующее ранжирование полными векторами.
Сохранить два пространства расстояний
Официальные примеры pgvector создают expression-индекс над binary_quantize, затем повторно ранжируют кандидатов исходными эмбеддингами. Расстояние Hamming сравнивает бинарные представления; оно не является исходным cosine или Euclidean distance. Shortlist способен быть полезным, не сохраняя каждого первоначального соседа. Описание обоих этапов как одного точного поиска скрывает приближение, от которого зависит доступность документов для последующей оценки. Это различие должно оставаться в схеме и результатах проверки.
Согласовать размерность и операторы
SQL-определения различают операции битовых векторов и операторы vector либо halfvec. Проверяйте объявленную битовую длину и представление обеих сторон запроса. Одинаковая длина массива ещё не доказывает совместимость моделей запроса и документа. Сохраните идентичность checkpoint и обработку входа вместе с SQL-набором проверки. Корректный с точки зрения типов запрос не является доказательством семантической корректности поиска по реальным документам выбранного корпуса.
Сделать двухэтапный опыт явным
Подготовьте небольшой корпус с точными результатами по исходным векторам. Сначала запросите ограниченный набор бинарным индексом, затем переупорядочите только эти идентификаторы объявленным полным расстоянием. До анализа финального порядка сравните покрытие shortlist с точным эталоном. Этот опыт не задаёт универсального числа кандидатов. Расширяйте список осознанно и записывайте, какие новые доказательства меняют результат, а не считайте любой более широкий набор полезным независимо от дополнительной работы.
| Наблюдение | Что оно подтверждает |
|---|---|
| Полнота shortlist | Сохранение нужных доказательств после приближения |
| Итоговая релевантность | Полезный порядок уцелевших кандидатов |
| Полное время | Стоимость обоих этапов вместе |
Найти границу пропуска
Если документ отсутствовал до reranking, это потеря формирования кандидатов. Неожиданная финальная позиция уцелевшего документа требует проверки исходной метрики и представления запроса. Фильтры добавляют ещё одну границу, поэтому сохраняйте их точное условие и положение в цепочке. Настройка финального порога не компенсирует документы, которые не были допущены. Она меняет выдачу, но не исправляет потерю доказательства, ставшую причиной отсутствующего результата.
Разделить версии и объёмы
Журнал изменений проекта фиксирует появление возможностей и последующие изменения бинарного квантования. Проверяйте установленное расширение, не распространяя опубликованный пример на каждый выпуск. Бинарный индекс может занимать меньше места при сохранённой исходной таблице. Повторное ранжирование читает эти данные, поэтому важны хранение и локальность доступа. Изменение размера в чужом тесте не определяет потребление памяти и время собственного корпуса с другим распределением запросов.
Оставить исходный контроль
Сохраните точную выдачу, идентификаторы кандидатов, финальные результаты и настройки вместе. Сравнивайте изменения по тем же запросам и разметке. Удаление оригинальных векторов ради дополнительной экономии отменяет прежний этап проверки полными значениями и требует нового решения о качестве. Приёмка должна явно называть используемое приближение и наблюдаемое покрытие доказательств, а не представлять бинарный поиск бесплатной заменой исходного представления.
Связанные материалы: PostgreSQL и pgvector для RAG: когда хватит существующего сервера; FAISS и память сервера: библиотека индексов или готовая база.