Qdrant Vocabulary: English for Vector Search Engineers (англійською)

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

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

** Collection ** — Названий контейнер, у якому містяться всі точки (векторів і їх метадані) для певного випадку використання. Збірки є організаційною одиницею верхнього рівня у Qdrant, подібно до таблиці у реляційній базі даних.

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

** Вектор ** — Числовий масив (список чисел з рухомою комою), який представляє семантичний зміст частини даних. Вектори створюються за допомогою вбудованих моделей і є основним типом даних, який зберігає і шукає Qdrant. “Кожен опис продукту перетворюється на 1536-вимірний вектор перед тим, як його вставляють у колекцію.”

** Корисна нагрузка ** — структуровані метадані, приєднані до точки разом з її вектором. У корисному навантаженні можна зберігати будь- які дані, сумісні з JSON — текст, числа, булівські функції або масиви — і використовувати його для фільтрування результатів пошуку.

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

** HNSW Index ** — скорочення від Hierarchical Navigable Small World, це структура індексу на основі графа, яку використовує Qdrant для швидкого наближеного пошуку найближчого сусіда. HNSW торгує невеликою кількістю точності відновлення для значно швидших часів запиту в масштабі. “Після налаштування параметрів індексу HNSW, наша затримка запиту p99 впала з 80 мс до 12 мс на колекції з десяти мільйонів точок.”

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

• “Поєднуючи щільний семантичний вектор з розрідженим вектором ключових слів, ми поліпшили відновлення запитів, що містять рідкісні терміни, специфічні для домену.” *

** Багатокористувацькість ** — архітектурний шаблон, у якому одна колекція Qdrant обслуговує декількох незалежних користувачів або організацій, використовуючи поля корисної інформації або іменовані вектори для логічного розділення даних кожного користувача. Це уникає надмірних витрат на створення тисяч окремих колекцій. “Наш продукт SaaS використовує багатокористувацький підхід з полем корисної нагрузки tenant_id і строгим фільтруванням, щоб не допустити витоку даних між клієнтами.”

** Квантування ** — Метод, який зменшує слід пам’ яті збережених векторів за рахунок представлення кожного числа з рухомою комою меншою кількістю бітів, наприклад, перетворення 32- бітових чисел з рухомою комою на 8- бітові цільні числа або навіть 1- бітові двійкові значення. Qdrant підтримує квантування скалярних, добутку і двійкових функцій.

• “Ввімкнення скалярного квантування зменшило використання пам’ яті приблизно в чотири рази, з незначним зниженням точності пошуку.” *

** Названі вектори ** — функція, яка надає змогу зберігати у одній точці Qdrant декілька різних векторів з різними назвами, кожен з яких представляє один і той же об’ єкт з різної моделі вбудовування або модальності.

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

Корисні фрази

Ось речення, які ви зазвичай почуєте і почуєте під час роботи з Qdrant у англомовному інженерному середовищі:

• «Давайте upsert нові вбудовування в колекцію — upsert означає вставити, якщо точка не існує, або оновити її, якщо вона існує»
• «Ми повинні додати ** індекс корисної нагрузки ** на category поле, перш ніж ми можемо ефективно фільтрувати в цьому масштабі.»
• «Параметри ef в конфігурації пошуку HNSW контролюють розмір набору кандидатів — вищі значення покращують відновлення, але збільшують затримку»
• “Чи можете ви перевірити, чи ввімкнено ** квантування ** для цієї збірки? Це може пояснити пік пам’яті, який ми бачили на панелі приладів»
• «Ми плануємо ** розділити ** колекцію на декілька вузлів, щоб обробляти прогнозований ріст протягом наступного кварталу. »
• «scroll API дозволяє вам переглядати всі точки в колекції без пошуку векторної схожості.»

Поширені помилки

Плутанина «збірки» з «індексом»

Інженери, які працюють у Elasticsearch або OpenSearch, часто називають збірку Qdrant « індексом ». У Qdrant, * індекс * відноситься до структури графа HNSW, збудованої * всередині * збірки для прискорення пошуку. Сказати « Я створю новий індекс для даних про продукт » збентежить колег — замість цього скажіть « колекція ».

