Навчання на реальному досвіді

Те, як користувачі взаємодіють із нашими продуктами в реальному світі, є цінним джерелом для навчання моделі. Дані є рясними, відображають фактичний розподіл завдань користувачів і фіксують виправлення користувачів і збої інструментів, які синтетичні середовища можуть пропустити.

Поширеним способом навчання на даних реального світу є точне налаштування вибірки відхилень: оцініть результат кожного сеансу, збережіть успішні та навчіть модель наслідувати їх. Але успішний результат не означає, що кожен крок був правильним, тому наслідування всієї траєкторії ризикує підкріпити погану проміжну поведінку на додаток до хороших. Відкидання невдалих сеансів також втрачає критичні свідчення про те, де модель не справляється.

Ми поєднуємо точне налаштування з вибіркою за відхиленням із самодистиляцією на основі підказок, щоб навчатися як на успішних, так і на невдалих сеансах. Підказка — це коротка інструкція з виправлення, що ґрунтується на інформації, яку модель уже мала під час припущення помилки. Корисні кроки з успішних сеансів залишаються цілями для імітації, тоді як обґрунтовані підказки перетворюють уникнені помилки на цілі для виправлення.

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

Під час використання в реальних умовах пізніша донавчена контрольна точка GLM-5.2 скоротила кількість збоїв викликів інструментів на 21,2% порівняно з попередньою контрольною точкою. Для GLM-5.3 донавчання знизило кількість збоїв викликів інструментів на 33,0%, а середню оціночну ймовірність середнього або високого рівня невдоволення користувачів — на 17,2% порівняно зі стандартною моделлю.

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

На відміну від цього, користувачі в сеансах реального світу пропонують різноманітні інструкції, контекст і комбінації інструментів у сеансах, які розгортаються протягом кількох кроків взаємодії. Таке використання в реальному світі природним чином дає два цінні сигнали про помилки: виправлення користувачів показують, де агент не зміг забезпечити те, чого вони хотіли, а помилки інструментів показують, де його дії зламалися в реальному середовищі. Наш конвеєр вибірки поважає конфіденційність користувачів і вибір навчання, виключаючи сеанси з особистою інформацією (PII) та від користувачів, які відмовилися.

Тому дані реального світу дають нам випадки збоїв, які синтетичне середовище може не виявити, і часто вже містять інформацію про те, де стався збій.

Під час навчання на реальних даних стандартне тонке настроювання вибірки відхилень (RFT) вибирає успішні сеанси на основі їхніх кінцевих результатів, без явного використання відгуків користувачів та інструментів для розрізнення хороших проміжних дій від поганих. Агент може відновитися після поганого виклику інструменту або виправити помилку після відгуку користувача і все одно видати правильний результат наприкінці.

Відкидання невдалих сеансів також обмежує ефективність вибірки. Сеанс, який ніколи не досягає хорошого результату, все одно може виявити чітку, уникнуту помилку як корисні сигнали для навчання.

Ми усуваємо ці обмеження, розділяючи два рішення: які сеанси містять поведінку, яку варто наслідувати, і які повороти містять помилки, які варто виправити. Конвеєр даних приймає ці рішення окремо, а потім призначає поворотам моделі один із трьох видів обробки:

Наслідувати: повороти без помилок в успішних сеансах отримують звичайну втрату перехресної ентропії (CE), що підвищує ймовірність записаних токенів.
Правильно: як в успішних, так і в невдалих сеансах повороти помилок із дійсною підказкою отримують втрату дивергенції Кульбака-Леблера (KL), переміщуючи модель до прогнози наступного токена, які вона робить, коли бачить підказку.
Зберігати як контекст: хвости в невдалих сеансах, які не мають підтвердженої підказки, і позначені погані хвости без підтвердженої підказки в будь-якому типі сеансу слугують контекстом, але не отримують жодної втрати.

