中文翻译暂不可用,显示俄语原文。

Что такое Prompt Registry (каталог промптов с версиями)?

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

Prompt Registry (реестр промптов) — это централизованное хранилище шаблонов промптов с поддержкой версионирования, метаданных и программного API для их динамического получения. Он решает проблему «расползания» промптов по коду, позволяет отслеживать изменения, откатываться к стабильным версиям и автоматизировать развёртывание промптов в production. В контексте Agentic RAG реестр промптов становится ключевым элементом управляемости, так как каждый агент использует десятки специализированных промптов, и их согласованная эволюция критична.


1. Зачем нужен Prompt Registry?

В современных LLM-приложениях, особенно в системах с агентами (RAG|Agentic RAG), промпты — это не просто строки, а программные артефакты. Они содержат:

  • инструкции и системный контекст;
  • переменные, подставляемые в момент вызова (документы, история диалога, инструменты);
  • примеры (few-shot).

Без реестра возникают проблемы:

  • Дублирование – одинаковые промпты раскиданы по разным микросервисам.
  • Неконтролируемые правки – разработчик меняет промпт в коде, и изменение не отслеживается.
  • Сложность отката – если новая версия промпта ухудшает качество, нет простого способа вернуться к предыдущей.
  • Несоответствие модели – промпт, оптимизированный под GPT-4, может хуже работать на Llama 3.

Prompt Registry решает эти задачи: единое место, версии, метаданные, API.


2. Сущности и структура данных

Базовая модель сущности «промпт» включает:

ПолеТипОписание
prompt_idstring (UUID)Уникальный идентификатор промпта (например, customer_support_v2)
versionstring (semver)Семантическая версия, напр. 1.2.3
contentstringТекст промпта с плейсхолдерами ({query}, {context})
modelstring (optional)Целевая модель, для которой оптимизирован промпт (gpt-4o, claude-3)
authorstringКто создал версию
created_atdatetimeВремя создания версии
statusenumdraft, staging, production, deprecated
metadataJSONДополнительные атрибуты (теги, описание, параметры температуры)

Таблица отношений: prompt_versions (хранит все версии), prompts (текущая активная версия для быстрого доступа).


3. Версионирование промптов

Используется semver (major.minor.patch):

  • major – несовместимые изменения структуры (добавление/удаление параметров, кардинальная смена инструкции);
  • minor – обратно совместимые улучшения (добавление few-shot примера);
  • patch – мелкие исправления (опечатки, форматирование).

Также применяются метки (tags) и каналы (channels):

  • latest – всегда указывает на последнюю версию;
  • stable – на последнюю протестированную production-версию;
  • canary – для A/B-тестирования.

Пример семантики версий:

v1.0.0 (initial)
v1.0.1 (fix typo)
v1.1.0 (add few-shot examples)
v2.0.0 (change format from JSON to XML)

4. Хранение и инфраструктура

Оптимальная архитектура включает три уровня:

  1. Git-репозиторий – исходный код промптов (человекочитаемые файлы .yaml или .jinja2). Ведётся история изменений.
  2. PostgreSQL (или другая БД) – нормализованная таблица prompt_versions для быстрых API-запросов по prompt_id и version.
  3. Кэш (Redis) – для часто запрашиваемых версий (с TTL).

Принцип работы:

  • Разработчик редактирует промпт в Git, делает commit, CI/CD пушит новую версию в БД.
  • API реестра получает запрос GET /prompts/{id}/versions/latest и отдаёт из Redis или БД.
# example_prompt.yaml в Git репозитории
prompt_id: customer_support
version: 1.2.3
model: gpt-4o
content: |
  Ты  дружелюбный агент поддержки. Отвечай на вопрос пользователя, 
  используя следующий контекст:
  {context}
  
  Вопрос: {query}
  
  Ответ:
author: ivanov
created_at: 2025-03-15T10:00:00Z
status: production

5. API и интерфейсы

Минимальный набор эндпоинтов:

  • GET /prompts/{prompt_id}/versions/latest – последняя production-версия.
  • GET /prompts/{prompt_id}/versions/{version} – конкретная версия.
  • GET /prompts/{prompt_id}/versions – список всех версий с метаданными.
  • POST /prompts/{prompt_id}/versions – создать новую версию (защищено auth).
  • PATCH /prompts/{prompt_id}/versions/{version}/status – изменить статус (например, promote to production).

Пример ответа (JSON):

{
  "prompt_id": "customer_support",
  "version": "1.2.3",
  "content": "Ты — дружелюбный агент...",
  "model": "gpt-4o",
  "status": "production",
  "created_at": "2025-03-15T10:00:00Z"
}

Клиентский код на Python:

import requests

class PromptRegistry:
    def __init__(self, base_url: str):
        self.base_url = base_url

    def get_prompt(self, prompt_id: str, version: str = "latest") -> dict:
        resp = requests.get(
            f"{self.base_url}/prompts/{prompt_id}/versions/{version}"
        )
        resp.raise_for_status()
        return resp.json()

registry = PromptRegistry("https://prompt-registry.example.com")
prompt_data = registry.get_prompt("customer_support", "1.2.3")
template = prompt_data["content"]
final_prompt = template.format(context=documents, query=user_query)

6. Интеграция с LLM-фреймворками

