🤖 10 особенностей работы с AI-интеграциями 🤖

AI-интеграции отличаются от обычных.

Тут другая логика, другие риски и другие вопросы от разработчиков.

Разбираю 10 особенностей, которые важно понимать аналитику.


1️⃣ Недетерминированность
AI не возвращает один и тот же ответ на один и тот же запрос.
Нужно явно описывать как система ведёт себя при разных ответах.


2️⃣ Стриминг вместо одного ответа
Ответ может приходить потоком сообщений через SSE.
Это отдельные требования к фронту, бэку и обработке обрывов соединения.


3️⃣ Ограниченный контекст (context window)
Длинный диалог может «выпасть» из памяти модели.
Нужны требования к хранению и передаче истории диалога.



4️⃣ AI сам инициирует вызовы вашего API (Tool Calling)
Не только ваша система вызывает API AI.
AI тоже вызывает ваш API через tools (инструменты), которые вы ему даёте.

Для каждого tool нужно описать:
▫️ название инструмента
▫️ назначение
▫️ входные параметры
▫️ обязательные поля
▫️ ограничения
▫️ возможные ошибки
▫️ какой сервис реально вызывается на backend
▫️ что возвращается обратно в модель



5️⃣ Системный промпт
Это тоже требование.
Его нужно проектировать, документировать, согласовывать и версионировать.

Включает:
▫️ правила поведения AI
▫️ ограничения
▫️ формат ответа
▫️ примеры корректных ответов
▫️ запрещённые действия
▫️ что делать при нехватке данных



6️⃣ Граница «что видит ИИ»: требования к безопасности
Это одно из главных требований, особенно если система работает с:
+ персональными, медицинскими или финансовыми данными
+ коммерческой тайной
+ внутренними документами компании

Аналитик должен зафиксировать:
▫️ какие данные разрешено / запрещено передавать
▫️ нужно ли маскирование / обезличивание
▫️ хранится ли история диалога
▫️ кто имеет доступ к логам AI



7️⃣ Непредсказуемые входные данные
Пользователь может написать что угодно.
Нужны явные требования: как система реагирует на вопросы не по теме, оскорбления, попытки сломать или украсть системный промпт.



8️⃣ Rate limits и стоимость
В отличие от большинства внешних API, у LLM-провайдеров ограничения идут сразу по трём измерениям одновременно:
▫️ RPM — запросов в минуту
▫️ TPM — токенов в минуту
▫️ RPD — запросов в день
Срабатывает первый достигнутый лимит — не обязательно по токенам.

Поэтому в требованиях нужно зафиксировать:
▫️ поведение при HTTP-429
▫️ использование заголовка retry-after — через сколько секунд повторить запрос
▫️ нужен ли rate limiting на стороне нашего бэкенда
▫️ fallback — что делает система, если лимит исчерпан надолго



9️⃣ Логирование диалогов
Чтобы разобрать инцидент «почему AI дал такой ответ», нужно знать:
▫️ какой системный prompt был активен
▫️ какие данные попали в контекст модели
▫️ что написал пользователь
▫️ какие tool calls запросила модель
▫️ какие внутренние сервисы были вызваны
▫️ что модель вернула на каждом шаге
▫️ какой финальный ответ получил пользователь
Без этого разбор инцидентов превращается в гадание.

Дополнительно фиксируем:
▫️ как долго хранятся логи и кто имеет доступ
▫️ нужно ли маскировать ПДн в логах
▫️ логи хранятся на стороне провайдера или только у нас

В медицине это ещё и регуляторный вопрос: история переписки пациента с AI может приравниваться к медицинской документации со всеми вытекающими требованиями к хранению и доступу.



🔟 Agentic loop — цепочка tool calls
AI может сделать несколько вызовов подряд.
Нужна логика остановки, таймаутов и обработки ошибок в цепочке — иначе бесконечный цикл станет сюрпризом на проде.


Сохраняйте, пригодится на задачах с AI-интеграциями 🤝

#ИнтеграцииGA #AI_for_analysts

📱 GetAnalyst | 💙 VK | 💬 Max