Это проблема при разработке ИИ-продуктов, которая в очередной раз была разобрана и отмечена как важная на моей текущей учёбе в Johns Hopkins.
Но тот же подход полезен и аналитикам для работы с ИИ.
Аналитик может использовать промпты по-разному.
Для своей работы:
1️⃣ копировать в чат из своей книги промптов
2️⃣ хранить постоянные инструкции в проектах
3️⃣ создавать ИИ-скиллы
4️⃣ использовать для автономных ИИ-агентов
Для внедрения в продукты:
5️⃣ встраивать промпты в системы для интеграций с ИИ
Например, после создания задачи в Jira, ваш ИИ-агент может автоматически:
▫️ определить тип задачи
▫️ найти связанную документацию
▫️ выбрать нужный шаблон промпта в зависимости от типа задачи: БД, REST, Интеграция и т.п.
▫️ сформировать черновик требований Confluence
▫️ передать его аналитику на проверку
Во всех этих случаях используются ШАБЛОНЫ ПРОМПТА под конкретные задачи.
В шаблоне есть:
✅ Постоянная часть:
правила, алгоритм, формат и критерии качества.
✅ Переменная часть:
требования конкретной задачи, документация, API и модель БД.
📌 Но даже постоянная часть со временем меняется.
Допустим, один промпт хорошо подготовил девять Use Case, а в десятом:
➖ потерял альтернативный сценарий
➖ придумал отсутствующее бизнес-правило
➖ забыл описать изменения в БД
Вы доработали промпт и исправили эти проблемы.
Но после изменения он начал хуже описывать ошибки внешней системы.
Это нормальная ситуация:
❗️улучшение одного сценария может ухудшить другой.
Кроме того, качество результата может измениться, даже если шаблон промпта остался прежним:
🔹 вышла новая версия модели
🔹 вы выбрали другую модель или инструмент
🔹 изменились настройки проекта
🔹 обновилась документация
🔹 в диалоге накопился другой контекст
Поэтому у промпта практически не бывает «окончательной» версии 🥲
Что с этим делать?
1️⃣ Версионировать промпты
Даже личную книгу промптов лучше хранить не одним файлом «финальная версия», а с историей изменений.
Например:
v1.0 — базовая структура Use Case
v1.1 — запрет на выдумывание бизнес-правил
v1.2 — обработка ошибок и повторных запросов
v1.3 — описание работы с БД
Личные промпты удобнее всего хранить в Markdown-файлах в GitHub или GitLab.
Для продукта — в Git рядом с кодом или в системе управления промптами.
2️⃣ Сохранять параметры запуска
Для личного промпта достаточно зафиксировать:
→ версию промпта
→ модель
→ дату изменения
→ что и зачем изменили
Для ИИ-продукта дополнительно сохраняют:
→ настройки модели
→ подключённые инструменты
→ источники контекста и RAG
→ схемы входных и выходных данных
Иначе будет сложно понять, что именно повлияло на результат.
3️⃣ Проверять новую версию на старых задачах
Соберите 10–20 разных примеров и запускайте на них каждую новую версию.
Например:
→ простой Use Case
→ неполные требования
→ несколько ролей
→ альтернативные сценарии
→ ошибки интеграции
→ изменение данных в БД
Сравнивайте старую и новую версии результатов по одинаковым критериям:
✔️ полнота
✔️ точность
✔️ соблюдение структуры
✔️ отсутствие выдуманных требований
✔️ соответствие API и модели БД
Каждый сценарий лучше запускать несколько раз: одинаковый промпт не гарантирует одинаковый ответ.
Если версия v1.3 улучшила описание БД, но начала терять ошибки интеграции, её пока нельзя считать успешной.
Нужно продолжить доработку или откатиться на v1.2.
👉 Минимальный рабочий процесс по работе с промптами при внедрении ИИ в продукт:
1. Новая версия
2. Тестовые задачи - несколько запусков на каждую
3. Сравнение качества результатов
4. Коммит новой версии шаблона промпта или откат
В продуктовой разработке промпты уже рассматривают как часть программного кода: хранят версии, проверяют изменения и предусматривают возможность отката.
Этот же подход полезно перенести и в личную работу аналитика 👍
❗️Книга промптов — это не папка с однажды написанными текстами.
Это библиотека рабочих инструментов, которые нужно обновлять, проверять и версионировать.
#AI_for_analysts
Tg | 
ВК | 
Max
