Как добавить функции ИИ в приложение

Чтобы добавить функции ИИ в приложение, вызывайте API большой языковой модели (LLM) с сервера: отправляйте ей понятные инструкции и нужные данные и используйте то, что вернётся. Большинство полезных функций относятся к одному из четырёх шаблонов — пересказ, чат, извлечение структурированных данных и классификация, — и каждый из них реализуется в нескольких десятках строк кода, которые ИИ-конструктор может написать за вас. Но то, хороша ли функция, решает не сам вызов модели, а всё вокруг него: ключ API на сервере, контроль стоимости на пользователя и проверка результата перед тем, как ему доверять.

Четыре шаблона, на которых строится большинство функций ИИ

Извлечение и классификация часто самые ценные и самые незаметные функции. Они незаметно экономят людям по несколько минут на каждой записи, а поскольку результат имеет фиксированную форму, его можно проверять автоматически. Чат самый заметный, но и самый сложный в настройке; у него есть отдельный гид: как создать приложение-чатбот на ИИ.

Как это встраивается в приложение

У каждого шаблона одна и та же схема:

1. Пользователь действует — нажимает «Пересказать», загружает файл, отправляет сообщение.
2. Фронтенд обращается к вашему серверу, а не к провайдеру ИИ.
3. Сервер формирует запрос: системные инструкции, ввод пользователя и данные из базы, которые нужны модели, — только те, которые этот пользователь вправе видеть.
4. Сервер вызывает API LLM с ключом из переменной окружения.
5. Сервер проверяет ответ — корректный JSON, известная метка, разумная длина — и сохраняет или возвращает его.
6. Фронтенд показывает результат, а для длинных ответов выводит текст по мере поступления.

Ключ находится на сервере на шаге 4 и никогда не попадает в браузер. Если идея API для вас нова, короткое пояснение есть в гиде что такое API, а как использовать LLM API подробно объясняет токены, модели и ключи.

Выбор провайдера и модели

Крупные провайдеры — OpenAI, Anthropic, Google и другие — предлагают текстовые API с похожим устройством. При выборе полезно ответить на несколько вопросов:

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

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

Добавление функции по шагам

Возьмём конкретный пример: небольшая CRM, где у каждого контакта длинная история заметок.

1. Сохраните ключ. Создайте ключ в панели провайдера и сохраните его как секрет на сервере, например OPENAI_API_KEY или ANTHROPIC_API_KEY.

2. Попросите об одной узкой функции:

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

3. Добавьте извлечение там, где оно экономит набор текста:

Когда пользователь вставляет подпись из письма в поле «Быстрое добавление», вызови [PROVIDER] на сервере и верни JSON с именем, компанией, должностью, email и телефоном, используя функцию структурированного вывода провайдера. Проверь JSON на сервере, заполни форму нового контакта и дай пользователю отредактировать данные до сохранения. Оставляй поля пустыми, а не угадывай.

Важнее всего здесь «дать пользователю отредактировать до сохранения»: модель предлагает, а решает человек.

4. Классифицируйте в фоне:

Когда приходит новый тикет поддержки, классифицируй его ровно в одну из категорий: оплата, ошибка, запрос функции, доступ к аккаунту, другое. Используй небольшую дешёвую модель. Если ответ не входит в эти метки, сохраняй «другое». Показывай метку как редактируемый тег.

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

Как писать инструкции, которые работают

Инструкции, которые отправляются с каждым запросом (часто их называют системным промптом), — главный источник качества.

• Скажите, для кого это и что считается хорошим результатом. «Пересказы читает продавец за 10 секунд перед звонком» даёт модели ориентир.
• Зафиксируйте формат. Точное количество пунктов, ограничение длины, поля, метки.
• Скажите, что делать, если модель не уверена. «Если в заметках нет следующего шага, напиши „Следующий шаг не записан“». Это уменьшает количество выдуманных ответов.
• Дайте два-три примера хорошего входа и выхода для извлечения и классификации.
• Отделяйте инструкции от пользовательского содержимого и явно помечайте пользовательский текст, чтобы модель различала их.

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

