LLM-First чи Code-First? Де інтелект належить у виробничому ШІ

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

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

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

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

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

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

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

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

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

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

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

Anthropic’s 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’s agent framework documentation, наприклад, підтримує виклики інструментів, які паузують, доки людина явно не схвалить запитувану операцію.

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

П’ять питань, які слід задати перед передачею завдання 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 там, де невизначеність вимагає інтелекту, і код там, де впевненість вимагає контролю.

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