У результаті успішні сеанси можуть надавати цілі імітації та корекції, тоді як невдалі сеанси надають лише цілі корекції. Усі інші повороти, включаючи системні, користувацькі та вихідні дані інструментів, залишаються контекстом.

Діаграма маршрутизації сеансів: успішні сеанси забезпечують імітацію CE та право на підказані виправлення; невдалі сеанси забезпечують лише право на виправлення. — Поточна маршрутизація сеансів і маски вмісту помічника. Успішні сеанси роблять внесок у цілі імітації; збережені записи відгуків можуть сприяти підказаним виправленням, навіть якщо сеанс є невдалими. Інший вміст залишається контекстом. Незавершені сеанси виключаються. Неостаточний виняток CE для генерації/стоп-токена не намальовано, і ця діаграма не встановлює суміш, яка використовується попередньою контрольною точкою.

Частина імітації використовує стандартний RFT. Корекційна частина використовує самодистиляцію на полі (OPSD): та сама модель діє як вчитель і учень, причому вчителю надається привілейована інформація. Тут ця привілейована інформація є короткою підказкою, що пояснює уникнуту помилку. Ми навчаємо учня відповідати прогнозам наступного токена вчителя без отримання підказки.

Обидві частини мають значення. Навчання лише на основі корекції може виявити скорочений шлях: вчитель і учень можуть погодитися, ігноруючи контекст, замість того, щоб вивчати корекцію. Термін CE закріплює навчання за корисною поведінкою, допомагаючи запобігти згоді, яка виникає через ігнорування контексту.

Додатково навчений учень потім стає варіантом моделі в Computer. Свіжі сеанси з використання в реальному часі проходять через ті самі фільтри відповідності та конфіденційності перед тим, як потрапити в новий цикл конвеєра навчання.

Далі ми розберемо конкретний приклад, який містить і імітацію, і корекцію.

Розглянемо остаточний успішний сеанс, де користувач просить порівняти зміни asyncio в Python 3.13 за допомогою офіційної документації. Документація нашого інструменту зазначає, що search.web повертає список результатів, кожен з полем url.

Спочатку модель виконує дійсний пошук однієї версії як частину збору доказів для порівняння, що є хорошою поведінкою для наслідування.

Однак наступний виклик виконання коду неправильно розглядає цей список як словник. Інструмент коду повертає TypeError: list indices must be integers or slices, not str. Оскільки тип повернення був задокументований до виклику, це помилка, якої модель мала б уникнути. Для виправлення цієї дії можна згенерувати підказку з правильним викликом.

Ілюстративний сеанс кодування: системні та користувацькі дані та помилки інструментів залишаються контекстом; корисні записані виклики пошуку та відновлення отримують CE в успішному сеансі; позначений помилковий пошук списку отримує KL у бік вчителя за наявності обґрунтованої підказки. — Ілюстративний сеанс кодування показує три ролі навчання: вхідні дані лише для контексту та результати інструментів (сірий), імітація CE корисних записаних викликів (темний) і корекція KL помітної помилки (бірюзовий). Тут модель неправильно трактує список результатів пошуку як словник; підказка лише для вчителя, обґрунтована попередньою документацією інструменту, спрямовує виправлення. Цілі CE застосовуються лише тоді, коли завершений сеанс вважається успішним, тоді як невдалий сеанс все одно може надати право на ціль корекції KL.

Конвеєр навчання має чотири етапи: вибір сеансів і оцінка їхніх результатів, визначення помилок і створення підказок на основі відгуків користувачів і помилок інструментів, генерація ймовірностей наступного токена як від учителя, так і від учня, а також навчання моделі зі змішаною втратою CE та KL.

Конвеєр вибірки бере підмножину реальних сеансів Computer, придатних для навчання, які обслуговує GLM 5.2. Відмови від участі в навчанні та пов’язані з PII виключення конвеєра застосовують до вибору прикладів для цього робочого процесу.