Популярные решения:

  • LangSmith – встроенный реестр промптов (Prompt Hub). Есть веб-интерфейс, версионирование, теги. Интеграция через langsmith.PromptClient.
  • Humanloop – специализированная платформа для управления промптами, A/B-тестирование, фидбэк.
  • Custom – если нужно полное владение данными (опенсорсные аналоги: PromptLayer, Agenta, Helix).

Пример интеграции с LangChain:

from langchain.prompts import PromptTemplate
from langchain_community.chat_models import ChatOpenAI
import requests

# получаем шаблон из реестра
resp = requests.get("http://registry:8000/prompts/translator/latest")
data = resp.json()
template = PromptTemplate.from_template(data["content"])

chain = template | ChatOpenAI(model="gpt-4o")
result = chain.invoke({"text": "Hello"})

7. Практический пример реализации (Python + FastAPI)

Минимальный локальный Prompt Registry:

# app.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import sqlite3
import uuid
from datetime import datetime

app = FastAPI()

conn = sqlite3.connect("registry.db", check_same_thread=False)
conn.execute("""
    CREATE TABLE IF NOT EXISTS versions (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        prompt_id TEXT,
        version TEXT,
        content TEXT,
        model TEXT,
        author TEXT,
        created_at TEXT,
        status TEXT DEFAULT 'draft'
    )
""")

class VersionCreate(BaseModel):
    prompt_id: str
    content: str
    model: str = "any"
    author: str

@app.get("/prompts/{prompt_id}/versions/latest")
def get_latest(prompt_id: str):
    cur = conn.execute(
        "SELECT * FROM versions WHERE prompt_id=? ORDER BY created_at DESC LIMIT 1",
        (prompt_id,)
    )
    row = cur.fetchone()
    if not row:
        raise HTTPException(404)
    return dict(zip([desc[0] for desc in cur.description], row))

@app.post("/prompts/{prompt_id}/versions")
def create_version(prompt_id: str, data: VersionCreate):
    version = f"1.0.0"  # упрощённо; реально вычислять следующую версию
    ts = datetime.utcnow().isoformat()
    conn.execute(
        "INSERT INTO versions (prompt_id, version, content, model, author, created_at) VALUES (?,?,?,?,?,?)",
        (prompt_id, version, data.content, data.model, data.author, ts)
    )
    conn.commit()
    return {"status": "created", "version": version}

8. Продвинутые возможности

  • A/B-тестирование – возвращать разным процентам запросов разные версии (canary).
  • Approval workflow – изменения проходят ревью, автоматические тесты на качество (метрики faithful, coherence).
  • Diff и аудит – сравнивать версии, логировать, кто и когда менял промпт.
  • Автоматическая оптимизация – сервис предлагает улучшения (например, с помощью DSPy или SPM).

9. Prompt Registry vs хранение в коде

КритерийХранение в коде (константы/env)Prompt Registry
Версионированиенет или ручноеавтоматическое, semver
Откатgit revert + деплойAPI-запрос на старую версию без деплоя
Доступ для не-инженеровтребует PRвеб-интерфейс/API
Динамическая смена (A/B)невозможноканалы, переключение без downtime
Зависимость от моделинеявнаяявное поле model
Метрики производительностинетможно привязать логи оценок качества

10. Роль в Agentic RAG

В Agentic RAG каждый агент использует несколько промптов:

  • system prompt (роль агента);
  • tool prompt (описание доступных инструментов);
  • query rewriter (преобразование пользовательского запроса);
  • memory prompt (извлечение из истории);
  • validation prompt (проверка финального ответа).

При этом промпты меняются по мере эволюции агента: добавляются новые инструменты, корректируется стиль ответа. Prompt Registry позволяет централизованно управлять этими изменениями, обеспечивая воспроизводимость экспериментов и быстрый откат при регрессии.

Лучшие практики

  • Именовать промпты по функциональности (не по агенту).
  • Использовать latest только в dev, в production всегда фиксировать версию.
  • Перед переводом новой версии в production прогонять оффлайн-тесты на эталонном датасете.
  • Хранить в метаданных ссылку на результат тестов и дату валидации.

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

Задача: Создать локальный Prompt Registry с возможностью получать промпт по ID и версии, а также добавлять новую версию через HTTP.

Инструменты: Python, FastAPI, SQLite, Postman или curl.

Шаги:

  1. Реализовать REST API (как в примере выше) с эндпоинтами GET /prompts/{id}/versions/latest и POST /prompts/{id}/versions.
  2. Добавить simple-версионирование: автоматически увеличивать minor-версию при добавлении новой версии.
  3. Реализовать кэширование в памяти (словарь) для latest версии с TTL 60 секунд.
  4. Написать клиентский класс, который форматирует промпт с переданными аргументами.
  5. Добавить простой тест (pytest) – создать версию, получить последнюю, убедиться, что содержимое совпадает.

Ожидаемый результат: Запущенный локально сервер, через который можно получать шаблоны промптов и создавать новые версии. Клиент получает промпт, подставляет переменные и вызывает LLM (можно mocked).


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

ВопросТема
795Что такое Tool Registry?
796Как агенту выбирать инструменты?
798Оркестрация агентов
799Память агентов
793ReAct паттерн
791Базовая архитектура Agentic RAG

Навигация