TL;DR
Retrieval-augmented few-shot prompting — техника, где вместо случайных примеров в промпт добавляются семантически похожие на вашу задачу. Каждый пример из базы превращается в вектор через embedding-модель, при новом запросе ищутся самые близкие по смыслу через cosine similarity, и топ-K попадают в промпт. В оригинале использовали ChromaDB и gemini-embedding-001, но принцип можно эмулировать прямо в чате.
Few-shot промптинг очень чувствителен к качеству примеров. Случайная выборка даёт нестабильные результаты — то попадётся релевантный пример, то совсем не в тему. В сложных задачах (multi-label классификация, несколько критериев одновременно) это особенно больно: модель видит пример про одно, а должна решить про другое. Разброс большой, воспроизводимость низкая.
Retrieval-augmented подход даёт стабильно лучшие результаты: F1 74% при 20 примерах против 66% у случайной выборки и 36% у zero-shot. Даже обошёл fine-tuned Gemini (59%), хотя и уступил специализированному CodeBERT (91%). Секрет в семантической близости — модель видит примеры, которые действительно похожи на текущую задачу по структуре и контексту.
Схема метода
ПОДГОТОВКА (один раз):
1. Берёшь базу примеров с правильными ответами
2. Превращаешь каждый в embedding-вектор (gemini-embedding-001 или аналог)
3. Сохраняешь в vector DB (ChromaDB, Pinecone, etc.)
ПРИМЕНЕНИЕ (каждый раз):
1. Новая задача → embedding-вектор
2. Поиск топ-K самых похожих из базы (cosine similarity)
3. Строишь промпт: K похожих примеров + новая задача
4. Модель выдаёт ответ
Пример применения (эмуляция в чате)
Задача: Классифицировать отзыв о доставке еды по нескольким проблемам одновременно (опоздание, качество еды, курьер, упаковка). У тебя есть 50 размеченных примеров — хочешь для нового отзыва подобрать 5 самых похожих, чтобы показать модели паттерн.
Промпт:
У меня есть база из 50 размеченных отзывов о доставке еды.
Каждый отзыв может иметь несколько проблем: "опоздание", "холодная еда", "грубый курьер", "плохая упаковка".
Вот новый отзыв для анализа:
"Курьер приехал через 2 часа, борщ был ледяной, крышка слетела, всё разлилось. Позвонила в поддержку — там нахамили."
Из моей базы выбери 5 самых СЕМАНТИЧЕСКИ ПОХОЖИХ примеров (по типу проблем, тону, структуре), которые помогут понять паттерн для классификации.
[Дальше вставляешь свои 50 примеров с метками]
Результат:
Модель проанализирует все 50 примеров и выберет топ-5, которые похожи по: - Комбинации проблем (опоздание + качество еды + упаковка) - Негативному тону - Упоминанию службы поддержки
Потом берёшь эти 5 отобранных примеров и строишь few-shot промпт для классификации новых отзывов. Получается двухшаговый процесс: сначала отбор похожих, потом использование их как few-shot.
Почему это работает
Слабость LLM: В few-shot промптинге модель учится на примерах "на лету" — но если примеры не похожи на текущую задачу, она цепляется не за те паттерны. Случайная выборка даёт то супер-релевантный пример, то совсем левый. Результат нестабилен.
Сильная сторона LLM: Модели отлично переносят паттерны из похожих примеров на новую задачу, если видят правильную аналогию. Чем ближе пример по смыслу и структуре — тем точнее применение.
Как метод использует это: Embedding-поиск находит примеры с похожей семантикой (не просто словами, а смыслом). Модель видит 5-20 случаев, которые реально близки к текущей задаче — и применяет именно тот паттерн, который нужен. Стабильность растёт, разброс падает.
Рычаги управления: - Количество примеров (K): 1-5 для простых задач (экономия токенов), 10-20 для сложных multi-label (больше паттернов). В исследовании оптимум был 10-20. - База примеров: Чем разнообразнее база — тем выше шанс найти похожий кейс. Если база узкая — retrieval не даст преимущества. - Критерий похожести: Можно попросить модель учитывать разные аспекты — структуру, тон, длину, комбинацию тегов.
Шаблон промпта (эмуляция в чате)
Шаг 1: Отбор похожих примеров
У меня есть база из {N} примеров с метками по задаче {описание_задачи}.
Новая задача для анализа:
{твоя_задача}
Из базы ниже выбери {K} самых СЕМАНТИЧЕСКИ ПОХОЖИХ примеров — учитывай {критерии_похожести: структуру / тон / комбинацию меток / контекст}.
БАЗА ПРИМЕРОВ:
{пример_1}: метки {метки_1}
{пример_2}: метки {метки_2}
...
{пример_N}: метки {метки_N}
Выведи номера и краткое объяснение почему выбрал.
Шаг 2: Few-shot классификация
Вот {K} примеров задачи "{описание_задачи}":
Пример 1:
Вход: {отобранный_пример_1}
Метки: {метки_1}
Пример 2:
Вход: {отобранный_пример_2}
Метки: {метки_2}
...
Теперь проанализируй новую задачу по тому же принципу:
Вход: {твоя_задача}
Метки:
Подстановка:
- {N} — размер твоей базы примеров (10-100)
- {K} — сколько примеров хочешь в промпте (5-20, оптимум 10-20 по исследованию)
- {описание_задачи} — что делаем (классификация отзывов, оценка резюме, разметка текста)
- {критерии_похожести} — на что обращать внимание при отборе
- {твоя_задача} — конкретный новый кейс для обработки
🚀 Быстрый старт — вставь в чат:
Вот шаблон Retrieval-Augmented Few-Shot. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: - Какая у тебя база примеров и сколько их? - Какие метки/категории используешь? - По каким критериям отбирать похожие (структура, тон, комбинация тегов)? - Сколько примеров показать в итоговом промпте?
Она возьмёт двухшаговый паттерн (отбор → few-shot) и настроит под твою задачу.
Ограничения
⚠️ Нужна база примеров: Метод работает только если у тебя есть размеченные примеры. Если базы нет — retrieval не поможет, останется только zero-shot.
⚠️ Качество базы решает: Если в базе мало разнообразия или примеры низкого качества — retrieval найдёт "лучшее из плохого". Garbage in, garbage out.
⚠️ Эмуляция в чате менее точна: Оригинальный метод использует embedding-векторы (математическая близость в 768-мерном пространстве). В чате модель оценивает похожесть "на глаз" — хуже, но рабочий вариант для начала.
⚠️ Проигрывает специализированному fine-tuning: CodeBERT, обученный на коде, дал 91% против 74% у retrieval-augmented промптинга. Если есть ресурсы на обучение — fine-tuning специализированной модели даст лучший результат. Но требует GPU, данные, поддержку.
⚠️ Токены: 20 примеров в промпте = много токенов. Для длинных документов может упереться в лимит контекста. Уменьши K или используй короткие примеры.
Как исследовали
Исследователи взяли датасет функций на C с метками уязвимостей (CWE-119, CWE-120, CWE-469, CWE-476 — buffer overflow, pointer errors и т.д.). Задача multi-label: одна функция может содержать несколько типов багов одновременно. Протестировали на Gemini-1.5-Flash три стратегии промптинга: (1) random few-shot — случайные примеры из базы, (2) retrieval-augmented — топ-K похожих через cosine similarity на embedding-векторах, (3) retrieval-based labeling — просто взять метки от похожих примеров без запроса к LLM.
Каждую стратегию прогнали с 1 до 20 shots (количество примеров в промпте). Измеряли жёсткие метрики: subset accuracy (все метки точно совпали), F1 score, partial match (хотя бы часть меток верна).
Главная находка: Retrieval-augmented стабильно растёт с увеличением shots и к 10-20 примерам даёт F1 71-74%. Random few-shot тоже растёт, но медленнее — 65-66%. А retrieval-based labeling (без LLM, просто метки от соседей) деградирует после 1 shot: при k=1 даёт 64% precision, при k=10 падает до 43%. Почему? При одном соседе часто угадывает правильно, но при 10 соседях начинает тупо объединять все их метки — получается overprediction (recall 98%, но precision в пропасть).
Сравнили с zero-shot (F1 36%) и fine-tuning. Fine-tuned Gemini через Vertex AI дал F1 59% — хуже чем retrieval-augmented промптинг! Но fine-tuned CodeBERT (маленькая модель, специально обученная на коде) выдал F1 91% — clear winner по точности, но требует GPU, обучение 10 эпох, поддержку инфры.
Инсайт для практики: Семантическая близость примеров — не мелочь, а критический фактор для few-shot. Случайные примеры дают разброс, retrieval — стабильность. Если нет ресурсов на fine-tuning специализированной модели, retrieval-augmented промптинг — золотая середина между zero-shot и полноценным дообучением.
Адаптации
🔧 Техника: Гибридный подход — retrieval + reasoning
Исследование показало что retrieval-based labeling (без LLM) проигрывает из-за overprediction при многих соседях. Но можно скомбинировать: retrieval находит K похожих, а потом просишь модель не просто скопировать их метки, а объяснить почему каждая метка применима к новой задаче.
Вот 5 похожих отзывов с метками: [примеры] Новый отзыв: [текст] Для каждой метки из похожих примеров объясни: 1. Применима ли она к новому отзыву? Почему да/нет? 2. Если применима — какие конкретно фразы это подтверждают? Итоговые метки:Получаешь точность retrieval + рассуждения LLM — модель не тупо копирует метки соседей, а фильтрует через логику.
🔧 Техника: Разнообразие вместо топ-K
Топ-K самых похожих могут быть слишком одинаковыми — все про один кейс. Попроси модель выбрать разнообразные примеры, покрывающие разные паттерны:
Из базы выбери 10 примеров для few-shot: - 5 самых ПОХОЖИХ на новую задачу (по смыслу, структуре) - 5 РАЗНООБРАЗНЫХ (разные комбинации меток, разные контексты) Цель: показать модели и прямые аналогии, и граничные случаи.Это помогает если задача на стыке категорий — модель увидит не только "точное попадание", но и соседние паттерны.
Ресурсы
Retrieval-Augmented Few-Shot Prompting Versus Fine-Tuning for Code Vulnerability Detection
Fouad Trad, Ali Chehab (Electrical and Computer Engineering, American University of Beirut)