Діагностика проблем з вихідними даними ШІ: коли використовувати запит, отримання чи налаштування
Спосіб, заснований на симптомах, щоб визначити, чи потребує слабка функція ШІ кращого запиту, шару пошуку чи доробки, та чому навчання моделі на фактах призводить до протилежних результатів.
Перша версія будь-якої функції ШІ створює результат, який не є абсолютно правильним. У вас є три способи це виправити: змінити інструкції, надати моделі документи, яких їй бракує, або перенавчити її на ваших власних прикладах. Вони суттєво відрізняються за витратами — від кількох хвилин роботи до тижнів збору даних — і кожен з них усуває різний тип проблем. Цей посібник пропонує підхід, заснований на симптомах, щоб ви могли обрати правильний спосіб та не витрачати тижні на усунення проблеми, яка насправді не потребувала цього.
Ставіться до моделі як до здібного новачка
Корисною уявною моделлю є розгляд моделі як дуже талановитого працівника на першому робочому дні. Він знає величезну кількість інформації про світ загалом, але зовсім нічого про вашу компанію: не про ваші продукти, не про ваші правила, не про те, як ваша команда любить формулювати відповіді. Він буде робити помилки, так само як і будь-який талановитий новачок.
Ви можете допомогти новому співробітнику рівно трьома способами. Ви можете краще проінформувати його, передати йому довідкові матеріали або відправити його на навчальний курс. Це відповідає процедурам створення запиту, пошуку інформації та її доробки, причому вони розташовані в порядку від найдешевших до найдорожчих. Суть полягає у підборі відповідного заходу до конкретної проблеми, тому має сенс розглядати їх у такій послідовності.
Створення запиту: спочатку перепишіть інструкції
Завжди починайте з цього. Запит — це просто інструкції, які ви надсилаєте разом із проханням: саме завдання, один-два приклади хорошої відповіді, для кого призначена відповідь та формат, який ви очікуєте. Його зміна не коштує нічого та займає кілька хвилин. Багато скарг на те, що «ШІ поганий», насправді стосуються неясностей у запиті.
Припустимо, відповіді вашого функціоналу є занадто довгими та формальними. Не потрібно перенавчання. Достатньо додати інструкцію на кшталт „відповідайте у трьох реченнях, теплим та простим тоном“, вставити одну гарну зразкову відповідь — і проблема зазвичай вирішується вже під час першої спроби. Інструкції, які ви встановлюєте для кожного запиту, називаються системними підказками; зразкові відповіді, які ви додаєте для ілюстрації формату, — прикладами типу „few-shot“.
Проте у використанні підказок є чіткий обмеження: інструкції не можуть надати знань, яких модель ніколи не бачила. Якщо новому співробітнику ще не показували показники цього кварталу, прохання „бути більш точним“ не допоможе отримати ці дані. Коли справжньою проблемою є брак інформації, потрібен другий підхід.
Швидка перевірка перед подальшими діями
Перш ніж робити висновок, що метод запитування не спрацював, переконайтеся, що ви спробували очевидні удосконалення: чітко вказайте формат результату, наведіть принаймні один конкретний приклад, сказайте, що робити, коли відповідь невідома, та протестуйте на невеликому фіксованому наборі реальних вхідних даних, а не на одному-двох вибраних випадках. Без цього фіксованого набору важко зрозуміти, чи справді якась зміна допомогла.
Отримання даних: передача файлів
Генерація з підтримкою пошуку документів, яку зазвичай скорочують до RAG, надає моделі доступ до ваших документів у момент надання відповіді: поточного списку цін, політики повернення товарів, історії замовлень певного клієнта. Цей підхід допомагає у разі відсутності необхідних знань, їх частих змін або якщо ця інформація є приватною для вашої організації. Коли документ оновлюється, змінюються й відповіді моделі, причому не потрібне повторне навчання. Це ідеальний варіант, коли знання належать вам, часто змінюються або потребують посилання. Різниця між тим, що модель запам’ятала у своїх вагах, та тим, що вона шукає під час надання відповіді, детальніше розглядається у статті про те, як відрізняються пам’ять, контекст, ембеддинги та ваги моделі ШІ.
У ситуації з новими співробітниками ви більше не даваєте їм лекцій; ви даєте їм посібник та дозволяєте їм перевірити його перед тим, як вони відповідають. Тепер вони можуть відповідати на запитання щодо змін, які відбулися давно після навчання моделі, та можуть точно вказати, звідки походить кожна відповідь.
Це коштує дорожче, ніж проста корекція запиту. Ви створюєте невелику систему, яка зберігає документи та шукає їх за змістом, що зазвичай вимагає кількох днів роботи, а не хвилин. Це все одно значно дешевше, ніж фін-тюнінг, і система залишається актуальною разом із вашими документами. Крім того, це додає елементи, які потрібно підтримувати: спосіб розділення документів, метод оцінки якості пошуку та те, що відбувається, коли не знаходиться нічого релевантного.
Отримання інформації має свої чіткі межі. Документ заповнює прогалини в знаннях моделі, але не змінює її поведінки. Надання комусь інструкцій не змінює його стилю письма чи суджень. Для цього його потрібно навчати.
Тонке налаштування: відправити на курс навчання
Тонке налаштування — це повторне навчання моделі на багатьох прикладах, поки певний стиль чи навичка не стане автоматичним. Це засіб для досягнення послідовної поведінки, якої не вдається досягти за допомогою простих запитів, або у випадку, коли ваш запит перетворився на сторінку правил і все ще залишається ненадійним. Уявіть собі, що кожна відповідь має дотримуватися дуже конкретного стилю бренду протягом мільйона розмов, без жодних відхилень. Навчання на тисячах прикладів може зробити таку поведінку стандартною, без необхідності додаткових інструкцій.
Найчастіше люди неправильно розуміють наступне: тонке налаштування змінює спосіб функціонування моделі, а не те, що вона знає. Цей процес є повільним та дорогим, вимагає значної кількості прикладних даних, і будь-яка фактична інформація, яку ви вбудуєте, стає застарілою як тільки ці факти змінюються. Тож не варто використовувати його для зберігання фактів — саме для цього існує функція пошуку. Це метод навчання серед трьох варіантів: ефективний, коли проблема справді пов’язана з поведінкою моделі, але марний у випадках, які можна було б вирішити за допомогою чіткіших інструкцій. Щоб дізнатися більше про економічну доцільність цього рішення, перегляньте аналіз витрат на тонке налаштування моделі порівняно з використанням API.
Вибір за симптомами
Почніть з одного запитання: у чому саме проблема з результатом?
- Формат чи тон неправильні, або модель ігнорує частини ваших інструкцій. Це проблема формулювання запиту, тож покращіть його.
- Бракує чи застаріла якась інформація, модель наводить неправильну версію даних, або вам потрібно, щоб вона вказувала джерело. Це проблема знань, тож додайте функцію пошуку інформації.
- Інформація правильна, але поведінка моделі залишається нестабільною незалежно від формулювання запиту, і вам потрібно, щоб вона була надійною у тисячах відповідей. Це проблема поведінки, тож розгляньте можливість фінтюнінгу.
Симптоми визначають спосіб вирішення проблеми. Ще два моменти легко залишити без уваги.
Інструменти діють сумісно, а не конкурують
Майже кожна функція починається з запиту. Багато з них пізніше додають механізм пошуку, коли їм потрібні актуальні чи приватні дані, а менша кількість — налаштування моделі для досягнення поведінки, яку неможливо забезпечити лише за допомогою запиту. Зазвичай ви самі вирішуєте, який етап додати наступним, а не обираєте один підхід на все час. Налаштована модель все одно отримує запит, а система RAG також залежить від інструкцій, які пояснюють моделі, як використовувати знайдені дані.
Йдіть лише настільки, наскільки це необхідно за симптомами
Оскільки варіанти йдуть від дешевих до дорогих у такому порядку, зупиніться на першому, який вирішує проблему. Той самий принцип діє ще до створення чого-небудь: якщо завдання залежить від змінюваних фактів, плануйте використання механізму пошуку; якщо потрібна дуже точна поведінка у великих обсягах, налаштування моделі може зрештою виявитися доцільним; у всіх інших випадках все починається з запиту.
Дорога помилка: налаштування моделі для навчання фактам
Помилка, яку варто чітко вказати, — це спроба використати тонке налаштування, щоб навчити модель щось знати. Це звучить як серйозний, технічно складний варіант, саме тому команди спочатку обирають його. Але факт, який постійно змінюється, не повинен бути частиною звичок моделі; він має знаходитися у документі, який модель може переглядати. Якщо зробити все навпаки, ви можете тижнями навчати модель факту, який вже до моменту запуску знову буде неправильним, без можливості легко показати, звідки походить відповідь.
Ще одна подібна пастка — це тонке налаштування для виправлення насправді нечіткого запиту. Якщо ви ще не пробували чітких інструкцій з форматування та кількох хороших прикладів на фіксованому наборі тестів, ви ще не знаєте, чи взагалі існує проблема з поведінкою моделі.
Ключові висновки
- Діагностуйте перед тим, як витрачати ресурси: з’ясуйте, чи проблема пов’язана з інструкціями, знаннями чи поведінкою.