Початковий процес скринінгу вибирає кандидатів із оцінками 4 або 5 за п’ятибальною шкалою складності завдань суддею LLM і поділяє їх на 2 групи:

Група відгуків користувачів містить сеанси зі справжнім подальшим запитом користувача або прапорцем середнього чи високого невдоволення. Ми вважаємо ці подальші запити з високим наміром особливо корисними для навчання: користувачі активно намагаються виконати завдання, а їхні виправлення визначають те, що пропустила модель.
Група помилок інструментів містить сеанси зі збоями викликів, позначеними перевірками на основі правил, за винятком визнаних збоїв інфраструктури та відхиленої авторизації.

Два судді LLM потім оцінюють остаточний результат щодо запиту користувача; обидва судді мають повернути позитивний вердикт, щоб позначити сеанс як «успішний». Для випадків, які надають артефакти, етап результатів може реконструювати та перевірити доставлене, повертаючись до своїх текстових оцінок у разі збою цього етапу. Сеанси, класифіковані як незавершені, наприклад робота, що очікує на користувача, виключаються.

Цей крок визначає потенційні джерела сигналів для навчання; однак не кожна помилка походить від моделі, оскільки деякі виникають через двозначні інструкції або збої інфраструктури. Пізніше анотування визначає, які можливі помилки насправді можна уникнути та підходять для навчання.

Розглянемо вибірковий сеанс у групі відгуків користувачів, де користувач запитує: «How do I find my w3 on paychex». Модель трактує «w3» як помилку друку для W-2, шукає інструкції щодо W-2 та пояснює, як знайти цю форму. Наступне питання користувача: «I meant the W-3 transmittal form», визначає помилку, навіть якщо сеанс зрештою виявляється успішним.

Скарга допомагає знайти помилку, але першопричиною є попереднє рішення інтерпретувати «w3» як W-2. Початковий запит робить помилку уникненням: модель могла зберегти W-3 або попросити про пояснення. Виявляється, що останній поворот помічника перед скаргою є першопричиною лише приблизно в половині випадків.

Наш конвеєр анотацій систематично зіставляє причину та наслідок у кожному сеансі відгуків користувачів. Спочатку анотатор перевіряє наявність пропущеної вимоги або наміру, підтриманого попереднім контекстом. Потім три судді LLM визначають відповідальні повороти, вимагаючи принаймні двоє з них погодитися щодо певного повороту. Іноді попередня заява прямо встановлює вимогу. В інших випадках жодна попередня заява сама по собі не робить цього, але кілька частин попередньої розмови разом роблять призначену поведінку виведеною. Ця конструкція дозволяє їм зв’язати скаргу з попередньою кореневою помилкою замість того, щоб приписувати її виключно останній відповіді.

Перш ніж прийняти підказку, конвеєр також перевіряє, чи її виправні твердження випливають з інформації, доступної до позначеного повороту. Ці перевірки призначені для зменшення упередженості заднього числа, коли нова перевага, виявлена в скарзі, розглядається як те, що модель уже мала знати.

У цьому прикладі підказка говорить моделі шукати передавальну форму W-3 на Paychex, а не W-2, або запитати, яку форму має на увазі користувач, якщо запит є двозначним. Корекція націлена на попереднє рішення щодо інтерпретації та пошуку, а не лише на остаточну відповідь. Початковий поворот залишається незмінним; анотація додає is_bad_turn: true та непорожню hint.

Запит W-3 хибно інтерпретується як W-2; пізніша скарга відстежується до попереднього рішення пошуку та перевіряється на основі попередніх доказів. — Реальний сеанс, що показує, як скарга простежується до попередньої помилки з накладеною процедурою анотації. Користувач попросив «w3» на Paychex, але модель сприйняла це як одпечатку для W-2 і почала шукати не ту форму. Консенсус пропозиторів визначає першопричину, тоді як дві перевірки обґрунтованості оцінюють, чи є докази передумовою помилки та чи випливають твердження підказки з інформації, доступної в цей момент. Прийняті анотації зберігають оригінальний текст і додають позначки та підказки, а не переписані цілі.

