Розробка кастомної системи керування промптами (Prompt Registry)

Зауважте: коли кількість промптів у LLM-системах перевалює за десяток, починається хаос. Одного разу ми бачили проєкт, де версії зберігалися в Jira, Confluence, Slack і навіть у коментарях до коду. Типова помилка в промпті — і платіжний запит на $2500 йшов з невірними даними. Деплой зміни на 50 мікросервісів займав 3 дні ручного копіювання. Prompt Registry — це система керування промптами, яка централізує зберігання, версіонування та деплой. Ми розробляємо кастомні Prompt Registry під ключ для компаній, яким не підходять готові рішення (PromptLayer, Humanloop). Наш досвід — 10+ років в AI/ML, 50+ запущених проєктів, у тому числі для RegTech та FinTech з жорсткими вимогами до безпеки. Ми гарантуємо якість та compliance, маємо сертифікати ISO 27001 та досвід роботи з RegTech. Наша компанія має 5 років досвіду в кастомній розробці AI-систем.

За словами розробників OpenAI, версіонування промптів — ключовий елемент production-ready LLM-систем.

Проблеми, які вирішує Prompt Registry

Без централізованого реєстру промптів рано чи пізно виникають три критичні проблеми:

• Відсутність версіонування. При аудиті — провал compliance. Ніхто не знає, який промпт використовувався в кожному запиті. Відновлення історії — ручний пошук по логах і чатах.
• Ручне поширення змін. Оновити промпт на 50 мікросервісів — ад для DevOps. З реєстром — один запит до API, і всі клієнти підхоплюють нову версію за секунди. Відкочування — один виклик.
• Немає моніторингу якості. Ми впроваджуємо збір метрик: latency p99, токени, вартість запиту, quality score. Це дозволяє A/B тестувати промпти і вибирати найкращий. Типове покращення якості — 15–30%.

Чому компаніям потрібен кастомний Prompt Registry?

Готові сервіси (PromptLayer, Humanloop) — хороший entry-level, але вони не закривають корпоративні потреби. Ось ключові відмінності:

Таблиця нижче показує реальні покращення після впровадження кастомного реєстру:

Кастомний Prompt Registry окупається за рахунок зниження часу на розгортання в 10 разів порівняно з ручним керуванням. Типова економія бюджету MLOps — 40%, що становить до $50 000 на рік для середнього проєкту. Вивільняється час інженерів для більш цінних завдань. Рішення підходить для LLM prompt management у великих компаніях з високими вимогами до безпеки.

Як ми забезпечуємо версіонування та відкочування?

Схема даних заснована на PostgreSQL. Наша реалізація PostgreSQL prompt registry забезпечує цілісність даних. Кожна версія промпту захищена SHA256-хешем — дублікати виключені. При деплої створюється запис у prompt_deployments з посиланням на попередню версію (rollback_of). Відкочування — один API-виклик.

-- PostgreSQL схема
CREATE TABLE prompts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name VARCHAR(255) NOT NULL,
  description TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  created_by VARCHAR(255) NOT NULL,
  tags TEXT[]
);

CREATE TABLE prompt_versions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_id UUID REFERENCES prompts(id),
  version_number INTEGER NOT NULL,
  content TEXT NOT NULL,
  content_hash VARCHAR(64) NOT NULL, -- SHA256
  model VARCHAR(100) NOT NULL,
  temperature FLOAT DEFAULT 0.0,
  max_tokens INTEGER DEFAULT 1000,
  variables JSONB DEFAULT '[]',
  metadata JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT NOW(),
  created_by VARCHAR(255) NOT NULL,
  UNIQUE(prompt_id, version_number)
);

CREATE TABLE prompt_deployments (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_version_id UUID REFERENCES prompt_versions(id),
  environment VARCHAR(50) NOT NULL, -- dev/staging/production
  deployed_at TIMESTAMPTZ DEFAULT NOW(),
  deployed_by VARCHAR(255) NOT NULL,
  is_active BOOLEAN DEFAULT TRUE,
  rollback_of UUID -- Посилання на попередню версію при відкочуванні
);

CREATE TABLE prompt_executions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_version_id UUID REFERENCES prompt_versions(id),
  executed_at TIMESTAMPTZ DEFAULT NOW(),
  input_variables JSONB,
  rendered_prompt TEXT,
  response TEXT,
  input_tokens INTEGER,
  output_tokens INTEGER,
  latency_ms INTEGER,
  cost_usd FLOAT,
  quality_score FLOAT -- Оцінка якості (якщо доступна)
);

Швидкий API на FastAPI

Ми використовуємо FastAPI для створення FastAPI prompt registry, що забезпечує високу продуктивність. Система витримує навантаження понад 10 000 запитів на секунду з p99 latency < 30 мс. Приклад створення версії та отримання останньої активної:

from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
import asyncpg

app = FastAPI(title="Prompt Registry API")