Неправильно вимовляєте або неправильно пишете “квантування”

У британській англійській мові правильним написанням є ** quantisation ** (з * s *), а не « quantization ». Ще важливіше те, що інженери іноді плутають * quantisation * (точність стиснення векторів) з * error of quantification * (втрата точності, що виникає внаслідок цього). Коли ви висловлюєте занепокоєння в огляді, будьте конкретними: «квантування ввімкнено» проти «ми бачимо високу помилку квантування»

Розгляд « корисного навантаження » і « метаданих » як завжди взаємозамінних

У загальній розмові вони часто означають одне і те ж, але в документації Qdrant «корисна нагрузка» має певне технічне значення — це структурований об’єкт JSON, приєднаний до точки. Використання «метадані» при написанні Qdrant-специфічних квитків або документації може викликати плутанину, тому що офіційний API, SDK методи, і конфігурації ключів всі використовують термін payload.

---

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

Мова йде про те, що мова не є рідною для мовців

Будьмо чесними. Технічний жаргон сам по собі може бути значною перешкодою, але коли ви вивчаєте професійну англійську - особливо в швидко розвивається галузі векторного пошуку - тонкощі фразування і очікування можуть відчувати себе ще більш пригнічуючими. Це не просто про те, щоб знати * визначення * «рідкісних векторів »; це про те, як ви ефективно передаєте ці знання вашій команді, таким чином, що сприяє співпраці і уникнення непорозумінь. Багато розробників, які вивчають англійську для цієї області, спочатку зосереджуються на точних визначеннях, що важливо, але часто не враховують ключовий елемент контексту - немовлені припущення і улюблені стилі спілкування в середовищі розробки.

Однією з ключових областей, де ця відмінність проявляється, є зворотній зв’язок і пріоритетність запитів. Простий «виправлення помилки» може бути інтерпретований дуже по-різному в залежності від навколишньої розмови. Розглянемо коментар перегляду коду: « Це вбудування векторів ідеально було б нормалізувати ». Хоча це технічно коректно, воно може бути надто прецедентним або навіть відвертим, якщо його не супроводжуватиме пояснення, чому нормалізація є важливою — можливо, пов’ язаною з оптимізацією продуктивності під час індексування або виконання запиту. Більш корисною формулюванням може бути, “Чи можемо ми дослідити нормалізацію цих вбудовувань? Я бачу деякі незначні невідповідності в відстанях і це впливає на наші показники затримки запиту. “Це визнає потенційну проблему, запрошуючи обговорення про рішення. Аналогічно, під час написання опису запитів на витягування, важливо дати докладне пояснення ваших змін — не просто скажіть « Реалізовано індексування HNSW ». Замість цього скажіть: « Реалізовано індексування HNSW для збірки product_embeddings, щоб поліпшити швидкість пошуку і зменшити слід у пам’ яті, особливо, коли ми масштабуємо для обробки зростаючої кількості векторів »

Інша поширена пастка полягає в тому, що всі мають однакове розуміння показників продуктивності. Фрази на кшталт «оптимізувати затримку» часто використовуються, але що конкретно є оптимізацією? Чи скорочується час запиту на 10 мс, чи досягається певна цільова кількість QPS (запитів на секунду)? Чисто визначення цих цілей заздалегідь - можливо, використовуючи спільний словник навколо ключових показників - значно зменшує неоднозначність і забезпечує, що всі працюють на одну і ту ж мету. Також важливо бути уважним до рівнів деталей; перебільшення пояснень може бути таким же шкідливим, як і недопояснення.

Нарешті, пам’ ятайте, що документація не просто надає інформацію; це форма спілкування. Стрімтеся до ясності і стислості, передбачаючи потенційні питання і активно їх вирішуючи. Це не тільки принесе користь вашим колегам, але й зміцнить ваше власне розуміння концепцій, які використовуються.

# Qdrant - Create a new collection with HNSW index
qdrant-cli create collection product_embeddings --index hnswnmf --metric cosine