Розглянемо ще один сеанс у групі помилок інструментів із викликом пошуку, де агент виконує пошук за допомогою recency_filter: "year", але інструмент відхиляє його, оскільки дозволеними значеннями є «day», «week» або «month». Це явне порушення схеми.

Шлях помилок інструменту використовує детерміновані правила для відомих помилок та судження моделі для випадків неоднозначності. Лише повідомлення про помилку також недостатньо, щоб звинуватити модель; винесене виправлення має вказувати на щось, що модель могла знати зі схеми інструменту, інструкцій системи чи попередньої розмови.

Виклик пошуку використовує недійсне значення recency_filter року; обґрунтована підказка доручає моделі використовувати перелічене значення або опустити необов'язкове поле. — Недійсний аргумент пошуку у звіті ілюструє поточну процедуру помилок інструментів. Схема робить цю помилку уникненню; сам по собі збій не був би таким. Початковий виклик залишається в записі та отримує обґрунтовану підказку. Підказка дозволяє перелічене значення або пропуск, якщо поле є необов'язковим; вона не вимагає «month» для кожного запиту.

Тут підказка містить назву невдалиго виклику, помилку перевірки та доручає моделі використовувати дозволене значення або опустити поле, якщо воно є необов’язковим.

Щойно репліку позначено, тренер запускає ту саму контрольну точку двічі: один раз як вчитель і один раз як учень. Вчитель бачить підказку, а учень — ні.

Обидва проходження використовують примус вчителя, коли ми передаємо моделі записаний сеанс замість того, щоб дозволити їй вибирати нові токени. Пряме проходження все ще створює повний розподіл наступних токенів на кожному кроці, але він завжди обумовлений фіксованим префіксом із запису, а не токенами розгортання.

Для прикладу пошуку та сама модель призначає набагато вищу ймовірність для «month» (місяць) і меншу для «year» (рік), коли надано підказку. Навчання використовує цей розподільчий зсув як м’яку ціль.

Та сама модель оцінює зареєстрований поворот з підказкою та без неї; ймовірності відокремленого вчителя надають цілі KL, тоді як CE закріплює імітацію. — Два проходження, один набір ваг. Обидва проходження оцінюють записане продовження; лише вчитель отримує підказки. Його відокремлені ймовірності наступного токена керують учнем через прямий KL. Окремі цілі CE закріплюють імітацію. Обидві втрати живлять одне оновлення ваги. Попередні підказки можуть залишатися в поточному сегменті вчителя; жодне проходження не генерує заміну навчальної відповіді.

Прогнози вчителя відокремлені або мають зупинений градієнт: вони надають ціль, але не отримують оновлення через прохід вчителя. Після проходу учня один крок оптимізатора оновлює спільну модель.

Втрата CE розглядає записані токени, вибрані для імітації, як цілі наземної істини та карає модель за присвоєння їм низьких ймовірностей. Це створює жорстку ціль імітації.

У позиції токена $i$ нехай $p_i(v)$ буде ймовірністю токена учня $v$ у повному словнику $V$ . Записаним наступним токеном у відповіді чи виклику інструмента є $y_i$ , одноелементний цільовий розподіл дорівнює $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

Перехресна ентропія вимірює, наскільки добре учень передбачає цей записаний токен. З одноелементною ціллю вона зводиться до від’ємного логарифма ймовірності, призначеного $y_i$ .

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

Маска CE $m_i^{\mathrm{CE}}$ є $1$ там, де токен слід імітувати, і $0$ в іншому випадку. Підсумовування вибраних позицій дає втрату імітації.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

