Active Prompting

Суть в двух словах

Active Prompting = measure uncertainty -> pick hard cases -> add them as examples.

Техника особенно полезна для:

• классификации с неоднозначными случаями;
• reasoning-задач, где модель то права, то нет;
• любых eval-driven pipelines, где examples можно подбирать автоматически.

Почему это лучше случайного отбора

Случайные примеры часто учат модель тому, что она уже умеет. Active Prompting смещает few-shot budget в сторону сложных, полезных и boundary-кейсов.

Выбери для few-shot только те примеры, где baseline-модель давала высокий disagreement или систематические ошибки. Не включай очевидные cases.

Как обычно выглядит pipeline

В чём реальная сила техники

Active Prompting важен тем, что переводит few-shot из категории:

"какие примеры мне кажутся хорошими?"

в категорию:

"какие примеры реально закрывают слабые места модели?"

То есть prompt engineering становится data problem.

Почему Active Prompting особенно полезен командам с живыми логами

В реальном продукте hard cases появляются не из теории, а из production traffic:

• route систематически путает boundary labels;
• пользователи пишут кривые edge-case inputs;
• модель нестабильна на похожих, но не идентичных сценариях.

Active Prompting полезен тем, что превращает эти failure cases в материал для улучшения few-shot слоя. Это делает его хорошим мостом между evals, logs и prompt maintenance.

Практическая версия 2026

В production Active Prompting обычно выглядит не как академический цикл с CoT sampling, а как более прагматичный процесс:

• собираете ошибки из logs и evals;
• ищете cases с высоким disagreement;
• добавляете их в curated example set;
• регулярно обновляете набор по drift-сигналам.

То есть техника становится частью prompt maintenance, а не только paper-only методом.

Что считать хорошим active example

Полезный active example:

• часто даёт ошибку;
• важен для бизнеса;
• хорошо размечен;
• покрывает boundary condition, а не просто редкий казус.

Бесполезный active example:

• уникальный, но нерепрезентативный;
• сам размечен сомнительно;
• сложный, но без business value;
• уже покрыт другими demonstrations.

Где техника особенно окупается

Лучшие сценарии:

• ticket triage;
• moderation edge cases;
• compliance classification;
• product taxonomy classification;
• support routing;
• reasoning tasks с recurring failure patterns.

Менее полезна техника:

• для open-ended writing;
• если нет нормального eval set;
• если задача слишком изменчива;
• если examples быстро устаревают и не поддерживаются.

Это особенно важно: без стабильного eval и owner-а для example pool техника быстро деградирует в набор старых кейсов, которые уже не отражают текущий traffic.

Сравнение с соседними подходами

Частые ошибки

Ещё типичные ошибки:

• uncertainty proxy шумная и нестабильная;
• hard cases не проходят ручную валидацию;
• example set растёт бесконтрольно;
• никто не проверяет drift и устаревание примеров.

Когда лучше взять другой подход

Если основная проблема не в boundary examples, а в:

• wording prompt-а -> OPRO;
• необходимости похожих примеров под конкретный запрос -> retrieval-based examples;
• нехватке внешних знаний -> RAG;
• строгом формате ответа -> schema/tool constraints,

то Active Prompting сам по себе не решит задачу.

Техническая реализация

def uncertainty_score(outputs: list[str]) -> float:
    """
    Чем больше расхождение между несколькими прогонами,
    тем выше кандидат на active-prompt example.
    """
    unique = len(set(outputs))
    return unique / len(outputs)

def select_active_examples(dataset, llm, n=8):
    scored = []
    for item in dataset:
        outputs = [llm(item["input"]) for _ in range(5)]
        scored.append((uncertainty_score(outputs), item))
    scored.sort(reverse=True, key=lambda x: x[0])
    return [item for _, item in scored[:n]]

Practical upgrades

• вместо повторных generation можно использовать historical failures;
• вместо uncertainty-only можно учитывать business severity;
• вместо fixed set можно хранить active examples в vector store и подбирать top-k под запрос;
• активные examples стоит versionировать как data asset.

Что полезно мерить

• uplift vs static few-shot;
• hard-case accuracy;
• drift in active example pool;
• prompt token budget vs gain.

Иначе Active Prompting остаётся красивой идеей без operational value.

Что хранить как data asset

Полезно versionировать:

• active example set;
• source of each example;
• uncertainty / disagreement score;
• business severity;
• validation status.

Тогда few-shot examples становятся не случайным текстом в prompt, а нормальным поддерживаемым data layer.