LogSyn: Few-Shot промптинг для структурированной экстракции данных из текста

ОДИН ЗАПРОС:
[Инструкция] + [2-3 примера вход→выход] + [Новый текст] 
→ JSON с заданной структурой

Ключевые параметры:

• Температура 0.1 — минимум вариативности, максимум консистентности
• 2-3 примера — достаточно для паттерна, не перегружает контекст
• JSON-схема в примерах — модель копирует структуру

Задача: Менеджер интернет-магазина получает сотни отзывов в день. Нужно автоматически разбирать их на: проблема, что хочет клиент, категория (доставка/качество/сервис/другое).

Промпт:

Ты — аналитик клиентского опыта. Преобразуй отзыв в структурированный JSON.

Формат вывода:
{
  "проблема": "краткое описание проблемы",
  "ожидание_клиента": "чего хочет клиент",
  "категория": "Доставка | Качество товара | Сервис | Другое"
}

ПРИМЕРЫ:

Отзыв: "Заказала платье на день рождения, пришло через 2 недели вместо обещанных 3 дней. Праздник прошёл, платье не пригодилось. Верните деньги!"
{
  "проблема": "Критическая задержка доставки — 2 недели вместо 3 дней",
  "ожидание_клиента": "Возврат денег",
  "категория": "Доставка"
}

Отзыв: "Кроссовки развалились через неделю, подошва отклеилась. За такие деньги ожидал лучшего качества."
{
  "проблема": "Дефект товара — подошва отклеилась через неделю",
  "ожидание_клиента": "Качественный товар за уплаченную цену",
  "категория": "Качество товара"
}

Отзыв: "Консультант в чате нагрубил, когда спросила про возврат. Никогда больше не куплю у вас."
{
  "проблема": "Грубость консультанта при обращении по возврату",
  "ожидание_клиента": "Вежливое обслуживание",
  "категория": "Сервис"
}

НОВЫЙ ОТЗЫВ:
"Получила посылку — внутри чужой заказ. Позвонила на горячую линию, ждала 40 минут, так и не дозвонилась. В итоге писала в Телеграм, там ответили только через сутки."

Выдай только JSON, без пояснений.

Результат: Модель выдаст JSON со структурой как в примерах. Поле «проблема» опишет путаницу с заказом и проблемы с поддержкой, «ожидание_клиента» — быстрое решение вопроса, «категория» — скорее всего «Сервис» или комбинация. Формат будет идентичен примерам.

Слабость LLM: Без примеров модель интерпретирует задачу по-своему. Попросишь «структурировать отзыв» — получишь что угодно: маркированный список, свободный текст, JSON с произвольными полями. Каждый запрос — лотерея.

Сильная сторона LLM: Модели отлично копируют паттерны. Покажи 2-3 примера с чётким форматом — она воспроизведёт его с высокой точностью. Это называется in-context learning: модель «учится» на примерах прямо в промпте, без дообучения.

Как метод это использует: Few-shot промпт создаёт «шаблон ожидания». Модель видит: вот вход, вот выход в JSON, вот категории. Когда приходит новый текст — она подставляет его в тот же паттерн. Температура 0.1 убирает креативность — модель выбирает наиболее вероятный следующий токен, что даёт консистентный формат.

Рычаги управления:

• Количество примеров — 2-3 для простых задач, 4-5 для сложных классификаций
• Разнообразие примеров — если есть редкие категории, обязательно включи пример для них
• Температура — 0.1 для стабильности формата, выше если нужна вариативность в формулировках
• «Только JSON» — убирает разговорную обёртку, чистый вывод

Ты — {роль}. Преобразуй {тип_входных_данных} в структурированный JSON.

Формат вывода:
{
  "{поле_1}": "{описание_поля_1}",
  "{поле_2}": "{описание_поля_2}",
  "{поле_категории}": "{категория_1} | {категория_2} | {категория_3}"
}

ПРИМЕРЫ:

{тип_входных_данных}: "{пример_входа_1}"
{
  "{поле_1}": "{значение_1}",
  "{поле_2}": "{значение_2}",
  "{поле_категории}": "{категория}"
}

{тип_входных_данных}: "{пример_входа_2}"
{
  "{поле_1}": "{значение_1}",
  "{поле_2}": "{значение_2}",
  "{поле_категории}": "{категория}"
}

{тип_входных_данных}: "{пример_входа_3}"
{
  "{поле_1}": "{значение_1}",
  "{поле_2}": "{значение_2}",
  "{поле_категории}": "{категория}"
}

НОВЫЙ {тип_входных_данных}:
"{новый_вход}"

Выдай только JSON, без пояснений.

Что подставлять:

