Штучний інтелект дедалі глибше заходить у бізнес‑процеси, документообіг і розробку ПЗ, але питання довіри до його результатів залишається відкритим. В одному з епізодів подкасту Mixture of Experts від IBM Technology, який веде Тім Хван, команда експертів — дослідниця Марина Данилевська, архітектор AI Open Innovation Ґейб Гудгарт та інженер Кріс Гей — обговорює нове дослідження Microsoft із промовистою назвою: «LLMs Corrupt Your Documents When You Delegate».
Ця робота пропонує не просто ще одну цифру точності моделей, а новий спосіб дивитися на те, що відбувається з даними, коли ми «делегуємо» LLM довгі, багатокрокові завдання. І висновки тут значно тривожніші, ніж звичні історії про «галюцинації» в чат‑ботах.
Delegate‑52: як виміряти, що відбувається з даними в довгих ланцюжках
Microsoft у своєму дослідженні пропонує бенчмарк Delegate‑52 — набір сценаріїв, які моделюють довгі делеговані робочі процеси. Ідея проста: замість одноразового запиту до моделі, як у звичайному чаті, моделюється реалістичний робочий ланцюжок, де модель крок за кроком переписує, узагальнює, переформатовує й доповнює документи.
Це ближче до того, як LLM уже починають використовувати в компаніях: як «агентів», що обробляють великі масиви тексту, мігрують контент між системами, готують звіти, перетворюють формат документації чи коду. Саме в таких сценаріях бізнес часто сподівається на майже «роботизовану» точність: якщо завдання звучить як «скопіюй», «перенеси», «переформатуй», то очікування — що зміст залишиться недоторканим.
Delegate‑52 якраз і перевіряє, що реально відбувається з вмістом документів, коли ми дозволяємо моделі крок за кроком «вести» їх через складний процес. Це не тест на красномовність чи креативність, а тест на збереження інформації.
Результат: навіть найкращі на сьогодні «фронтирні» моделі до кінця таких ланцюжків у середньому псують близько 25% вмісту документа. Чверть інформації — змінена, втрачена або спотворена. Для систем, де важлива точність — від юридичних контрактів до технічної документації — це не просто похибка, а фундаментальний ризик.
Галюцинації проти втрат: як різні моделі псують дані по‑різному
Один із найцікавіших висновків дослідження — те, що різні класи моделей псують документи по‑різному.
Фронтирні моделі, тобто найпотужніші сучасні LLM, схильні «галюцинувати» зміни. Вони не просто щось втрачають, а активно вигадують нові фрагменти, переформульовують, додають деталі, яких не було в оригіналі. Це логічне продовження їхньої сили: вони добре вміють узагальнювати, домислювати, заповнювати прогалини. Але там, де потрібна точна передача змісту, ця ж здатність перетворюється на джерело корупції даних.
Менші, нефронтирні моделі, навпаки, частіше просто «скидають» контент. Вони втрачають шматки тексту, пропускають деталі, не переносять частину інформації далі по ланцюжку. З погляду безпеки це інший тип ризику: замість вигаданих фактів — тиха втрата важливих елементів.
Для практики це означає, що немає «безпечної» моделі, яку можна просто поставити в центр довгого робочого процесу й забути. Потужніші моделі можуть непомітно змінювати сенс, слабші — непомітно його обрізати. В обох випадках фінальний документ уже не є тим, що було на вході.
Це ставить під сумнів популярну нині ідею «агентів», яким можна віддати на відкуп цілі бізнес‑процеси: від обробки заявок до складання звітів. Якщо навіть у контрольованому бенчмарку в середньому псується чверть вмісту, то в реальних, ще більш заплутаних сценаріях ризики лише зростають.
Неправильний патерн: чому LLM не можна сприймати як детермінований конвеєр
У дискусії навколо дослідження Microsoft експерти наголошують: головна помилка — це ставитися до LLM як до інструменту для детермінованих перетворень даних без подальшої перевірки.
Поширений сценарій сьогодні виглядає так: компанія хоче автоматизувати рутинні завдання — наприклад, міграцію контенту між системами, уніфікацію форматів, генерацію шаблонних документів. LLM отримує інструкцію «перепиши це в такий‑то формат» або «витягни такі‑то поля й склади новий документ». Далі результат автоматично потрапляє в продакшн‑систему.
Такий підхід передбачає, що модель поводиться як детермінований конвеєр: на однакове завдання дає однаковий, передбачуваний результат, не змінюючи змісту, якщо її про це прямо не просять. Delegate‑52 показує, що це хибне припущення.
Ґейб Гудгарт формулює принцип, який варто було б написати над кожним проєктом з інтеграцією LLM: детерміновані задачі мають вирішуватися детермінованими інструментами. Моделі великої мови — це статистичні системи, що генерують правдоподібний текст, а не механізми точного копіювання.
Там, де потрібна гарантована відповідність вхідних і вихідних даних — від фінансових розрахунків до юридичних форм — покладатися на LLM як на «копіювальний апарат» означає вбудовувати у процес випадкову помилку. І чим довший ланцюжок делегованих кроків, тим більше ця помилка накопичується.
Звідси й ключова теза: LLM краще підходять для задач, де система в цілому є відмовостійкою до помилок. Наприклад, для генерації чернеток текстів, варіантів дизайну, ідей для коду, які потім обов’язково проходять людський чи автоматизований аудит. Там, де помилка не є фатальною, а результат все одно переглядається й коригується.
Довгий контекст не рятує: чому потрібні бенчмарки на кшталт Delegate‑52
Одна з популярних відповідей індустрії на проблему надійності — збільшення контекстного вікна. Мовляв, якщо модель «бачить» більше тексту, вона краще розуміє завдання і менше помиляється.
Однак обговорення дослідження Microsoft підкреслює: довгий контекст сам по собі не вирішує проблему корупції даних у багатокрокових процесах. Навіть якщо модель може одночасно «тримати в голові» величезний документ, це не означає, що вона не буде його спотворювати, коли її просять щось переформулювати, узагальнити чи розбити на частини.
Delegate‑52 цінний саме тим, що фокусується не на разовій взаємодії, а на ланцюжку кроків. У реальних системах LLM рідко працює в ізоляції: її відповіді стають вхідними даними для наступних викликів моделі, для інших сервісів, для людей. Помилка на одному кроці може бути непомітною, але через десяток ітерацій вона перетворюється на суттєву корупцію вмісту.
Тому індустрії потрібні саме такі бенчмарки — які вимірюють не лише «розумність» моделі в окремому діалозі, а й її поведінку в довгих робочих процесах. Це змінює й підхід до оцінки моделей: важливо не тільки, наскільки добре вони відповідають на складні питання, а й наскільки стабільно зберігають інформацію, коли їх використовують як частину конвеєра.
Для розробників продуктів це означає, що «довгий контекст» не може бути виправданням для відсутності контролю. Навіть якщо модель здатна оперувати сотнями сторінок тексту, її результати в багатокрокових сценаріях мають проходити додаткові перевірки.
Верифікаційні петлі та контроль версій: як будувати безпечніші AI‑процеси
Якщо LLM не можна сприймати як детермінований механізм, постає питання: як тоді безпечно інтегрувати їх у робочі процеси, де важлива точність?
У дискусії навколо Delegate‑52 звучить кілька принципів, які поступово стають новим «золотим стандартом» для проєктування AI‑систем.
По‑перше, потрібні верифікаційні петлі. Це означає, що результат роботи моделі не повинен автоматично вважатися істинним і переходити далі по ланцюжку без перевірки. Перевірка може бути людською — коли експерт переглядає й затверджує зміни, — або автоматизованою, коли інша система (можливо, інша модель) порівнює вхід і вихід, шукає розбіжності, перевіряє інваріанти.
По‑друге, критично важливий контроль версій для всього, що генерує або змінює AI — від документів до коду. Якщо модель переписує технічну документацію чи вносить правки в репозиторій, має бути чітко видно, що саме змінилося, коли й за якої підказки. Це дозволяє не лише відкотити невдалу зміну, а й аналізувати системні помилки: які типи завдань найчастіше призводять до корупції даних.
По‑третє, варто чітко розділяти задачі, де LLM виступає як «співавтор», і задачі, де від нього чекають точного перенесення інформації. У першому випадку модель може вільно пропонувати варіанти, переформульовувати, узагальнювати — але людина або інша система приймає остаточне рішення. У другому випадку краще покладатися на класичні, детерміновані інструменти: парсери, трансформери форматів, строго типізовані пайплайни.
Цікаво, що ці принципи перегукуються з порадами, які Гудгарт дає молодим фахівцям щодо особистого використання AI: використовувати моделі як «співрозмовника» й «партнера з роздумів», а не як повноцінного виконавця, якому можна бездумно делегувати завдання. На рівні індивідуального користувача це означає: AI допомагає думати, але не приймає рішень замість вас. На рівні систем — AI допомагає генерувати варіанти, але не змінює критичні дані без контролю.
Висновок: AI як інструмент, а не невидимий співробітник
Дослідження Microsoft із Delegate‑52 та дискусія навколо нього показують: головна загроза від LLM у бізнес‑процесах сьогодні — не в тому, що вони «захоплять роботу», а в тому, що їх занадто легко сприйняти як надійних, передбачуваних виконавців.
Коли моделі вбудовують у довгі ланцюжки обробки документів чи коду без верифікації й контролю версій, вони стають джерелом повільної, але системної корупції даних. І чим потужніша модель, тим витонченішими можуть бути ці спотворення: не просто втрати, а переконливі, але вигадані зміни.
Вихід — не в тому, щоб відмовитися від LLM, а в тому, щоб чітко визначити їхню роль. Це інструменти для задач, де допустима помилка й де результат все одно проходить перевірку. Це потужні «співрозмовники» й генератори варіантів, але погані «копіювальні апарати» й ненадійні «невидимі співробітники», яким можна мовчки делегувати критичні процеси.
Delegate‑52 — це нагадування, що ера «агентів», які самостійно ведуть документи через складні робочі процеси, вимагає не лише кращих моделей, а й кращої інженерії навколо них: верифікаційних петель, прозорого контролю версій і тверезого розуміння, де детерміновані задачі мають залишатися у світі детермінованих інструментів.