Втрата KL натомість використовує повний розподіл ймовірностей наступного токена вчителя $q_i$ як м’яку ціль корекції. Контекст вчителя включає поточну підказку та будь-які попередні підказки, збережені в цьому сегменті навчання; контекст учня завжди не містить підказок.

Маска KL $m_i^{\mathrm{KL}}$ є $1$ там, де токен слід виправити, і $0$ в іншому випадку; маски CE та KL не перетинаються. У цих позиціях прямий KL карає розбіжність між учителем та учнем у всьому словнику:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Обидва члени мають один знаменник замість окремої нормалізації. Цей знаменник підраховує загальну кількість токенів, вибраних для імітації в глобальному навчальному пакеті. Вага $\lambda$ керує внеском корекційного навчання відносно імітації.

Ця спільна нормалізація відповідає інтерфейсу з єдиним знаменником нашої інфраструктури навчання та відновлює стандартну втрату SFT під час $\lambda=0$ , спрощуючи порівняння базових показників. Оскільки токени CE набагато рясніші, ніж токени KL, використання спільного знаменника також дозволяє уникнути присвоєння окремим токенам KL непропорційно великої ваги в пакетів із кількома позначеними токенами.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Застосовуючись до попередніх прикладів, повороти, що містять змішування W-3/W-2 та недійсний виклик пошуку, отримують KL. Інший немаркований вміст помічника в успішному сеансі все ще отримує CE. Інший вміст помічника в невдалих сеансах зберігається як контекст, але не отримує ні CE, ні KL.

Наші оцінки дають відповіді на два окремі питання. По-перше, чи дійсно підказка допомагає моделі виправити помилку, коли вона присутня? По-друге, чи допомагає навчання моделі уникнути цієї помилки пізніше без підказки? Перше перевіряє, чи надають підказки корисні сигнали для навчання. Друге перевіряє, чи вчиться модель на них.

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

Ми відтворили позначені повороти відгуків користувачів з підказкою та без неї, використовуючи ту саму базову модель GLM-5.2 за нульової температури. Сліпий суддя бачить пізнішу скаргу, але ані підказку, ані умову, яка призвела до відповіді.

У прикладі W-3 підказка зміщує ймовірність наступного токена до «3» і від «2» після префікса «W-».

Ймовірності наступного токена після W- зміщуються в бік 3, а не 2, коли незмінна базова модель отримує підказку. — Підказка зберігає запитувану форму W-3. Стовпчики показують середні ймовірності наступного токена за вісім прямих проходів; вуса показують спостережуваний діапазон, а не інтервал довіри. В обох умовах використовується незмінна базова модель.

У більшій вибірці з 40 поворотів, що залишилися, підкріпленій чітко викладеними попередніми доказами, частка оцінених як виправлені або на правильному шляху зростає з 40,0% без підказки до 75,0% з нею. На інших 40 поворотах, підтриманих виведеним наміром, він зростає з 32,5% до 80,0%.

Перевірка підказок: фіксовані показники або показники на шляху зростають з 40,0% до 75,0% для чітких доказів і з 32,5% до 80,0% для виведених намірів. — Перевірка підказок, а не оцінювання після навчання. Ті самі 40 позначених поворотів у кожній групі доказів відтворюються з підказкою та без неї за допомогою незмінної GLM-5.2 за нульової температури. Суддя бачить скаргу, але не підказку чи умову. Кількість виведено з показників звіту та розмірів вибірки; довірчі інтервали не повідомляються.

У прикладі помилки інструмента пошуку підказка дійсно переносить масу ймовірності з токена року на токен місяця.

Підказка зміщує ймовірності наступного токена незмінної базової моделі від року до дозволеного значення місяця. — Підказка зміщує ймовірність у бік дозволеного значення. Стовпчики показують середні ймовірності наступного токена за вісім прямих проходів; вуса показують спостережуваний діапазон, а не інтервал довіри. Обидві умови використовують ту саму базову модель; порівняння навченої контрольної точки не проводиться.

