Від чату до ШІ-систем

Складність: [QUICK]

Час виконання: 35-45 хв

Передумови: базові поняття вебзастосунків, базове розуміння API, вміння читати прості діаграми

Результати навчання

Після завершення цього модуля ви зможете:

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

Чому цей модуль важливий

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

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

Цей модуль дає вам першу ментальну модель побудови з ШІ: модель є одним компонентом усередині більшої програмної системи, а не всією системою. Ви практикуватиметеся розділяти користувацький інтерфейс, оркестрацію, виклик моделі та захисні бар’єри, а тоді використовувати це розділення, щоб порівнювати іграшкові демо зі справжніми функціями v1. Ця сама звичка знадобиться пізніше, коли ШІ-функції працюватимуть поруч із навантаженнями Kubernetes 1.35+, викликатимуть внутрішні API або перебуватимуть в операційних інструментах, де дозволи та аудиторські сліди не можна імпровізувати.

Почнімо з найпростішого зсуву

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

Ви -> промпт -> модель -> відповідь

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

користувач -> застосунок -> побудова промпту -> модель -> логіка застосунку -> вивід

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

Зупиніться і спрогнозуйте: якщо колега каже: «Я вже зібрав це вручну, вставляючи листи клієнтів у чат і копіюючи підсумок у нашу CRM», — які три роботи, окрім набору тексту, виконує колега? Добрі відповіді включають вибір безпечних вхідних даних, визначення формату виводу, потрібного CRM, перевірку точності, редагування відповіді та збереження її в правильний запис. Ці роботи не зникають, коли ви додаєте API; вони переходять у дизайн продукту.

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

Чотири частини простої ШІ-системи

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

+----------------+      +----------------------+      +----------------+
|  Користувач    | ---> |   Інтерфейс заст.     | ---> |  Оркестрація   |
| хоче результат |      | форма, панель, кнопка |      | робочий процес |
+----------------+      +----------------------+      +----------------+
                                                              |
                                                              v
+----------------+      +----------------------+      +----------------+
| Фінальний вивід| <--- |   Захисні бар'єри     | <--- |  Виклик моделі |
| показано або   |      | валідація й перевірка |      | ймовірнісний   |
| утримано       |      |                      |      |                |
+----------------+      +----------------------+      +----------------+

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

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

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

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

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

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

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

Повністю опрацьований приклад: підсумовувач електронних листів

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

Частина	Дизайн підсумовувача листів	Чому це належить сюди
Інтерфейс	Кнопка «Чернетка підсумку», редагована панель підсумку та дія «Зберегти в тікет»	Користувачеві потрібен сфокусований робочий процес, а не відкритий чат
Оркестрація	Завантажити листування, перевірити дозволи, видалити нерелевантні заголовки, побудувати промпт завдання, запитати структурований вивід, розібрати відповідь	Застосунок має контролювати контекст, формулювання завдання та стан робочого процесу
Виклик моделі	Попросити модель створити підсумок, намір клієнта, мітку терміновості та невирішені запитання	Модель корисна для стискання неструктурованої мови в корисну чернетку
Захисні бар’єри	Перевірити поля, обмежити довжину, заблокувати непідтверджені твердження про дії, вимагати збереження людиною, логувати редагування та відмови	Система має запобігти тому, щоб слабкий вивід непомітно ставав збереженим записом

Пройдіть потік так, ніби ви його налагоджуєте. Агент підтримки відкриває тікет T-1182, застосунок перевіряє, чи агент належить до призначеної групи підтримки, і агент натискає «Чернетка підсумку». Застосунок завантажує останні видимі клієнту повідомлення, виключає приватні внутрішні нотатки, формулює вивід як чернетку для агента підтримки, запитує структуровані поля та встановлює тайм-аут, щоб звичайний робочий процес тікета не блокувався безстроково.

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

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

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

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

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

Краща ментальна модель

Не думайте: «Я створюю ШІ-застосунок», — ніби модель є особливою заміною системного дизайну. Думайте: «Я створюю програмну систему, яка використовує модель у конкретних точках ухвалення рішень». Таке формулювання залишає детерміновані частини детермінованими, розміщує невизначеність там, де їй належить бути, і полегшує налагодження функції, коли щось іде не так.

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

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

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

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

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

