| +11 голос |
|
Я вже приблизно рік займаюся декількома AI-проєктами, в тому числі RAG-ботом (Retrieval-Augmented Generation), і весь час дізнаюся для себе щось нове. Чому б не поділитися?
Розробка RAG-чатбота вважається простим завданням – багато хмарних платформ, від OpenAI до Cloudflare, пропонують навіть готові рішення, де все можна налаштувати кліками у вебінтерфейсі. Та й для власної розробки немає особливих проблем – візьміть базу знань, розділіть її на невеликі фрагменти, однорідні за змістом (наприклад, питання-відповідь або розділ у великому документі), обчисліть для цих фрагментів векторне представлення (embeddings, у найпростішому випадку це дуже дешево робиться через запит до API, наприклад, OpenAI або Google), збережіть у спеціальному вигляді бази, яка називається «векторною», і чекайте на запитання користувача. Отримане питання теж перетворюєте в ембеддінг і тепер на запит з ним векторна база поверне вам результати, найбільш схожі (similar) на поставлене питання. Залишається сформулювати запит до LLM буквально такого змісту «Ти фахівець служби підтримки (або консультант, залежно від завдання), ось питання користувача, ось що ми знаємо на цю тему, сформулюй відповідь».
Насправді як тільки ви виходите за рамки декількох десятків документів в базі та намагаєтеся навчити бота відповідати на складніші питання, починаються деталі, які сильно впливають на всю роботу. Ось про одну з таких деталей я і розповім.
Поки завдання всієї системи до генерації підсумкової відповіді зводиться до пошуку приблизно схожих питань серед вже наявних, все працює досить просто. Але, якщо ви вирішуєте для поліпшення якості відповіді додати в базу інші документи – наприклад, чому б магазину з продажу алкоголю не додати статті про процес виготовлення вина, винні регіони, традиції Північної Європи з виробництва горілки й так далі, – починаються цікаві проблеми. Пошук по векторній базі чомусь не видає ці чудові, повні корисного контексту статті, або ранжує їх помітно нижче банальних відповідей на питання. Ще гірше стає, якщо ви вирішуєте це завдання для області, де є маса інформації нормативного характеру – від законів до новин.
Причина цього дуже проста – хоча векторна схожість, на відміну від точного входження, і враховує семантику запиту, але все ж вона не може знайти результат, де всі або багато слів запиту представлені синонімами, наприклад. Тобто, якщо питання ставить простий користувач, а у вашій базі відповіді суперфахівців, сформульовані в абсолютно точних спеціальних термінах, пошук поверне щось випадкове – просто нічого схожого на питання «А як мені зробити так, щоб у мене швидко працював вай-фай» у вашій базі, де докладно пояснено, які канали Wi-Fi 2,4 GHz частіше зазнають впливу інтерференції в щільній міській забудові, може і не знайтися. Можливо, розумна LLM в результаті якось відповість без будь-яких підказок у промті, але досить часто, щоб виключити ймовірність галюцинацій, їй забороняють користуватися власними знаннями та використовувати тільки зміст контексту, а там випадкові результати.
Дуже погано, якщо мова користувача і документів в базі відрізняється разюче – наприклад, в базі лежать тексти законів і постанов. І проблема довершується, якщо запит користувача дуже короткий – в цьому випадку він стає схожим відразу на всі документи на тему.
Що можна зробити? Звичайно, є варіант зробити пошук гібридним. Тобто проіндексувати базу ще й з побудовою традиційного пошукового індексу і при пошуку за схожістю паралельно шукати за ключовими словами, об'єднуючи ці результати надалі. Але чи можна сам пошук за схожістю зробити кращим?
Виявляється, можна, і це досить нескладно з погляду логіки. Якщо у нас немає ідеального документа для пошуку, давайте його вигадаємо. Техніка HyDE (Hypothetical Document Embedding) працює саме так: перш ніж стукати в базу, ми просимо швидку LLM згенерувати гіпотетичну відповідь на питання користувача. Нам не потрібна фактична точність – нехай модель галюцинує, головне, щоб вона використовувала правильну термінологію і структуру. Замість питання «чому гальмує вай-фай» ми перетворюємо на вектор згенерований пасаж про «інтерференцію каналів і діапазон 2,4 ГГц». Векторний пошук, отримавши такий «м'ясний» контекст, знаходить реальні документи набагато точніше. Результат стає помітно кращим з двох причин. Така гіпотетична відповідь довша за питання, тому ви відсікаєте випадкові збіги у випадку коротких запитів. Плюс LLM набагато краще розуміє сенс питання, а не тільки схожість, і видає вам проєкт відповіді в тих термінах, які використовуються в документах бази. Цим ліквідується той самий розрив між лексикою користувача і документів.
Звичайно, треба попередити про очевидний ризик. HyDE відмінно працює на загальнолюдських знаннях, але на вузькоспеціалізованих даних може зіграти злий жарт. Якщо на специфічне питання щодо внутрішньої корпоративної політики модель згенерує правдоподібну, але неправильну відповідь із загальносвітової практики, вектор цієї відповіді відтягне пошук убік від ваших реальних документів.
Так, швидкість відповіді на питання падає – яку LLM ви не візьмете, вона додасть кілька секунд до процесу обробки питання, а це блокуюча операція. Але пошук та обчислення ембеддінгів теж займають час, а якщо підсумкова LLM у вас розсудна, то кілька секунд на помітне поліпшення якості пошуку себе виправдовують. Ба більше, краще знайшовши результати, ви можете передати LLM менше документів у запиті й в підсумку виявити, що загальний час відповіді особливо не змінився.
Але над цим варто особливо задуматися – якщо у вас невелика база відносно однорідних документів або якщо поточний пошук в середньому рівномірно покриває результатами всі категорії документів, то, можливо, у вас і немає такої гострої проблеми лексичного розриву між запитами та документами, і вам краще подивитися в бік інших способів поліпшити релевантність пошуку – наприклад, витягувати ключові слова або використовувати query rewriting. Але якщо проблема є і тема вимагає кваліфікованої відповіді, то користувач готовий миритися з декількома зайвими секундами до початку генерації більш точної й повної відповіді.
Ось така цікава техніка. Чудово спрацювало в нашому випадку, коли з'ясувалося, що питання користувачів на бухгалтерські та податкові теми, звичайно, схожі на консультації професійних експертів, але зовсім не збігаються з текстами законів і постанов уряду. Ми в результаті додали й HyDE, і пошук за ключовими словами (і переранжування) – і в підсумковий промпт стали набагато частіше потрапляти нормативні документи, а підсумкова розмірковуюча модель стала генерувати приблизно на 25% кращі (за оцінками людей-експертів) (повні та правильні) відповіді.
Stay tuned, у мене ще багато неочевидних знахідок у запасі.
Стратегія охолодження ЦОД для епохи AI
| +11 голос |
|
