Advanced Vector Embeddings Vocabulary: Reranking, Matryoshka, and Beyond (англійською)

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

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

** Переранкування ** — Крок оцінювання другого проходу, який бере початкові результати отримання і переупорядковує їх за допомогою більш дорогої, але більш точної моделі. Інженери кажуть “ми додали переранкер” або “крок переранкерування покращує точність”. Дієслово - “переранкувати”; агент, що це робить, - “переранкер”

«Наше початкове пошукове завдання отримує 50 найкращих кандидатів з векторного індексу, потім переранкер оцінює кожного з них за запитом і ми зберігаємо перші 5. Затримка влучання варте того для нашого випадку використання»

** Cross- encoder ** — архітектура моделі переранжування, яка приймає запит і документ- кандидат разом як єдиний вхід, що дає оцінку відповідності. Це точніше, ніж бі-кодер, але повільніше. Інженери кажуть «ми використовуємо крос-кодер для переранкінгу» або контраст «крос-кодер проти бі-кодера»

«Крос-кодер бачить повний запит-документ пару за раз, тому він розуміє контекст краще — але ви не можете попередньо обчислити ці вбудовування, тому він не масштабується до мільйонів документів.»

** Bi- encoder ** — архітектура вбудованої моделі, яка кодує запит і документ незалежно у вектори, а потім порівнює їх за допомогою косинусної подібності. Швидкий і масштабований, але менш точний, ніж перехресний кодер. Ви почуєте « Повернення двох кодерів » або « Ми вбудовуємо обидві сторони окремо. »

«Ми використовуємо бі-кодер для першого проходу пошуку — ви попередньо обчислюєте вбудування документів один раз і зберігаєте їх у векторній базі даних, а потім у час запиту вам потрібно тільки вбудувати запит.»

** Матриця навчання представлення (MRL) ** — Метод навчання, який створює вбудовування, де короткі префікси вектора самі по собі мають сенс. Названа на честь російських ляльок-гнізд. Інженери кажуть: «ми використовуємо вбудовування матрьошок» або «цю модель тренували з MRL»

«Хороша річ про вбудування Матрюшки в тому, що ви можете обрізати з 1536 розмірів до 256 і все ще отримати пристойну якість — дозволяє нам налаштувати компроміс затримки-якості в час обслуговування»

** Пізня взаємодія ** — архітектура отримання, де вбудовані символи запиту і документа взаємодіють у часі нарахування балів, а не стиснуті спочатку у окремі вектори. ColBERT є канонічним прикладом. Інженери кажуть «моделі пізньої взаємодії» або «це використовує підхід пізньої взаємодії»

«Пізня взаємодія дає вам більш виразне оцінювання, ніж стандартний бі-кодер, тому що токени запиту можуть відвідувати окремі токени документів — але ваш індекс набагато більший.»

** ColBERT ** — Специфічна модель отримання пізньої взаємодії (Contextualized Late Interaction over BERT), яка зберігає вбудовування по токену і використовує оцінку MaxSim. Використовується як іменник, так і прикметник: « ColBERT retrieval », « a ColBERT index. »

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

** Розміри вбудовування ** — довжина вектора, створеного за допомогою вбудованої моделі. Інженери кажуть, що «модель виробляє 768-вимірні вбудовування» або обговорюють «зменшення розмірів» для ефективності. Фраза «високовимірний простір» описує абстрактний простір, який займають ці вектори.

«Ми використовували 1536-вимірну модель для бази знань, але обрізали до 512 для шляху в реальному часі — різниця в якості була менше 2% на нашому наборі оцінок»

** Комбінація вивантаження і точності ** — Під час пошуку, вивантаження вимірює кількість знайдених відповідних елементів; точність вимірює, яка частина отриманих елементів є відповідними. Інженери кажуть: «ми оптимізуємо для відновлення на стадії відновлення» або «переранкер покращує точність»

