Англійська для розробників pgvector

pgvector став популярним способом додавання пошуку векторної подібності безпосередньо у Postgres, уникаючи потреби у створенні окремої бази даних векторів. Якщо ви працюєте з pgvector у міжнародній команді, вам знадобиться точна англійська мова для опису вбудовування, стратегій індексування і швидкості виконання запитів. Цей підручник містить основні слова для розробників pgvector.

Ключовий словник

** Вбудовування ** — числове векторне представлення тексту, зображень або інших даних, створене за допомогою моделі машинного навчання, яке захоплює семантичний зміст.

• “Ми зберігаємо вбудоване зображення для кожної статті підтримки поряд з її текстом, щоб ми могли знайти семантично схожі статті.” *

** Векторна колонка ** — колонка Postgres типу vector, яку використовує pgvector для зберігання вбудованих даних фіксованої довжини.

• “Ми додали векторну колонку з 1536 розмірами, щоб вона відповідала розміру виводу нашої вбудованої моделі.” *

** Метрика відстані ** — математична функція, яку використовують для вимірювання подібності між двома векторами, наприклад, косинусної відстані, відстані L2 або внутрішнього добутку.

• “Ми використовуємо косинусну відстань для нашого пошуку, оскільки наші вкладення не нормалізовані за величиною.” *

** Пошук найближчого сусіда ** — запит, який знаходить вектори, найбільш схожі на вказаний вектор запиту, зазвичай, це основа семантичному пошуку.

• “Пошук найближчого сусіда повертає п’ять найважливіших документів для запитання користувача за менше ніж 50 мілісекунд.” *

** HNSW index ** — тип індексу найближчого сусіда, заснований на графі, у pgvector, що надає можливість швидкого виконання запитів за рахунок точного вивантаження.

• “Ми перейшли від плоского сканування до індексу HNSW, коли наша таблиця вбудовування перевищила мільйон рядків.” *

** IVFFlat index ** — тип індексу з інвертованим файлом у pgvector, який кластеризує вектори у розділи для прискорення приблизного пошуку.

• “Індекс IVFFlat вимагає виконання операції ANALYZE після завантаження даних, інакше планувальник запитів вибере недостатню кількість зондів.” *

** Recall ** — відсоток справжніх найближчих сусідів, які було повернено за допомогою наближеного пошуку, використовується для вимірювання якості індексу.

• “Ми налаштовували параметри HNSW, поки не досягли 95% відновлення без жертвування занадто великої затримки запиту.” *

** Гібридний пошук ** — стратегія пошуку, яка поєднує векторну схожість з традиційним пошуком за ключовими словами або повнотекстовим пошуком для поліпшення відповідності.

• “Гібридний пошук використовується у випадках, коли користувач шукає точний код помилки, який не буде знайдено за допомогою чистого семантично- семантичного пошуку.” *

** Переранкування ** — крок оцінювання другого проходу, застосований до початкового набору результатів кандидатів для поліпшення остаточного порядку.

• “Ми переранжуємо перші 50 результатів векторного пошуку за допомогою моделі перехресного кодування перед показом перших 5 користувачеві.” *

Обговорення індексних виборів

• «Ми обрали HNSW над IVFFlat, тому що наш обсяг запису низький, а затримка запиту важливіша, ніж час побудови індексу»
• «Перебудова індексу після масового імпорту тривала двадцять хвилин, тому ми запланували його під час нашого вікна обслуговування»
• «Ми індексуємо тільки вбудовану колонку, а не сирий текст, оскільки текст живе в окремому повнотекстовому індексі пошуку.»

Пошук по ключових словах

• «Користувачі скаржилися, що результати пошуку відчували себе «близько, але не зовсім правильно» — ми відслідковували це за допомогою відстані L2 замість косинусної відстані для нормалізованих вбудованих даних»
• «Ми додали крок переранжування, тому що сирова векторна схожість сама по собі занадто високо ранжувала деякі результати поза темою»
• «Recall dropped after we lowered the ef_search parameter to reduce latency — we’re now testing a middle ground.» (англійською)

Професійні поради

