Many-Shot In-Context Learning

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

Many-shot нужен, когда:

• 3-5 примеров уже недостаточно;
• у вас есть хороший размеченный набор;
• поведение надо быстро менять без дообучения;
• стоимость длинного контекста приемлема или компенсируется caching.

Классифицируй тикет поддержки. Ниже 150 размеченных примеров по категориям billing, technical, compliance, access, feature_request. Используй ту же логику.

[...150 примеров...]

Тикет: «Сотрудник уволился, нужно срочно отозвать доступ к админке и выгрузкам»

Many-shot полезен, когда few-shot уже не удерживает все нужные edge-cases, а полноценный fine-tuning ещё рано или невыгодно делать.

Когда many-shot оправдан

Many-shot хорошо работает там, где важна не общая эрудиция модели, а локальная калибровка на вашем распределении задач.

Many-shot особенно интересен там, где:

• examples уже существуют;
• distribution стабилен;
• хочется быстро менять поведение без retraining loop;
• input cost можно amortize через caching.

Когда many-shot уже не лучший выбор

Many-shot проигрывает, если:

• знания должны быть свежими и внешними -> лучше RAG;
• поведение нужно закрепить надолго на больших объёмах -> смотрите в fine-tuning;
• нужен strict schema output -> добавляйте structured outputs;
• latency и input-cost критичны -> длинный контекст может быть слишком дорогим.

То есть many-shot — это хороший "средний слой", но не конечная точка всех production-систем.

Главный trade-off

Главный operational вопрос здесь не "можем ли мы поместить 200 примеров", а "окупается ли это против alternatives".

Как many-shot обычно строят в продакшене

В production many-shot обычно делают не как "запихнуть всё подряд", а так:

1. Собирают пул хороших размеченных примеров.
2. Чистят дубликаты и явные ошибки.
3. Делят на core examples и edge cases.
4. Либо кладут фиксированный набор в prompt prefix, либо динамически выбирают top-k похожих примеров.
5. Кэшируют стабильный префикс.

Часто самый выигрышный режим — гибрид:

• стабильный core prefix;
• плюс небольшая динамическая добавка релевантных примеров под текущий запрос.

Fixed many-shot vs dynamic selection

Фиксированный набор проще operationally. Dynamic selection обычно точнее, но сложнее в поддержке.

Примеры

Many-shot для support triage

Ниже 80 размеченных примеров support triage. Используй те же категории и ту же логику эскалации.

[...examples...]

Новый тикет: «Нам нужен экспорт всех логов аудита за последние 90 дней для проверки комплаенса»

Many-shot для brand rewrite

Ниже 60 пар 'до -> после' для нашего tone of voice. Перепиши новый текст в том же стиле.

[...examples...]

До: «Мы выпустили обновление, которое улучшает навигацию в интерфейсе и ускоряет работу системы»

Many-shot для rubric judging

Ниже 120 размеченных примеров оценки customer replies по шкале weak / acceptable / strong.

[...examples...]

Новый ответ: «Спасибо, мы рассмотрим ваш запрос позже»

Где many-shot особенно выгоден

Many-shot часто выигрывает там, где:

• есть качественный labeled set;
• deployment нужен быстро;
• бизнес-логика часто меняется;
• команда ещё не готова к fine-tuning pipeline.

Там это может быть лучшим промежуточным решением на месяцы, а не на дни.

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

Dynamic example selection

def build_many_shot_prompt(query, example_store, k=40):
    """
    Псевдокод: вместо фиксированного набора выбираем
    релевантные примеры под текущий запрос.
    """
    selected = semantic_search(query, example_store, top_k=k)

    prefix = "Используй категории и логику из примеров ниже.\n\n"
    examples_text = "\n\n".join(
        f"INPUT: {ex['input']}\nOUTPUT: {ex['output']}"
        for ex in selected
    )

    return f"{prefix}{examples_text}\n\nINPUT: {query}\nOUTPUT:"

Почему caching меняет economics

Если большой блок примеров стабилен между запросами, provider-side prompt caching сильно уменьшает стоимость repeated calls. Поэтому many-shot в 2026 часто считают уже не "слишком дорогим всегда", а "дорогим без reuse".

Core + edge-case layout

def compose_many_shot(core_examples, edge_examples):
    return core_examples + edge_examples

На практике лучше держать:

• core_examples как стабильный cacheable prefix;
• edge_examples как динамическую часть под конкретный кейс.

Когда сравнивать с fine-tuning

def should_compare_with_finetuning(num_examples, request_volume):
    return num_examples > 100 and request_volume > 10000

Это не строгая формула, но полезная эвристика: если examples много и трафик большой, economics already start resembling a finetune decision.

Operational rule

Сравнивайте три режима на eval:

• few-shot;
• many-shot + caching;
• fine-tuning.

На surprisingly большом числе задач выигрывает именно второй вариант: без обучения, но с хорошим набором примеров и кэшируемым префиксом.