У корпоративному середовищі основні AI/ML рішення зосереджені на чат-ботах, і через свою природу вони часто намагаються вирішити завдання за допомогою системи RAG. Модель роботи RAG (Request Augmented Generation) полягає в тому, щоб спробувати передати AI-моделі лише релевантні частини документації, замість того щоб передавати всю документацію по продукту, щоб модель могла сформулювати точну (надіємось правильну) відповідь, враховуючи питання користувача та контекст.
Проста архітектура RAG
Сьогодні ми будемо зосереджуватися на знаходженні "релевантних частин" і досліджувати, як працює це рішення на текстах українською мовою.
Пошук на основі embedding
Коли я розмовляю з колегами, які тільки починають знайомитися з цією темою, я зазвичай пояснюю embedding як "семантичний відбиток" заданого тексту. Ми передаємо довге речення або навіть абзац / повний розділ, і на виході отримуємо довгу числову послідовність (вектор), яка репрезентує зміст цього тексту.
Основи
Основою пошуку на основі embedding є те, що схожі за змістом / значенням тексти генерують схожі вектори, тому порівнюючи їх, можна визначити, чи є текст релевантним, чи ні.
Ось дуже простий приклад з Cohere Playground:
Хто на кого впливає — 2D репрезентація embedding, кольори від мене
Правильні відповіді показані на точках 3 та 5. Дуже добре видно, що хоча зміни є лише у порядку слів або навіть у окремих буквах, така низько-розмірна модель точно репрезентує значні зміни у змісті речень. На ділянці, позначеній синім, Фері знаходиться попереду, а на фіолетовій — Піштя. Червона лінія показує поділ впливу: під нею Піштя — це той, на кого впливають, а вище — Фері.
Масштабуємо
В реальній практиці embedding не є векторами розмірності 1-2, вони зазвичай мають 512 або більше (2-3 тисячі) вимірів. Нам потрібен метод для порівняння цих векторів, щоб потім можна було визначити, чи є зв'язок між нашими текстами. Існує кілька таких методів, і я зараз не буду вдаватися в деталі. Для тих, хто цікавиться, Serkan Özal написав чудову статтю на цю тему (просту і коротку):
[
Vector Search For AI — Part 1 — Vector Similarity Search Algorithms
Data is key in the fast-evolving field of Artificial Intelligence (AI). Vector similarity search methods and vector…
medium.com
](/@serkanozal/vector-similarity-search-53ed42b951d9?source=postpage-----8207f2bf5cdc--------------------------------)
На практиці зазвичай використовують косинусну подібність, тому ми зосередимося саме на ній: це показує, який кут між вектором запиту (query) користувача та вектором контенту (chunk). Якщо контент ідентичний, то значення косинусної подібності буде 1, якщо сильно відрізняється — 0 (вектори перпендикулярні), а якщо контент протилежний, то -1. Ось приклад на основі моделі MiniLM:
Приклад подібностей MiniLM
Цю метрику можна дуже добре використовувати, бо можна сказати, наприклад, що “якщо подібність більше 0.73, то можна брати chunk, а якщо менше — ні”. З інформатичної точки зору це дуже проста та гарна задача.
Взаємозамінність
Embedding різних постачальників / розробників не є взаємозамінними між собою. Це відбувається через те, що різні моделі репрезентують різні "речі" на основі різних даних і з різною довжиною.
Це означає, що, наприклад: вектори embedding, згенеровані OpenAI, не можна порівнювати з embedding векторами Granite (IBM), оскільки їх вимірювання значення різні. Потрібно стежити за тим, щоб embedding в нашій RAG системі були єдиними, і якщо ми їх змінюємо, то треба перерахувати всі частини документів. Але, на щастя, це лише одноразова операція.
Вибір embedding для нашої RAG системи!
Як і LLM, якість embedding значною мірою залежить від якості навчальних матеріалів. Тут ми маємо як embedding, навчені на англомовних корпусах, так і багатомовні моделі. Важливо, щоб ми вибрали embedding, які генерують дуже хороші (чутливі) вектори для нашої проблеми пошуку та мовного середовища.
MTEB лідерборд
Звичайно, немає конкретного тестового набору, оптимізованого для угорської мови, але певною мірою допомагає MTEB (Massive Text Embedding Benchmark), який дає хороше уявлення про якість. Результати публікуються на Huggingface, лідерборд варто переглянути при виборі моделі:
Результати тестів, орієнтованих на пошук (retrieval) для польської мови (2025.01.06)
На перший погляд не привертає увагу, але серед виконаних тестів є й угорськомовні, які проводяться на корпусі SZTAKI korpuszán. Ви знайдете їх у наступному розділі:
Розділ Classification / Other languages (перші три місця в категоріях — 2025.01.06):
- MassiveIntentClassification (hu): GritLM-7B, e5-mistral-7b-instruct, multilingual-e5-large-instruct
- MassiveScenarioClassification (hu): e5-mistral-7b-instruct, GritLM-7B, multilingual-e5-large-instruct
Угорські моделі
На щастя, є угорською мовою навчені моделі, які обов'язково варто спробувати. На жаль, ці моделі не включені в MTEB тести, тому ми не можемо порівняти їх в лістингу — хіба що ви завантажите тест самі і запустите. Що варто спробувати: huBERT та XLM-roBERTa.
Практично це питання вирішується компаніями шляхом створення власних тестів для їхнього (RAG) рішення (оскільки для автоматизованих тестів це потрібно зробити), і пробують, який embedding підходить для їхніх цілей.
Хочу згадати, що в Інституті мовознавства Петро Хатвані та Ян Цзідянь Гьозьо працювали над подальшим навчанням запропонованих моделей і досягли дуже хороших результатів. Опис можна прочитати тут: Training Embedding Modells for Hungarian, думаю, варто ознайомитись.
Тестуємо
Раніше я згадував, що при тестуванні end-to-end якість embedding буде зрозуміла. На практиці це означає, що необхідно повторно індексувати (перерахувати) існуючий контент, і коли у вас є сотні мільйонів частин, це не тривіально. Тестування RAG є "дорогою" операцією, тому важливо провести якийсь стандартний набір тестів, щоб хоча б мати уявлення, чого можна очікувати від embedding.
Оскільки я раніше працював з корпусом HuLU, я вирішив вибрати підходящі набори. Я шукав набори, що дозволяють змоделювати ситуацію, коли користувач задає коротке питання, і його потрібно порівняти з довшим текстом. Ось що я знайшов корисним:
- HuRTE (Recognizing Textual Entailment): дають коротке речення, зміст якого міститься в оригінальному тексті або не міститься.
- HuWNLI: порівнюють два дуже схожих речення з точки зору того, чи одне містить інше. Різниця лише в кількох словах.
Примітка: Петро і Гьозьо використовують набір STS у своїй роботі, але він наразі недоступний.
Якщо публічно буде доступно, я знову запущу тести.
Метод оцінки досить простий: для пар речень я генерую embedding по черзі, обчислюю косинусну подібність, візуалізую гістограму отриманих значень, намагаюсь задати "cutoff" значення для категоризації, а потім порівнюю результати з еталонними значеннями, які є в тестовому наборі (з мітками).
Основна ідея полягає в тому, що між даними з міткою 0 косинусна подібність буде низькою (менше 0.5, навіть можуть бути від'ємні значення), а між даними з міткою 1 — високою (понад 0.5, до 1). Ось що я уявляв:
Я припускав, що повинно бути чітке "розмежування", яке розділяє випадки, де між реченнями є зв'язок / немає зв'язку. Давайте подивимося на результати...
Оцінка на тестовому наборі HuRTE
У корпусі 2132 пари даних, що є досить великою вибіркою для релевантних вимірів. Щодо моделей embedding, я вибрав ті, які доступні за замовчуванням в Ollama за посиланням, а також моделі OpenAI text-embedding.
Яка модель яким міткам відповідає, які значення косинусної подібності знайдено (% від усіх даних)
Трохи допомоги для інтерпретації: модель вважається кращою, якщо червона лінія та синя лінія мають мінімальне перехрестя.
Чесно кажучи, результати в верхньому ряду трохи засмучують, і лише в другому ряду можна побачити певну надію на те, що буде можливість реалізувати змістовний пошук, але й тут є велика перекриття.
Зазначу, що ми не можемо очікувати ідеальних результатів, оскільки цей корпус не призначений для тестування задач типу "retrieval". Саме те, що embedding може значущо відрізняти тексти з високою мовною деталізацією, я вважаю великою перемогою.
Альтернативні рішення
Під час проведення тестів у мене виникло підозра, що метод перевіряє схожість слів / токенів. Я знаю, що він перевіряє семантичну схожість, але важко стриматися, коли бачиш в прикладі однакові слова. І я пам'ятаю, що минулого року на виступі з RAG один з експертів порадив, що якщо ти тільки починаєш працювати з цією темою, то замість embedding можна застосувати пошук по базі даних.
Об'єднавши підозру і цю пораду, я провів ще одне вимірювання, де перевіряю, скільки слів з запиту знаходиться в описі. Я проводив два види пошуку: повна відповідність слів, та відповідність початкових частин слів (це має сенс через наявність відмінків).
Легенько зауважу, що ці альтернативи пошуку підтримуються в Elasticsearch за замовчуванням.
Який метод скільки знайдених елементів відповідає для кожної мітки, в процентах від загального числа
Цікаво, що між двома методами немає великої різниці, але що здивувало, ці надзвичайно прості методи категоризації дали третій найкращий результат.
Однак давайте правильно оцінимо цей результат: в тестовому наборі йдеться, що пари речень містять багато схожих слів, і потрібно розрізняти їх. Для позитивних зв'язків в реченнях більше однакових слів. Якщо б ми працювали з даними, де були лише синоніми, цей метод був би набагато менш ефективним.
Досвід, оцінка
Тести (окрім OpenAI) я проводив на власному комп'ютері.
Embedding використовують GPU в різній мірі в залежності від архітектури: менші моделі майже не використовують GPU (їх можна було б запускати навіть на CPU), тоді як більші моделі (наприклад, BGE моделі) можуть повністю навантажити RTX4080.
Час відповіді для MiniLM був найшвидший, він давав результат у межах 10–15 мсек, тоді як для інших моделей час відповіді був у діапазоні 40–100 мсек, що дозволяє проводити масштабування.
У стабільності тестів не було проблем, за винятком двох випадків:
- У bge-large моделі дві записи стабільно давали помилки. За інформацією з форумів, це проблема з llama.cpp, над якою працюють.
- У OpenAI small моделі постійно виникала помилка для іншої записи, ймовірно через спеціальні лапки, які модель не сприймала.
Витрати: Тести OpenAI коштували 0.04 USD за кожен запит. Це не є великим витратним елементом у межах проєкту.
Щодо якості мене здивувало, що не OpenAI виграла в цій категорії, до цього ми звикли у LLM. Однак я був розчарований тим, наскільки низькою була "якість". Не дивно, що в RAG системах багато часу витрачається на перерахунок знайдених chunk'ів (reranking та інші підходи), адже вже сам процес визначення релевантності працює з досить низькою ефективністю. Сподіваюся, що моделі, навчені на більш розвинених, багатших наборах даних, допоможуть вирішити це в майбутньому.
Підсумки
Якщо б я мав підсумувати висновки в кількох пунктах, я б сказав наступне:
- варто працювати з open-source моделями, оскільки вони можуть давати кращі результати, ніж закриті моделі
- потрібно тестувати якість embedding на своїх даних, тому що результати залежать від конкретних use-case
- можна запускати моделі навіть на власному комп'ютері, оскільки вони малі і швидкі
- на початкових етапах розробки RAG систем навіть прості бази даних і "old-school" пошукові системи можуть давати хороші результати
Сподіваюся, що результати були корисними. У наступній статті я подивлюсь на якість embedding від інших постачальників і, мабуть, заглиблюсь у пошуки на основі синонімів / схожих значень.
Перекладено з: Mennyire tudnak magyarul az embedding-ek?