У більшій вибірці з 985 відкладених поворотів ми відтворюємо кожен поворот чотири рази з підказкою та без неї, використовуючи ту саму базову модель. Сліпий суддя оцінює, чи кожне відтворення дозволяє уникнути початкового збою. Підказки підвищують уникнення збоїв з 75,1% до 93,7%, що є парним приростом на 18,6 відсоткових пункти, і збільшують частку виконання виправленої дії з 60,6% до 82,3%. Приріст є найбільшим для помилок, які лише повторна вибірка намагається виправити.

На 985 ізольованих позначених поворотах помилок інструментів підказки підвищують уникнення збоїв з 75,1% до 93,7%, а показники виправлених дій – з 60,6% до 82,3%. — Перевірка підказок щодо помилок інструментів на 985 ізольованих позначених поворотах із чотирма регенераціями на умову. Стовпчики показують показники уникнення збоїв та виправлених дій для незмінної базової моделі з підказками та без них. Уникнення цільової помилки не гарантує успіху виклику інструмента чи завдання.

Далі ми перевіряємо, чи робить навчена модель менше помилок без підказок. Ми оцінюємо базову модель і різні контрольні точки після навчання на офлайн-бенчмарк-завданнях і в живих сеансах користувачів, перевіряючи, чи стає менше збоїв інструментів і чи зменшується незадоволеність користувачів.

Офлайн-оцінювання використовує BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, репрезентативний набір завдань Computer і перевіряє на завантаження навичок, огляд документів та вбудовані цитування. Ми вимірюємо частку викликів інструментів, результати яких явно позначені як помилки на траєкторіях оцінювання.

У цих оцінках зареєстрований показник помилок інструментів становив 2,79% для стокової GLM 5.2, 1,35% для контрольної точки лише з RFT та 0,87% для контрольної точки RFT-plus-OPSD. Ці контрольні точки навчалися на різних даних, тому це не абляція OPSD на основі відповідних даних. Результати бенчмарків на рівні завдань були неоднозначними, тому менша кількість помилок інструментів сама по собі не обов’язково перетворюється на широке покращення успіху завдань.

Офлайн-показники помилок інструментів, які записано: 2,79% для стокової GLM 5.2, 1,35% для RFT-only та 0,87% для RFT plus OPSD; дані навчання відрізняються. — Офлайн-показники помилок інструментів для контрольних точок stock GLM-5.2, RFT-only та RFT-plus-OPSD. Дані навчання відрізняються для різних контрольних точок; це не контрольоване видалення.

Для GLM-5.2 ми провели два окремі A/B-тести за участю близько ста тисяч користувачів у кожній умові. У першому тесті рання контрольна точка RFT-plus-OPSD мала дещо нижчу частоту збоїв інструментів, ніж звичайна GLM 5.2 (2,82% проти 2,94%), проте різниця не була статистично значущою.

У пізнішому тесті ми порівняли дві контрольні точки RFT-plus-OPSD: більш ранню (контрольна точка один) і пізнішу (контрольна точка два). Збої викликів інструментів впали з 2,24% до 1,77% викликів із записаним статусом. Це було статистично значуще відносне зниження на 21,2%. Ми не порівнювали контрольну точку два безпосередньо зі стандартною GLM 5.2 в Інтернеті.

Результати відгуків користувачів виявилися менш переконливими. У другому експерименті з GLM-5.2 середня ймовірність сильного невдоволення (середнього або високого) становила 2,58% для першої контрольної точки та 2,54% для другої, без статистично значущої різниці.

Два окремі онлайнові тестування A/B; лише пізніше порівняння контрольних точок має значне зниження збоїв інструментів без значної зміни невдоволення MID+. — Два окремих живих A/B-тести GLM-5.2. Контрольна точка 1 порівнюється зі звичайною моделлю GLM-5.2; контрольна точка 2 — з контрольною точкою 1. Серед цих двох тестів лише пізніше зниження частоти збоїв інструментів є статистично значущим. Показники MID+ є середніми оціночними ймовірностями середнього або високого рівня незадоволеності, а не кількістю скарг.

