Вибір між RAG і донавчанням залежить від того, що має робити ваш асистент. RAG, скорочення від retrieval-augmented generation, надає відповідний джерельний матеріал, коли модель відповідає; донавчання означає подальше навчання моделі на прикладах. Почніть із тестування чіткої інструкції до завдання, тобто промпту. Потім використайте результат, щоб вирішити, чи досліджувати брак джерельного матеріалу, непослідовність результатів або обидві проблеми, перш ніж замовляти додаткову роботу.
Один постачальник пропонує навчити систему ШІ для вашого бізнесу, а інший пропонує базу знань із можливістю пошуку. Ці описи не визначають завдання, яке має виконувати готова система, або те, який результат вважатиметься невдалим. Ми починаємо з письмового опису цього завдання. Воно дає вам конкретну основу для порівняння отриманих пропозицій.
Що змінює вибір RAG чи донавчання?
RAG змінює матеріал, який надається для відповіді; донавчання змінює модель шляхом навчання. Посібник OpenAI з точності відрізняє брак контексту від непослідовної поведінки. Це корисне початкове розрізнення для покупця, якщо залишити місце для потреб, що перетинаються. Асистенту, який працює з документами, також може знадобитися послідовний спосіб формулювання відповіді.
Згідно з поясненням баз знань Amazon Bedrock, пошук вибирає відповідний матеріал і додає його до вхідних даних для генерування. Для запропонованого асистента, що відповідає на запитання про правила повернення, попросіть показати, який затверджений уривок підтверджує відповідь. Посилання на джерело все одно потрібно звірити з тим, що сказано у відповіді.
Донавчання використовує приклади для подальшого навчання моделі тому, як відповідати. Посібник OpenAI описує його як один із варіантів покращення поведінки під час виконання завдання. Уявіть потрібну нотатку для передавання справи з узгодженою структурою: постачальнику потрібні приклади прийнятних нотаток і вхідні дані, використані для їх створення. Це інший результат, ніж папка з документами про правила.
Жодна з цих назв не показує, чи відповідає демонстрація вашим вимогам. Попросіть постачальника визначити, що змінює запропонований компонент, показати матеріал, який він використовує, і пояснити, як ви перевірятимете результат. Пов’язуйте обговорення з фактичною роботою, яку ви купуєте.
Почніть із завдання та простішої демонстрації
Опишіть вхідні дані й прийнятний результат, перш ніж вибирати підхід. Посібник Anthropic зі створення промптів починається з чітких критеріїв успіху, тесту з прикладами та чернетки промпту. Ми використовуємо цю послідовність для підготовки специфікації на закупівлю: записуємо інструкцію, надаємо затверджений матеріал і перевіряємо, що може зробити найпростіша запропонована конфігурація. Це запропонований нами метод оцінювання, а не опублікований бенчмарк.
Для умовного асистента з повернень вхідними даними можуть бути запитання клієнта й відповідні правила. Прийнятна чернетка відповідає лише в межах того, що підтверджують ці правила, а винятки передає людині. Для умовного передавання справи відділу продажів вхідними даними можуть бути запит і затверджений формат нотатки. Результат має зберігати зміст запиту й залишати відсутні відомості незаповненими.
Попросіть власника процесу записати, що робить кожен результат прийнятним. Додайте запит, який асистент має відхилити або передати людині. Використовуйте матеріал, яким вам дозволено ділитися, вилучивши зайві персональні дані. Демонстрація, яка залежить від інформації, якої ви не можете надати, ще не є здійсненною пропозицією.
Якщо у вас уже є асистент, який дає ненадійні відповіді, скористайтеся окремим посібником про перевірку причин неправильних відповідей ШІ, перш ніж вирішувати, що замовляти.
Оберіть наступний тест за прогалиною, що залишилася
Використовуйте виявлений збій, щоб вибрати наступний тест. AWS рекомендує починати з пошуку для запитань, що посилаються на власні документи, і звертає увагу на складність узгодження навчання з матеріалом, який часто змінюється. Також допускається спільне використання пошуку й донавчання. У таблиці нижче запропоновано наступний тест для прогалини, виявленої під час демонстрації.
| Чого все ще бракує демонстрації | Що тестувати далі |
|---|---|
| Інформації із затверджених документів, що змінюються | Пошук, який надає відповідний поточний матеріал |
| Повторюваного результату, який залишається непослідовним після чіткіших інструкцій і прикладів | Навчання на прийнятих прикладах, якщо вибрана модель його підтримує |
| Джерельного матеріалу й послідовнішої відповіді | Комбінована конфігурація з перевіркою кожної вимоги |
Якщо простіша демонстрація вже відповідає вимогам, залиште цей варіант у порівнянні. Запитайте, яку додаткову проблему розв’яже запропоноване навчання або система пошуку. Вибір також може залишатися відкритим, поки ви готуєте відсутні вхідні дані.
AWS зазначає, що донавчання доступне не для кожної моделі. Попросіть постачальника назвати провайдера й модель, пояснити, де і як працюватиме система, а також підтвердити поточну підтримку запропонованого навчання та розгортання.
Хто підтримує систему після запуску?
Порівняйте обов’язки, які кожна пропозиція залишає вашій команді. Для пошуку визначте особу, яка затверджує джерельні документи й перевіряє, чи доходять оновлення до асистента. Для навчання визначте, хто готує прийняті приклади й переглядає подальші зміни. Запишіть, хто надає доступ, хто опрацьовує збої та як працівники повертають завдання до ручного процесу, коли система непридатна.
Ми додаємо ці запитання до планування впровадження ШІ, перш ніж вибирати компоненти. Корисна специфікація містить:
- Завдання, дозволені вхідні дані й очікуваний результат.
- Авторитетні джерела, їхнього власника та процес оновлення.
- Приклади прийнятної роботи й неприйнятних пропусків або доповнень.
- Умови для відхилення запиту або передавання його людині.
- Приймальні перевірки, відповідального за перевірку й матеріал для передавання.
Для роботи з активним замовленням або записом контакту запитайте, як запропонована система отримуватиме дозволений поточний запис. Додайте цю вимогу до частини специфікації про інтеграцію CRM. Пропозиція навчити систему на експортованих записах усе одно потребує пояснення, як оброблятимуться подальші зміни.
Запитайте, де зберігатимуться документи, придатні до пошуку копії, приклади та результати, хто матиме до них доступ і як відбуватиметься видалення. Запишіть відповіді для фактичного розгортання. Не сприймайте назву будь-якої архітектури як рішення щодо хостингу чи дозволів.
Перевірте пропозицію на запитах, яких система раніше не бачила
Не включайте тестові запити до матеріалів, використаних для налаштування чи навчання запропонованої системи. Попросіть кожного постачальника виконати ці запити за однаковими критеріями приймання. Нехай власник процесу перевірить результати, вхідні дані, використані для їх створення, і потрібні виправлення. Це перевіряє пропозицію на вашому завданні, але не доводить її ефективності для кожного майбутнього запиту.
- Збережіть базовий рівень. Збережіть результати ручного процесу та простішого промпту разом із вхідними даними й примітками перевірки.
- Перевірте оновлення джерела. Змініть затверджений тестовий документ і повторіть відповідне запитання. Попросіть постачальника показати, яку версію було використано і як оновлення потрапило до асистента.
- Перевірте правила результату. Перефразуйте запит і залиште частину інформації невказаною. Перевірте, чи зберігає нотатка потрібну структуру, не вигадуючи деталей.
- Перевірте доступ і межі. Спробуйте запит поза узгодженими межами та користувача, який не повинен отримувати документ з обмеженим доступом. Перевірте фактичну відмову або передавання.
- Запишіть роботу, яку ваша команда має й надалі виконувати. Занотуйте виправлення, час на перевірку й відповідального за підтримку матеріалів. Порівняйте це з базовим рівнем, перш ніж розширювати роботу.
Якщо перевірка не пройдена, запишіть невиконану вимогу й попросіть провести оновлену демонстрацію. Не платіть за складніший підхід лише тому, що його назва звучить потужніше. Прийміть обсяг, який можете перевірити, або залиште завдання людям, поки не буде виконано відсутні умови.
Як ми можемо допомогти
Ми починаємо зі спільного опису завдання, дозволених даних і приймальних перевірок. Потім порівнюємо запропоновані підходи з цією специфікацією та документуємо, хто підтримуватиме джерела, приклади й оцінювання. Корисний перший крок полягає в тому, щоб записати реальний запит і затвердити приклад потрібного результату.