Вибір доброго першого варіанту використання

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

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

Добрий перший варіант використання також має зрозумілий стан завершеності. «Допомогти агентам підтримки підсумовувати листи» зрозуміліше, ніж «зробити підтримку розумнішою». «Видобути номер рахунку, постачальника, дату оплати та суму в чергу перевірки» зрозуміліше, ніж «розуміти рахунки». «Створити чернетку приміток до релізу зі злитих pull request’ів» зрозуміліше, ніж «керувати релізами». Конкретність зменшує когнітивне навантаження, зменшує ризик і дає вам щось конкретне для тестування.

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

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

Іграшкове демо проти справжньої v1

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

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

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

Вам не потрібно будувати кожен зрілий засіб контролю з першого дня. Вам потрібно чесно позначити стадію, щоб стейкхолдери не брали на себе надмірних зобов’язань. Ви можете сказати: «Це демо, яке доводить, що модель може відповідати», або «Це чернетковий помічник v1 із людською перевіркою», або «Це не готове до автономних дій». Ці позначки захищають команду, оскільки вони пов’язують продуктові заяви з фактичними засобами контролю в системі.

Налагодження дизайну ШІ-функції

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

Оглядове запитання	Слабка відповідь	Сильніша відповідь
Що користувач намагається досягти?	«Використати ШІ у підтримці»	«Підсумувати довгі листи підтримки перед тим, як агент відповість»
Яка обмежена робота моделі?	«Обробити тікет»	«Створити чернетку підсумку, наміру, терміновості та відкритих запитань»
Що залишається детермінованим?	«Модель може вирішити»	«Дозволи, запис даних, перевірки політик і дії збереження залишаються в коді»
Як обирається контекст?	«Надіслати тікет»	«Надіслати лише видимі клієнту повідомлення, до яких агент має доступ»
Як перевіряється вивід?	«Відповідь має виглядати добре»	«Перевірити поля, мітки, довжину та заборонені твердження»
Що людина може змінити?	«Вони можуть ігнорувати»	«Вони можуть редагувати, відхилити, повторити або зберегти явно»
Що станеться при відмові?	«Спробувати пізніше»	«Показати резервний варіант, залогувати трасування та зберегти звичайний робочий процес»

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

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

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

Проєктування першої версії

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

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

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

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

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

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

Що залишати детермінованим

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

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

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

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

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

Для чого моделі придатні

Моделі корисні, коли мова неструктурована, а бажаний вивід можна перевірити або проконтролювати. Листи клієнтів містять непрямі запити, емоційні формулювання, пропущений контекст і довгі відступи. Звіти про інциденти змішують симптоми, гіпотези та часткові хронології. Обговорення pull request’ів включають технічні скорочення та соціальні перемовини. У цих ситуаціях модель може стискати, реорганізовувати, класифікувати або пояснювати матеріал у спосіб, що економить людям час.

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

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

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

Саме тому питання «Чи може модель це зробити?» є занадто розмитим для інженерного дизайну. Краще питання: «Яка частина цієї роботи виграє від ймовірнісної обробки мови, а яка частина потребує детермінованих повноважень?» Це питання веде до кращих інтерфейсів, чистішої оркестрації, сильніших захисних бар’єрів і чеснішого обсягу проєкту. Воно також допомагає командам уникати як галасу, так і страху, оскільки кожна відповідальність отримує конкретного власника.

Що вимірювати насамперед

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

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

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

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

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

Патерни й антипатерни

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

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

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

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

Коли ви використовували б це проти альтернатив

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

Якщо ви вибираєте між чат-інтерфейсом і сфокусованим робочим процесом, оберіть інтерфейс, який відповідає реальному завданню користувача. Чат корисний, коли користувачеві потрібне дослідження, уточнення в обидва боки або широка допомога. Кнопка, форма, панель або черга перевірки зазвичай кращі, коли завдання має відомий ввід, відому форму виводу та чіткий крок збереження або затвердження. Інтерфейс є частиною системи контролю, оскільки він навчає користувача, наскільки довіряти виводу.

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

