Як додати функції ШІ до застосунку

Щоб додати функції ШІ до застосунку, викличте API великої мовної моделі (LLM) з вашого сервера: надішліть їй чіткі інструкції плюс відповідні дані та використайте те, що повернеться. Більшість корисних функцій належать до одного з чотирьох шаблонів — підсумовування, чат, видобування структурованих даних і класифікація, — і кожна з них становить кілька десятків рядків коду, які конструктор на базі ШІ може написати за вас. Те, що визначає, наскільки функція корисна, — це робота навколо виклику: збереження ключа API на сервері, контроль вартості на кожного користувача та перевірка результату перед тим, як йому довіряти.

Чотири шаблони, на яких будується більшість функцій ШІ

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

Як це вписується в застосунок

Кожен шаблон має однакову структуру:

1. Користувач діє — натискає «Підсумувати», завантажує файл, надсилає повідомлення.
2. Ваш фронтенд викликає ваш власний сервер, а не постачальника ШІ.
3. Ваш сервер формує запит: системні інструкції, введені користувачем дані та будь-які дані з бази, потрібні моделі, — лише ті, які цьому користувачеві дозволено бачити.
4. Ваш сервер викликає API мовної моделі з ключем, збереженим у змінній середовища.
5. Ваш сервер перевіряє відповідь — коректний JSON, відома мітка, розумна довжина — і зберігає або повертає її.
6. Фронтенд показує результат, передаючи довгі відповіді потоково, в міру надходження тексту.

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

Вибір постачальника та моделі

Основні постачальники — OpenAI, Anthropic, Google та інші — пропонують текстові API зі схожою структурою. Корисні запитання під час вибору:

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

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

Додавання функції крок за кроком

Візьмемо конкретний приклад: невелика CRM, де в кожного контакту є довга історія нотаток.

1. Збережіть ключ. Створіть ключ у панелі постачальника та збережіть його як секрет на сервері, наприклад OPENAI_API_KEY або ANTHROPIC_API_KEY.

2. Попросіть про одну вузьку функцію:

Додай кнопку «Підсумувати» на сторінку контакту. На сервері надішли останні 20 нотаток контакту до [PROVIDER], використовуючи секрет [ENV_NAME], з інструкцією написати три пункти: поточний статус, відкриті питання, наступний крок. Включай лише нотатки, які може бачити користувач, що увійшов. Покажи стан завантаження, збережи підсумок із позначкою часу та показуй «Не вдалося зробити підсумок зараз», якщо виклик не вдався. Ніколи не надсилай ключ у браузер.

3. Додайте видобування там, де це заощаджує набір тексту:

Коли користувач вставляє підпис електронного листа в поле «Швидке додавання», викликай [PROVIDER] на сервері та поверни JSON з полями ім'я, компанія, посада, електронна пошта й телефон, використовуючи функцію структурованого результату постачальника. Перевір JSON на сервері, заповни форму нового контакту цими даними й дай користувачеві відредагувати їх перед збереженням. Залишай поля порожніми замість здогадок.

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

4. Класифікуйте у фоновому режимі:

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

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

Як писати інструкції, які працюють

Інструкції, які ви надсилаєте з кожним запитом (її часто називають системним промптом), — це джерело якості.

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

Зберігайте промпти у файлах у вашій кодовій базі, щоб вони були версіонованими та придатними для перевірки, як будь-який інший код.

Контроль витрат

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

• Надсилайте лише потрібне. Останні 20 нотаток, а не всю історію. Скорочуйте довгі документи або ділите їх на частини.
• Використовуйте найменшу модель, що справляється із завданням. Тестуйте, перш ніж за замовчуванням брати найбільшу.
• Обмежуйте довжину відповіді параметром максимальної кількості токенів API.
• Кешуйте результати. Зберігайте підсумок і перегенеровуйте його лише тоді, коли змінилося джерело, а не при кожному перегляді сторінки.
• Обмежуйте на користувача. Денний ліміт для облікового запису або тарифу не дає одному активному користувачеві чи одному скрипту накрутити рахунок.
• Обмежуйте частоту запитів до ендпоінта, як і до будь-якого іншого дорогого маршруту.
• Встановіть бюджет або сповіщення в панелі постачальника та перевіряйте використання щотижня після запуску.
• Фіксуйте використання токенів для кожної функції, щоб знати, яка скільки коштує.

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

Безпека та довіра

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

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

Повний перелік перевірок — у контрольному списку безпеки для застосунків, створених на ШІ.

Типові помилки

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

Додавання функцій ШІ з Mythex

У Mythex ви додаєте ШІ до свого застосунку, просячи про це в чаті, з використанням власного ключа постачальника. Зберігайте ключ як секрет проєкту: коли агенту він потрібен, Mythex показує картку секретів у чаті, тож ви не вставляєте ключ у розмову. Агент пише серверний маршрут, промпти та інтерфейс. Використання ШІ вашим застосунком оплачує ваш постачальник, окремо від кредитів Mythex, які ви витрачаєте на створення. Стартовий промпт є в документації: додавання функцій ШІ з вашими ключами API.

Запитання