«У час пошуку ви хочете високу пам’ять — отримати все, що може бути актуальним. Перестановка - це те, де ти збільшуєш точність. Якщо ви оптимізуєте точність занадто рано, ви пропустите щось»

** Вбудовування, не залежне від обрізання ** — Вбудовування (подібні до тих, що тренуються за допомогою MRL), де обрізання до коротшого вектора зберігає відносний порядок подібності. Інженери кажуть, що модель «підтримує обрізання» або «вбудовування є обрізанням-інвариантними»

«Стандартні моделі ламаються, коли ви обрізаєте виміри — осі не впорядковані за важливістю. Моделі MRL спеціально тренуються для цього, тому обрізання безпечно»

** Оцінка семантичної схожості** — Числова оцінка (зазвичай косинус подібності між 0 і 1), яка вимірює, наскільки семантично близькі два тексти. Інженери кажуть «оцінка подібності», «оцінка косинусу», або «модель повертає подібність 0,87»

«Одна річ, на яку варто звернути увагу: подібність 0,85 не означає «дуже відповідний» в абсолютних цифрах — вам потрібно калібрувати пороги проти вашого фактичного набору оцінок»

Фрази в контексті

** Пропозиція зміни рівня в перегляді архітектури: **

“Я б запропонував додати крок перекодування крос-кодера після векторного пошуку. В данный момент мы получаем хороший отклик, но наша точность на позиции 1 ниже, чем мы хотели бы. Крос-кодер може бачити всю пару запит-документ і повинен це очистити — ми запустимо його тільки на 20 найкращих кандидатах, тому вплив затримки повинен бути керованим»

** Пояснення компромісів MRL в обговоренні проекту: **

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

** Обговорення можливості пізнього взаємодії: **

«Пошук ColBERT дійсно переконливий для якості, але вимоги до зберігання є блокуючим фактором для нас зараз — ми говоримо про 50x розмір індексу стандартної установки бі-енкодерів. Варто переглянути, якщо ми перейдемо до окремого кластера пошуку»

Відображення рішення про відкликання проти рішення про точність після смерті:

«Глядачи на випадки невдачі, проблема була в тому, що ми переоптимізували для точності на стадії пошуку. Мы только получали пять лучших документов, что означало, что у переранкера не было достаточно кандидатов, чтобы работать с ними. Ми повинні збільшити вікно пошуку і дозволити реранкеру зробити більше роботи з фільтрування»

Ключові слова

• ** запустити переранжування на ** результатах (не « застосувати переранжування до »)
• ** вбудувати запит ** / ** вбудувати документи ** (не « векторизувати » у більшості сучасних застосувань)
• ** top- k retrieval ** — отримання k найсхожіших елементів: « збільшити top- k з 20 до 50 »
• ** розмір індексу ** — розмір місця на диску для вашого векторного індексу
• ** eval set ** / ** evaluation set ** — ваш еталонний набір даних для вимірювання якості
• ** компроміс між якістю і затримкою ** (не « компроміс між якістю і швидкістю » у технічному письмі)
• ** зменшення розмірів ** / ** обрізання розмірів ** (контекст МЗП)
• ** оцінити кандидата ** — запустити переоцінку одного документа: « перехресний кодер оцінює кожного кандидата »

Practice

Знайдіть публічне обговорення проектування системи RAG — обговорення LlamaIndex або LangChain GitHub, або гілки на форумі Hugging Face — де інженери обговорюють якість пошуку. Прочитайте коментарі і визначте принаймні п’ ять слів з цього повідомлення, які використовуються у природному порядку. Потім напишіть коротке повідомлення у стилі Slack (від чотирьох до шести речень), у якому поясните співробітнику команди, чому ви бажаєте або не бажаєте додати крок зміни рангу до гіпотетичного конвеєра RAG для вашого домену. Будь конкретним щодо компромісу між затримкою і якістю. Це таке пояснення, яке вам слід буде дати під час обговорення справжньої архітектури.