Чи знали ви?

NIST опублікував AI Risk Management Framework 1.0 у січні 2023 року. Його функції govern, map, measure і manage відповідають звичці, яку ви тут вивчаєте: називайте контекст, вимірюйте поведінку та керуйте ризиком, замість того щоб ставитися до якості ШІ як до питання відчуттів.
OWASP Top 10 для застосунків на основі великих мовних моделей відстежує ризики за межами формулювання промпту. Він включає такі проблеми, як розкриття чутливої інформації, надмірна агентність, небезпечна обробка виводу та проблеми ланцюга постачання, що підкріплює, чому системні межі мають значення.
Структуровані виводи змінюють інженерну проблему. Замість того щоб просити застосунок інтерпретувати довільний текст, відповідь у формі схеми дозволяє звичайному програмному забезпеченню перевіряти обов’язкові поля, відхиляти невідомі мітки та зазнавати невдачі в спосіб, зрозумілий користувачам.
Людська перевірка — це елемент дизайну, а не вибачення. Коли перевірка вбудована в потік, користувачі швидше виправляють вивід, команда отримує сигнали якості, а продукт уникає вдавання, що ймовірнісна чернетка вже є авторитетною дією.

Поширені помилки

Помилка	Чому вона трапляється	Як її виправити
Ставлення до моделі як до цілого продукту	Чат-демо приховує роботу з дозволами, вибором контексту, валідацією, перевіркою та резервним сценарієм, яку людина виконувала вручну	Спочатку спроєктуйте повний робочий процес, потім розмістіть виклик моделі всередині нього як один контрольований компонент
Початок з автономних дій	Стейкхолдери бачать плавну відповідь і припускають, що система може безпечно фіксувати зміни, надсилати повідомлення або схвалювати рішення	Почніть із потоків чернеток або пропозицій, вимірюйте надійність і автоматизуйте лише вузькі кроки з доказами та шляхами відкату
Використання ШІ там, де достатньо детермінованих правил	Команда хоче модель у функції, навіть коли запит, парсер, обчислення або правило політики були б точними	Залишайте точні рішення в звичайному коді, а модель резервуйте для неструктурованої мови, підсумовування, видобування, створення чернеток або пояснення
Оптимізація промптів перед уточненням варіанту використання	Налаштування промпту здається продуктивним, але завдання, користувач, межі даних і режими відмов усе ще розмиті	Запишіть мету користувача, роботу моделі, детерміновані засоби контролю, форму виводу та обробку відмов перед шліфуванням формулювання промпту
Копіювання чат-інтерфейсу для кожної функції	Чат знайомий, тому він стає типовим, навіть коли завдання має відомий ввід і форму виводу	Використовуйте форму, кнопку, панель або чергу перевірки, коли сфокусований робочий процес краще передає завдання та точку перевірки
Пропуск валідації виводу	Перші кілька прикладів виглядають добре, тому некоректні поля, непідтверджені твердження та ризиковані мітки розглядаються як рідкісні крайові випадки	Перевіряйте структуру, мітки, довжину, підтримку джерел і заборонені твердження перед показом або збереженням, потім записуйте результати валідації
Приховування кроку людської перевірки	Команди хвилюються, що перевірка робить продукт менш розумним на вигляд, тому чернетки подаються як готові відповіді	Зробіть дії редагування, відхилення, повтору та збереження явними, щоб користувачі знали, де належить судження, а команда могла вчитися на виправленнях

Вікторина

Питання 1: Ваша команда створює ШІ-функцію, яка генерує чернетки підсумків тікетів клієнтів. У прототипі модель пише безпосередньо в історію тікета. Під час тестування агенти кажуть, що підсумки часто корисні, але іноді пропускають запити на скасування. Що слід змінити, перш ніж називати це справжньою v1?

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

Питання 2: Стейкхолдер просить ШІ-асистента для білінгу, який вирішує, чи кваліфікується клієнт на повернення коштів, а потім пояснює рішення. Як вам слід проаналізувати відповідальність між детермінованим програмним забезпеченням і моделлю?

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