1. ** Знайти відповідність між метрикою відстані і тим, як було навчено модель. ** Використання неправильної метрики тихо погіршує якість пошуку, не викликаючи помилок.
2. ** Пояснити компроміси приблизного пошуку зацікавленим сторонам. ** « Приблизний » може звучати тривожно — розгляньте його як навмисний вибір швидкості проти точності.
3. ** Перед вибором типу індексу, перевірте його. ** HNSW і IVFFlat поводяться дуже по- різному при різних розмірах даних і шаблонах запиту.

Практичні вправи

1. Поясніть співробітнику команди 3- 4 реченнями, чому ви обираєте косинусну відстань замість відстані L2 для вбудовування.
2. Напишіть коротке пояснення (4- 5 речень) щодо того, що таке індекс HNSW і чому він прискорює пошук найближчого сусіда.
3. Опишемо ваду якості пошуку, яку ви виправили додаванням гібридного пошуку або зміною позицій, так, щоб керівник продукту, який не має технічних знань, міг її побачити.

Навигація по лінії — практичний підхід

Будьмо чесними; початкове захоплення від створення з pgvector може швидко перерости у потоп відгуків. Як розробник, ви не просто пишете код; ви повідомляєте його намір, обґрунтовуєте рішення і отримуєте критику, яка формує весь процес. Освоєння словникового запасу навколо цього спілкування - особливо при роботі зі складними концепціями, такими як вбудовування і пошук подібності - є * критичним *. Не достатньо просто зрозуміти технічні деталі; вам потрібно сформулювати їх чітко і впевнено, як в перегляді коду, так і в ширших обговореннях.

Розглянемо такий сценарій: Ви реалізували новий гібридний індекс пошуку, який поєднує точне збіг фрази з косинусною подібністю у вбудованих векторах. Під час перегляду коду старший інженер коментує: «Поточній реалізації не вистачає ясності щодо вагань, застосованих до різних векторів. Важко визначити, чи система приоритизує точність або відновлення. Чи могли б ви розкрити вашу логіку і, можливо, запровадити журналювання для ключових показників, таких як частота відповідей на запити проти поширеності індексів?» Це не про суперечки; це про відповідь з технічно вірним поясненням, використовуючи точний словник. Сказати «Я оптимізував пошук» набагато менш ефективно, ніж сказати: «Я використав косинусну схожість, щоб захопити семантичні відносини разом з точним індексом фрази, визнаючи, що пріоритетизація вимови вимагає більшої ваги для більш широких векторних збігів»

Поширене повідомлення Slack, з яким ви можете зіткнутися, може бути таким: «Привіт, команда, нам потрібно підвищити продуктивність наших рекомендацій продуктів. Роздуми про переіндексування за допомогою pgvector і експерименти з різними метриками відстаней. Хтось має досвід використання Евкліда проти Мангеттен?» — здатність обговорювати ці нюанси — розуміння наслідків вибору однієї метрики над іншою — є ключем. Формування ваших думок за допомогою таких термінів, як «семантична дрейф», «зменшення розмірності», або навіть посилання на конкретні метричні відстані («Евклідова відстань сприяє більшим значенням, що, можливо, призводить до упередження, якщо не ретельно калібрувати») демонструє глибший рівень залучення і дозволяє більш продуктивні розмови. Це про перехід від простого роблення роботи до активного формування дискусії навколо неї.

Нарешті, важливо створити чіткі описи PR, які включають цей словник. Замість « Оновлений індекс » спробуйте: « Впроваджено новий гібридний індекс пошуку, який використовує косинусну схожість з індексом точної фрази для поліпшення відновлення запитів користувачів, пов’ язаних з можливостями продукту. Система тепер використовує налаштовувану схему вагань для динамічного регулювання між точністю і відкликанням на основі характеристик запиту, відстежуваних за допомогою внутрішніх метрик журналювання. ”

# Example pgvector CLI command - demonstrating creating an index with a specific distance metric:
pgvector_cli create --db mydatabase --collection products --index type=gist --distance=cosine

Ця проста команда показує, яким чином лексика — « gist », « cos » — часто використовується для обговорення і усунення помилок у стратегіях індексування.