Для GLM-5.3 ми порівняли донавчену контрольну точку безпосередньо зі стандартною GLM-5.3. Кількість збоїв викликів інструментів зменшилася з 3,56% до 2,38% від загальної кількості викликів із зафіксованим статусом, що становить відносне скорочення на 33,04%. Показник MID+, тобто середня оціночна ймовірність середнього або високого рівня невдоволення, знизився з 4,12% до 3,41%, що означає відносне скорочення на 17,2%. Обидва скорочення є статистично значущими.

A/B тестування GLM-5.3: частота збоїв інструментів знижується з 3,56% до 2,38%, а показник MID+ (середня оціночна ймовірність середнього або високого рівня невдоволення) — з 4,12% до 3,41%. Відносні скорочення з поправкою CUPED становлять відповідно 33,04% та 17,16%. Обидва 95% послідовні інтервали не містять нуля; основна метрика залученості є незначущою. — Порівняння донавченої GLM-5.3 зі стандартною GLM-5.3 в окремому онлайн A/B тесті. Частота збоїв інструментів і показник MID+, відносні зміни та 95% послідовні довірчі інтервали розраховано з поправкою CUPED. Обидва скорочення є статистично значущими. Показник MID+ є середньою оціночною ймовірністю середнього або високого рівня невдоволення для відповідних оцінених гілок обговорення, а не кількістю скарг. Частота збоїв інструментів не включає виклики без зафіксованого статусу успіху чи збою.

Центральна ідея полягає в тому, щоб вчитися на рівні рішення, а не лише сеансу.

Успішний результат може приховувати помилки, а невдалий сеанс усе одно може показати, як удосконалитися. Ми зберігаємо корисну поведінку з успішних сеансів як якір, використовуємо скарги та помилки інструментів для виявлення уникнутих збоїв та спрямовуємо модель на прогнози, які вона робить, коли ці помилки та виправлення стають явними. Успіх забезпечує поведінку, яку слід зберегти; невдача забезпечує напрямок для вдосконалення.

Використання в реальному світі робить цей підхід особливо корисним. Реальні користувачі приносять цілі, обмеження та робочі процеси, які важко передбачити в синтетичному середовищі. Їхні виправлення виявляють вимоги, які пропустила модель, тоді як помилки інструментів оголюють розриви між тим, що намагалася зробити модель, і тим, що дозволяє середовище. Ці сигнали доповнюють навчання на основі результатів: замість того, щоб запитувати лише про те, чи завершилося завдання успіхом, ми можемо запитати, де модель помилилася і яка інформація могла допомогти їй прийняти краще рішення.

Обмеження мають таке ж значення. Експерти можуть помилятися, а виправлення однієї репліки не гарантує успішного виконання всього завдання. Мета полягає не лише в тому, щоб створити агент, який відновлюється після виправлення. Потрібен агент, якому рідше потрібні виправлення.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

Від синтетичних до реальних даних

Наслідуйте хороші кроки, виправляйте погані

Приклад: один сеанс може навчити обом урокам

Як працює навчання

Виберіть сеанси, а потім оцініть результат

Знайти помилки за відгуками користувачів

Знайти помилки за помилками інструментів

Два прямі проходження

Функція втрат

Втрата CE

Втрата KL

Комбінована втрата

Що показують оцінки

Підказки можуть відвернути модель від помилок

Відгуки користувачів

Помилки інструментів

Надійність інструментів і відгуки користувачів після навчання

Офлайн-оцінювання

Онлайн-оцінювання: GLM-5.2

Онлайн-оцінювання: GLM-5.3

Висновок

Цитування