Питання 3: Ви перевіряєте ШІ-генератор приміток до релізу. Він надсилає весь текст нещодавніх pull request'ів моделі, і вивід згадує несумісну зміну з-поза діапазону релізу. Який рівень слабкий і як би ви налагодили дизайн?

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

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

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

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

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

Питання 6: Демо добре підсумовує транскрипти зустрічей, коли автор обирає чисті приклади. У реальному використанні транскрипти містять кількох доповідачів, незавершені речення та чутливі HR-обговорення. Які запитання слід поставити, перш ніж обрати це як безпечний для початківця варіант використання?

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

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

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

Практична вправа

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

Крок 1: Запишіть мету користувача одним конкретним реченням. Слабка мета — «Використати ШІ для підтримки», оскільки вона не називає користувача, завдання або вивід. Сильніша мета — «Допомогти агенту підтримки створити короткий редагований підсумок довгого листування клієнта». Ваше речення має бути достатньо конкретним, щоб інший інженер міг визначити, чи підтримує його запропонований інтерфейс.

Орієнтири розв'язання для Кроку 1

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

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

Орієнтири розв'язання для Кроку 2

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

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

Орієнтири розв'язання для Кроку 3

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

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

Орієнтири розв'язання для Кроку 4

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

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

Орієнтири розв'язання для Кроку 5

Автоматичні перевірки можуть валідувати обов’язкові поля, дозволені мітки, посилання на джерела, обмеження довжини або заборонені твердження. Людська перевірка може бути редагованою чернеткою, кнопкою затвердження, чергою перевірки або явною дією збереження. Резервний сценарій може показати оригінальне джерело з чітким повідомленням, що генерація зазнала невдачі, зберігаючи звичайний робочий процес користувача.

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

Орієнтири розв'язання для Кроку 6

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

Крок 7: Опишіть реалістичну семантичну відмову і як дизайн обмежує шкоду. Не обирайте лише «API недоступний», оскільки відмови доступності легше помітити, ніж правдоподібні хибні відповіді. Оберіть оманливий підсумок, пропущене поле, непідтверджене твердження, хибну мітку або небезпечну рекомендацію, потім пов’яжіть відмову з вашим інтерфейсом, оркестрацією та захисними бар’єрами.

Орієнтири розв'язання для Кроку 7

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

Крок 8: Вирішіть, чи є ваша функція іграшковим демо, справжньою v1 або небезпечним першим проєктом, і обґрунтуйте позначку, використовуючи чотири частини. Справжня v1 повинна мати робочий процес користувача, оркестрацію, обмежену роботу моделі, захисні бар’єри та обробку відмов. Іграшкове демо може доводити, що модель може відповідати, але не має продуктових засобів контролю. Небезпечний перший проєкт дає моделі занадто багато повноважень до того, як команда може перевірити надійність.

Орієнтири розв'язання для Кроку 8

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

Критерії успіху

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

Джерела

Building Effective AI Agents — Пояснює контрольовані робочі процеси, агентів і те, коли автономність додає складності.
Structured model outputs — Документує виводи у формі схеми та орієнтовані на валідацію відповіді моделі.
AI Risk Management Framework — Визначає практики управління, картографування, вимірювання та керування ризиками ШІ.
OWASP Top 10 for Large Language Model Applications — Каталогізує поширені ризики застосунків, такі як надмірна агентність і небезпечна обробка виводу.
OpenAI Text Generation Guide — Охоплює патерни промптів і відповідей для функцій застосунків на основі моделей.
OpenAI Function Calling Guide — Описує підключення виводів моделі до контрольованих програмним забезпеченням функцій та інструментів.
OpenAI Production Best Practices — Надає операційні настанови для продакшен-інтеграцій моделей.
Anthropic Prompt Engineering Overview — Надає вендорські настанови щодо формулювання завдань і дизайну промптів.
Anthropic Evaluation Tool Documentation — Охоплює визначення та запуск оцінювань для поведінки моделі.
Google Cloud Responsible AI Guidance — Надає хмарні вендорські настанови для відповідального дизайну ШІ-систем.

Наступний модуль

Продовжуйте до Моделі, API, контекст і структурований вивід, щоб перетворити цю карту системи на конкретні виклики моделей і перевірені виводи.