class PromptCreateRequest(BaseModel):
    name: str
    content: str
    model: str = "gpt-4o"
    temperature: float = 0.0
    description: str = None

@app.post("/prompts/{name}/versions")
async def create_version(
    name: str,
    request: PromptCreateRequest,
    db = Depends(get_db)
):
    content_hash = hashlib.sha256(request.content.encode()).hexdigest()
    existing = await db.fetchrow(
        "SELECT id FROM prompt_versions pv JOIN prompts p ON p.id = pv.prompt_id "
        "WHERE p.name = $1 AND pv.content_hash = $2",
        name, content_hash
    )
    if existing:
        raise HTTPException(400, "Identical prompt version already exists")
    version = await db.fetchrow("""
        INSERT INTO prompt_versions (prompt_id, version_number, content, content_hash, model, temperature)
        SELECT p.id, COALESCE(MAX(pv.version_number), 0) + 1, $2, $3, $4, $5
        FROM prompts p
        LEFT JOIN prompt_versions pv ON pv.prompt_id = p.id
        WHERE p.name = $1
        GROUP BY p.id
        RETURNING id, version_number
    """, name, request.content, content_hash, request.model, request.temperature)
    return {"version_id": str(version['id']), "version": version['version_number']}

@app.get("/prompts/{name}/latest")
async def get_latest(name: str, environment: str = "production", db = Depends(get_db)):
    prompt = await db.fetchrow("""
        SELECT pv.content, pv.model, pv.temperature, pv.variables, pv.version_number
        FROM prompt_versions pv
        JOIN prompt_deployments pd ON pd.prompt_version_id = pv.id
        JOIN prompts p ON p.id = pv.prompt_id
        WHERE p.name = $1 AND pd.environment = $2 AND pd.is_active = TRUE
        ORDER BY pd.deployed_at DESC
        LIMIT 1
    """, name, environment)
    if not prompt:
        raise HTTPException(404, f"No deployed prompt '{name}' in {environment}")
    return dict(prompt)

Python-клієнт для інтеграції

Для простоти використання ми пишемо клієнтську бібліотеку на Python. Вона кешує останню активну версію і підставляє змінні шаблону:

class PromptClient:
    def __init__(self, registry_url: str, api_key: str):
        self.url = registry_url
        self.headers = {"X-API-Key": api_key}
        self._cache = {}

    def get_and_render(self, name: str, variables: dict, environment: str = "production") -> str:
        cache_key = f"{name}:{environment}"
        if cache_key not in self._cache:
            resp = requests.get(
                f"{self.url}/prompts/{name}/latest",
                params={"environment": environment},
                headers=self.headers
            )
            self._cache[cache_key] = resp.json()
        template = self._cache[cache_key]['content']
        for var, value in variables.items():
            template = template.replace(f"{{{{{var}}}}}", str(value))
        return template

Версіонування промптів для compliance

Повна історія змін з SHA256-хешем та метаданими дозволяє за хвилини надати аудиторам звіт: який промпт, коли і ким був застосований. Наші клієнти з RegTech скорочують час аудиту з тижнів до годин. Кастомне рішення в 5 разів швидше впроваджує зміни порівняно з ручним оновленням мікросервісів. Інтеграція SSO для Prompt Registry — стандартна опція, яка спрощує audit trail.

Процес роботи

1. Аналіз — аудит поточних практик, вимог до автентифікації, compliance, обсягів. Визначаємо цільові метрики (p99 latency < 30 мс, throughput > 1000 rps).
2. Проєктування — схема БД, архітектура API, модель розгортання (Kubernetes, bare-metal).
3. Реалізація — розробка бекенду, клієнта, інтеграція з CI/CD (GitLab CI, GitHub Actions).
4. Тестування — unit, integration, load-тести (p99 latency заміряємо до 30 мс).
5. Деплой — розгортання на ваші оточення, документація, навчання команди.
6. Підтримка — SLA, моніторинг, доопрацювання за зворотним зв'язком.

Наші інженери володіють промпт інжинірингом і можуть налаштувати систему під будь-які бізнес-процеси.

Строки та що входить

Орієнтовно — від 4 до 8 тижнів залежно від складності інтеграції (SSO, кастомні метрики). Входить: робоча система, документація (API + адміністрування), навчання до 5 осіб, вихідний код, підтримка 1 місяць. Вартість розраховується індивідуально — зв'яжіться, оцінимо ваш проєкт.

Типовий результат після впровадження: швидкість розгортання змін зростає в 10 разів, кількість помилок при деплої знижується на 95%, час аудиту скорочується з тижнів до хвилин. Єдиний MLOps prompt registry стає ключовим компонентом MLOps-інфраструктури. Наш on-premise prompt registry забезпечує повний контроль даних.

Отримайте консультацію: розкажіть про свої завдання — ми запропонуємо рішення з урахуванням ваших data governance та budget. Замовте попередній аналіз через форму на сайті.