Створення продукту на основі генеративної штучної інтелекту: що потрібно знати насамперед

Вступ

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

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

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

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

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

Почніть із проблеми, яка потребує генеративного ШІ

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

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

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

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

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

Розробка чи купівля: скільки контролю вам насправді потрібно?

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

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

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

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

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

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

Обирайте архітектуру з урахуванням робочого процесу

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

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

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

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

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

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

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