LLM-First чи Code-First? Де місце інтелекту в ШІ у промисловій експлуатації

Як вирішити, що має обробляти модель, що має обробляти ваш код і як їх з’єднати.

Кілька років тому архітектура AI‑додатку виглядала так: надіслати підказку великій мовній моделі -> отримати відповідь -> показати її користувачеві. Це вже не вся історія. Від моделей вимагається інтерпретувати намір, отримувати інформацію, обирати інструменти, викликати API, планувати дії та виконувати багатокрокові робочі процеси.

Цей зсув розділив галузь на два підходи – LLM-First або Code-First

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

У архітектурі Code-First програмне забезпечення/код залишається відповідальним за послідовність, бізнес‑правила, валідацію, дозволи та виконання. LLM тут виступає як спеціаліст, до якого код звертається, коли потрібне розуміння чи генерація мови.

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

Чому LLM-First настільки привабливий

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

Природна мова не співпрацює так. Уявіть, що користувач вводить: «Знайди транзакції, які виглядають незвично, поясни, що сталося, і підкажи, що слід дослідити спочатку».

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

Саме тут LLM відіграє важливу роль, слугуючи гнучким шаром міркувань між людською мовою та вашими детермінованими сервісами. Саме тому агенти привертають таку увагу. Рекомендації Google Cloud щодо агентної AI‑архітектури описують агента як застосунок, у якому модель ШІ працює як рушій міркувань, а інструменти дозволяють їй отримувати доступ до зовнішніх систем і даних.

Керівництво Anthropic Building Effective AI Agents робить розрізнення, до якого я постійно повертаюся. У робочому процесі моделі та інструменти слідують шляхам, які визначає ваш код. У агенті LLM керує власним процесом і вирішує, як використовувати інструменти. Те ж керівництво радить починати з найпростішої архітектури, що вирішує проблему, замість того, щоб додавати агентну складність за рефлексом. Я б підкреслив цю пораду двічі.

Обмеження підходу «Нехай модель вирішує»

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

Наприклад, візьмемо фінансовий робочий процес. LLM може добре розуміти «надішліть ту ж суму, яку я надсилав минулого місяця тому ж постачальнику». Але чи повинен він також вирішувати, чи переказ дозволений, розраховувати регуляторні ліміти, перевіряти право власності на рахунок, скасовувати політику безпеки та виконувати транзакцію?

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

Жодне з цього не означає, що моделі ніколи не повинні виконувати дії. Це означає, що автономність моделі має бути обмежена детерміністичним контролем.

Code-First все ще має значення

Зі швидким розвитком ШІ легко відчути, що традиційна інженерія вийшла з моди. Я б стверджував протилежне. ШІ робить детерміністичні системи ще важливішими, а не менш важливими.

Код все ще є правильним вибором, коли завдання вимагає точної повторюваності. Автентифікація — найпростіший приклад. Модель не повинна «розмірковувати», чи має хтось права адміністратора. Ваш застосунок має запитувати у авторитетної системи управління ідентифікацією та доступом. Те саме стосується грошових розрахунків, перевірки прав, валідації даних, регуляторних обмежень, лімітів транзакцій, валідації схеми та будь‑якого незворотного процесу. Це потребує чітких контрактів, а не здогадок.

Це відповідає ширшому підходу до управління. NIST AI Risk Management Framework закликає організації керувати ризиками ШІ на всіх етапах: проектування, розробки, впровадження та використання. Її супровідний документ Generative AI Profile додає, що генеративні системи можуть потребувати додаткового нагляду, документування, перегляду та контролю, залежно від пов’язаного ризику.

Тому я вважаю за корисне розбити кожне проєктне рішення на два питання:

Що має статися?

і

Що дозволено робити?

LLM часто може допомогти з першим. Детерміновані системи зазвичай мають відповідати за друге.

Гібридний підхід: розмірковувати ймовірнісно, виконувати детерміновано

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

Ось приклад. Припустимо, AI‑асистент допомагає розробникам створювати тимчасові середовища для тестування API, і розробник вводить: “Надай мені пісочницю для робочого процесу онбордингу клієнта.”

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

Приблизний поділ виглядає так:

• LLM: розуміти, розмірковувати, класифікувати, пропонувати, підсумовувати.
• Код: перевіряти, авторизувати, розраховувати, зберігати, забезпечувати дотримання правил, виконувати.

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

Кордони стають важливішими, коли агенти стають потужнішими

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

Виправлення не обов’язково полягає у повному усуванні автономії. Потрібно поступово додавати автономію, зберігаючи явні контрольні точки. Рекомендації Google щодо багатагентних систем радять поєднувати динамічну поведінку ШІ з детермінованими засобами безпеки, спостережуваністю, чітко визначеною автономією та людським наглядом у критичних для бізнесу сценаріях.

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

Принцип простий: чим вищі наслідки дії, тим сильніші детерміновані контролі навколо неї повинні бути.

П’ять питань, які слід задати перед передачею завдання LLM

Коли я вирішую, чи має компонент бути LLM‑first чи code‑first, я розглядаю такі питання:

1. Чи має завдання одну об’єктивно правильну відповідь? Якщо так, віддавайте перевагу детермінованому коду. Податкові розрахунки, дозволи та валідація схеми не повинні змінюватися через те, що модель сьогодні читає їх інакше.
2. Чи включає воно неоднозначну мову або неструктуровану інформацію? Якщо так, LLM може принести реальну цінність.
3. Що станеться, якщо модель помилиться? Правильна архітектура для підсумку зустрічі дуже відрізняється від архітектури для ініціювання платежу.
4. Чи можна незалежно перевірити вихід? Плани, згенеровані LLM, стають значно безпечнішими, коли детерміновані правила можуть перевірити дію, що випливає з плану, перед її виконанням.
5. Чи дійсно це потребує агента? Якщо ви вже знаєте кроки, звичайний робочий процес з кількома цільовими викликами LLM зазвичай простіший, дешевший, легший у тестуванні та експлуатації.

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

Надійність — це архітектурна властивість, а не підказка

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

Система у промисловій експлуатації повинна передбачати, що вивід моделі іноді буде неповним, неправильно сформованим, неочікуваним або просто неправильним. OWASP Top 10 для застосувань LLM перераховує ризики, такі як prompt injection та improper output handling, що підкреслює важливу практику: розглядати вивід моделі як недовірений вхід для наступних систем, а не як інструкції для автоматичного виконання.

Це змінює питання, яке ви ставите. Замість «Як написати підказку, яка завжди змушує модель дотримуватись правила?», запитайте «Як спроектувати систему так, щоб правило не могло бути порушене, навіть коли модель помиляється?»

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

Поза дискусією: системи «intent‑first»

Розмірковуючи над усім цим, я дійшов висновку, що дискусія LLM‑first проти code‑first веде до третьої ідеї: intent‑first архітектура.

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

Запит типу «Допоможіть вирішити проблему з оплатою клієнта» може перетворитися на конвеєр: розуміння інтенції, отримання транзакції, визначення причини збою, рекомендація виправлення, запит схвалення, виконання схваленої операції.

Деякі з цих етапів виграють від розумових можливостей мовних моделей. Інші мають бути фіксованими сервісами. Архітектура не визначається тим, чи «перемагає» ШІ чи код. Вона визначається тим, де прийнятна невизначеність.

Підсумок

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

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

Майбутнє корпоративного ШІ, ймовірно, не буде суто LLM‑first або суто code‑first. Це LLM там, де невизначеність вимагає інтелекту, і код там, де визначеність вимагає контролю.

Ця різниця може мати набагато більше значення, ніж вибір конкретної моделі.