• {роль} — кто обрабатывает данные (аналитик, редактор, HR)
• {тип_входных_данных} — что на входе (отзыв, резюме, тикет)
• {поле_N} — какие данные извлекаем
• {поле_категории} — классификация с перечислением опций через |
• Примеры — реальные данные из твоей задачи, минимум 2-3 штуки

⚠️ Чувствительность к примерам: Точность может упасть на 24% от неудачных примеров. Если результаты нестабильны — экспериментируй с другими примерами.

⚠️ Редкие категории: Если категория редкая и не представлена в примерах — модель будет ошибаться именно на ней. Включай примеры для всех важных категорий.

⚠️ Жаргон и аббревиатуры: Если в данных специфическая терминология — добавь расшифровку в промпт или используй примеры с этими терминами.

Команда взяла 6,169 записей из реальных журналов техобслуживания авиации — каждая запись содержала описание проблемы и принятые меры. Задача: превратить свободный текст в структурированный JSON с категорией из 8-уровневой онтологии.

Сравнили четыре подхода: few-shot (LogSyn), zero-shot (без примеров), rule-based NER (регулярки + spaCy), и fine-tuned BERT. Few-shot победил по всем метрикам: accuracy 90.2% против 89% у zero-shot, но главное — macro-F1 вырос с 0.69 до 0.76 (+10%). Macro-метрики важны, потому что считают все категории равноправно — даже редкие.

Интересная находка: разброс точности между разными промптами — 24%. Это значит, что сам по себе подход «добавь примеры» не гарантирует успех — важно какие примеры. Исследователи также использовали LLM-as-a-Judge для масштабной оценки: вторая модель ставила оценки 1-5 за точность. Средний балл — 4.7 из 5. Это подтверждает, что few-shot даёт семантически корректные результаты, а не просто формально правильный JSON.

Problem: #2 & 4 CYL ROCKER COVER GASKETS ARE LEAKING.
Action Taken: REMOVED & REPLACED GASKETS.

Output:
{
  "summary_problem": "Rocker cover gasket leaks in cylinders 2 and 4 were reported.",
  "summary_action": "The leaking rocker cover gaskets were replaced on cylinders 2 and 4.",
  "failed_component": "Rocker Cover Gaskets (Cyl 2 & 4)",
  "category": "Powerplant - Sealing & Gaskets"
}

Контекст: Исследователи использовали этот формат для классификации авиационных логов в двухуровневую онтологию (система → подсистема). Температура 0.1 обеспечивала стабильность JSON-структуры.

💡 Адаптация для HR-скрининга резюме:

Ты — HR-аналитик. Преобразуй описание опыта из резюме в структурированный JSON.

Формат вывода:
{
  "ключевые_навыки": "список через запятую",
  "уровень": "Junior | Middle | Senior",
  "сфера": "Разработка | Маркетинг | Продажи | Аналитика | Другое",
  "красные_флаги": "если есть — что настораживает"
}

ПРИМЕРЫ:

Опыт: "3 года работал тимлидом в Яндексе, управлял командой из 8 человек, запустили 2 продукта с нуля. До этого 2 года разработчиком в стартапе."
{
  "ключевые_навыки": "управление командой, запуск продуктов, разработка",
  "уровень": "Senior",
  "сфера": "Разработка",
  "красные_флаги": "нет"
}

Опыт: "Полгода стажировался в маркетинге, вёл соцсети компании. Сейчас ищу первую работу."
{
  "ключевые_навыки": "SMM, базовый маркетинг",
  "уровень": "Junior",
  "сфера": "Маркетинг",
  "красные_флаги": "нет коммерческого опыта"
}

НОВЫЙ ОПЫТ:
"{вставить текст из резюме}"

Выдай только JSON, без пояснений.

🔧 Техника: иерархическая категоризация

Если категорий много — используй двухуровневую структуру как в оригинале. Вместо плоского списка «Доставка | Качество | Сервис» делай «Система - Подсистема»: «Логистика - Сроки доставки», «Логистика - Состояние упаковки», «Продукт - Дефект», «Продукт - Несоответствие описанию». Это помогает модели точнее классифицировать и даёт тебе более гранулярную аналитику.

Работа: LogSyn: A Few-Shot LLM Framework for Structured Insight Extraction from Unstructured General Aviation Maintenance Logs (INCOM 2026)

Авторы: Devansh Agarwal, Maitreyi Chatterjee (Cornell University), Biplab Chatterjee (AI Airport Services Ltd)

Датасет: Aircraft Historical Maintenance Dataset (2012–2017) — Kaggle

Ключевые референсы: Brown et al., 2020 — Language Models are Few-Shot Learners (GPT-3 paper)