Как вы храните историю изменений промптов (prompt lineage)?

Краткий тезис

Хранение истории изменений промптов (prompt lineage) — это практика, позволяющая отслеживать каждую версию промпта, её автора, дату, причину изменения, а также связывать версию промпта с версией модели и логами ответов. Без этого невозможно откатить изменения, понять, какая версия привела к ухудшению качества, или воспроизвести старый эксперимент. Основные подходы — использование Git для файлов промптов, хэширование промптов (SHA256) и специализированные инструменты (LangSmith, MLflow), которые автоматически фиксируют версии и метаданные.

1. Термин: Prompt lineage (происхождение промптов)

Prompt lineage — это запись всей эволюции текста промпта и его параметров (temperature, top_p, strategy, model name) от первой версии до текущей. В контексте LLM-приложений это аналог lineage|data lineage для данных и model lineage для моделей: нужно знать, какой «код» (промпт) породил какой ответ.

Зачем это нужно:

• Откат на рабочую версию, если новая версия сломала продукт.
• Воспроизводимость — возможность в точности воспроизвести ответ, который давала система месяц назад.
• Аудит и compliance — требования регуляторов (например, в медицине или финансах) фиксировать, почему и кем был изменён промпт.
• Анализ регрессий — когда метрики упали, можно быстро найти, какое изменение промпта (или модели) к этому привело.

2. Проблема: хаос версий без системы

Без явного lineage разработчики часто:

• Перезаписывают промпт прямо в коде, не сохраняя предыдущие варианты.
• Меняют промпт в черновике, теряя историю.
• Не могут сказать, какая версия была на проде неделю назад → невозможно откатить падение качества.
• Не могут связать конкретный ответ пользователя с версией промпта и модели → сложно анализировать ошибки.

Термин «регрессия» (regression) — ухудшение качества ответов LLM после внесения изменений в промпт или модель.

3. Git-подход: каждый промпт в своём файле

Самый простой способ — хранить промпты как текстовые файлы в Git-репозитории. Рекомендуемая структура:

prompts/
├── v1.0/
│   ├── system_prompt.txt
│   └── user_prompt_template.txt
├── v1.1/
│   ├── system_prompt.txt
│   └── user_prompt_template.txt
└── current/
    └── symlink -> ../v1.1

Или, для большего числа промптов, каждый промпт — отдельный файл с версией в имени:

prompts/
├── summarization_v1.txt
├── summarization_v2.txt
├── qa_v1.txt
└── qa_v2.txt

Плюсы естественное версионирование, code review, ветвление (A/B тесты).
Минусы неудобно, если промптов много, и сложно автоматически связывать с логами ответов.

4. Хэширование промпта + версия модели

Для связи промпта с каждым ответом можно вычислять хэш промпта (например, SHA256) и сохранять его вместе с версией модели в лог ответа.

Пример структуры лога (JSON):

{
  "timestamp": "2025-02-20T12:00:00Z",
  "prompt_hash": "a1b2c3d4e5f6...",
  "model_version": "gpt-4o-2024-11-20",
  "temperature": 0.7,
  "input": "Расскажи про RAG",
  "output": "Retrieval-Augmented Generation — это...",
  "user_id": "..."
}

Термин «хэш» (hash) — строка фиксированной длины, однозначно соответствующая содержимому промпта. Любое изменение промпта (даже пробел) даёт новый хэш.

Зачем это нужно

• По хэшу можно найти, какая версия промпта использовалась для данного ответа.
• Если хэша нет в базе известных версий — значит, промпт был изменён вне контроля.

5. Инструменты для автоматического отслеживания

LangSmith — самый удобный для быстрой интеграции: он автоматически снимает слепок промпта при каждом вызове LLM и позволяет просматривать историю в UI. Термин «трассировка» (tracing) — запись всей цепочки вызовов (prompt, LLM, tool) с метаданными.

6. Тегирование версий

Присваивание тегов (tags) версиям промптов упрощает управление. Примеры тегов:

• production-v1 — текущая версия в проде.
• staging-v2 — кандидат на замену.
• archived-2025-01 — старая версия, сохранённая для истории.
• best-performing-augmented — версия, показавшая лучшие метрики во время A/B теста.

Схема тегирования:

Version v1.2 → tags: [production, best-known]
Version v1.3 → tags: [staging, experiment-ab-test-7]
Version v1.1 → tags: [archived, last-stable-before-chunk-change]

При переключении проката обновляем тег production на новую версию и снимаем с предыдущей.

7. Аннотации: кто, когда, зачем менял

Каждое изменение промпта должно сопровождаться метаданными:

• Автор (developer ID / имя)
• Дата и время (timestamp)
• Причина изменения (comment, ссылка на задачу JIRA/Linear)
• Связанный pull request (если через Git)
• Результат A/B теста (опционально)

Пример аннотации в YAML (вариант хранения вместе с файлом промпта):

version: 1.4
author: "ivan.ivanov@company.com"
date: "2025-02-18T15:30:00Z"
reason: "Добавлены инструкции избегать галлюцинаций — см. тикет PROMPT-42"
previous_hash: a1b2c3d4
current_hash: e5f6g7h8
tags: [staging]

Без аннотаций невозможно понять мотивацию изменения, и строить культуру улучшения промптов становится сложно.

8. Процесс CI/CD для промптов

Чтобы избежать «хаоса версий», промпты должны проходить такой же процесс ревью, как код:

1. Разработчик создаёт ветку в Git, изменяет файл промпта, добавляет аннотацию.
2. Code review — другой разработчик проверяет изменения.
3. Автоматические тесты — прогон набора тестовых кейсов с оценкой метрик (faithfulness, answer relevance).
4. A/B тест (по желанию) — небольшая часть трафика направляется на новую версию.
5. Merge в main/master → деплой на продакшен.
6. Мониторинг — если метрики упали, автоматический откат через Git revert или переключение тега.

Интеграция с CI/CD (Continuous Integration / Continuous Deployment) — pipeline, который собирает промпты, запускает тесты и деплоит новую версию.

9. Хранилище промптов: централизованное или файловое

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

10. Мониторинг и алерты при изменении промптов

После того как новая версия промпта вышла в прод, нужно автоматически отслеживать её влияние:

• Метрики качества (RAGAS, faithfulness, answer relevance) — строятся по логам ответов с новым хэшем.
• Отслеживание аномалий — если метрика упала ниже порога, срабатывает алерт и запускается автоматический откат на предыдущую версию.
• Дашборды в Grafana / Datadog — показывают распределение версий промптов и связь с метриками.

Термин «метрики онлайн» (online metrics) — метрики, считающиеся в реальном времени на живых запросах пользователей.

Пет-проект для закрепления

Задача Создать простую систему lineage для чат-бота на Flask с использованием Git и SQLite, которая:

• Хранит промпты в Git-репозитории (по одному файлу на версию).
• При каждом запросе вычисляет хэш промпта, записывает его в лог вместе с версией модели (захардкодить) и ответом.
• Реализует endpoint /version для просмотра истории версий промптов.
• Позволяет переключать active версию промпта через тег production (например, через файл current.txt с именем версии).

Инструменты Python, Flask, GitPython (для работы с Git из кода), SQLite, hashlib.

Шаги:

1. Организовать папку prompts с файлами v1.txt, v2.txt и current.txt.
2. При старте Flask приложение читает current.txt и загружает соответствующий промпт.
3. Endpoint /chat принимает запрос, вычисляет хэш промпта, генерирует ответ (кладет фиктивный), сохраняет в SQLite запись: timestamp, хэш, модель, input, output.
4. Endpoint /versions показывает все версии из Git, их хэши, даты коммитов и аннотации (из commit message).
5. Добавить API для переключения версии: /switch?v=v2 — обновляет current.txt, делает новый коммит с сообщением.

Ожидаемый результат пет-проект, наглядно демонстрирующий, как можно связать Git (история изменений) с логами ответов (хэш) и делать откат.

Связь с другими вопросами

Навигация

• Предыдущий: 94
• Следующий: 96
• Индекс: 00. Индекс разборов