Контроль стоимости

API LLM берут плату за токены — небольшие фрагменты текста — и за то, что вы отправляете, и за то, что приходит в ответ. Стоимость растёт пропорционально объёму контекста в запросе и частоте выполнения. Практические меры:

• Отправляйте только необходимое. Последние 20 заметок, а не всю историю. Обрезайте длинные документы или делите их на части.
• Берите самую маленькую модель, которая справится. Проверьте её, прежде чем брать самую большую по умолчанию.
• Ограничивайте длину ответа параметром максимального числа токенов в API.
• Кэшируйте результаты. Сохраняйте пересказ и пересоздавайте его только при изменении источника, а не при каждом открытии страницы.
• Ставьте лимиты на пользователя. Суточный лимит на аккаунт или тариф не даст одному активному пользователю или скрипту раскрутить счёт.
• Ограничивайте частоту запросов к эндпоинту, как к любому другому дорогому маршруту.
• Задайте бюджет или уведомление в панели провайдера и проверяйте расход раз в неделю после запуска.
• Логируйте расход токенов по каждой функции, чтобы знать, какая из них сколько стоит.

Если ИИ-функции — основа вашего продукта, заложите их стоимость в цену, а не поглощайте её.

Безопасность и доверие

Результат ИИ вероятностный. Он может ошибаться, звуча при этом уверенно, и им можно управлять через текст, который модель читает. Проектируйте с учётом этого:

• Считайте результат недоверенным вводом. Проверяйте структуру, экранируйте его перед выводом как HTML и никогда не выполняйте как код или запросы к базе.
• Оставляйте человека в контуре для всего, что имеет последствия: отправка письма, изменение записи, возврат платежа. Модель составляет черновик, человек подтверждает.
• Защищайтесь от prompt injection. Документ или сообщение может содержать текст вроде «игнорируй свои инструкции». Ограничивайте то, что модель видит, данными, доступными текущему пользователю, и не давайте ей инструменты для важных действий без проверки прав вашим кодом.
• Помечайте контент ИИ, чтобы пользователи знали: пересказ или предложение создано ИИ и его можно проверить.
• Аккуратно обрабатывайте сбои. У провайдеров бывают сбои и лимиты запросов. Задайте таймаут, покажите понятное сообщение и дайте остальной части приложения работать.
• Следите за тем, что присылают пользователи. Для открытых текстовых полей подумайте о модерации и укажите в политике конфиденциальности, что контент обрабатывает сторонний провайдер ИИ.

Более широкий список проверок — в чек-листе безопасности для приложений, собранных с ИИ.

Частые ошибки

• Начинать с общего чатбота, когда одна кнопка «Пересказать» или «Категоризировать» принесла бы пользу большему числу людей.
• Класть ключ во фронтенд-код или в публичный репозиторий.
• Отправлять всю базу данных как контекст: это медленно, дорого и грозит раскрыть данные других пользователей.
• Доверять свободному тексту там, где схема или фиксированный набор меток сделали бы результат проверяемым.
• Нет лимитов на пользователя, о которых узнают, когда придёт первый счёт.

Добавление ИИ-функций в Mythex

В Mythex вы добавляете ИИ в своё приложение, попросив об этом в чате, используя собственный ключ провайдера. Сохраните ключ как секрет проекта: когда агенту он понадобится, Mythex покажет в чате карточку секретов, и ключ не придётся вставлять в переписку. Агент напишет серверный маршрут, промпты и интерфейс. Использование ИИ в вашем приложении оплачивает ваш провайдер, отдельно от кредитов Mythex, которые вы тратите на сборку. Стартовый промпт есть в документации: добавить ИИ-функции с вашими API-ключами.

Вопросы