Boundary Cases: как LLM разделяют данные на лёгкие и сложные для точной фильтрации

ШАГ 1: Zero-shot фильтрация → четыре категории по уверенности
ШАГ 2: Few-shot для граничных → улучшение точности примерами 
ШАГ 3: Ручная проверка → только граничные случаи

Все шаги можно выполнить в одном чате последовательными запросами.

Задача: У вас 150 резюме на позицию Middle Python-разработчик в Яндексе. Нужно отобрать кандидатов с опытом 3+ года в Python и Django.

Промпт:

Оцени каждое резюме по критериям:
1. Опыт работы с Python 3+ года
2. Опыт работы с Django

Для каждого резюме дай:
- Решение: ВКЛЮЧИТЬ / ИСКЛЮЧИТЬ
- Категория: ЛЕГКОЕ ВКЛЮЧЕНИЕ / ГРАНИЧНОЕ ВКЛЮЧЕНИЕ / ГРАНИЧНОЕ ИСКЛЮЧЕНИЕ / ЛЕГКОЕ ИСКЛЮЧЕНИЕ
- Уверенность: 0-100%
- Обоснование: почему такое решение

[вставить список резюме]

Результат:

Модель разделит резюме на четыре группы. Легкие включения (явно указано «3 года Python + Django») и легкие исключения (нет Python или junior) — высокая точность. Граничные случаи (например, «2.5 года Python, упоминание Django в pet-проекте» или «Python указан в skills, но опыт не расшифрован») — нужна ручная проверка. Вы проверяете вручную только граничные случаи вместо всех резюме — обычно это 15-20% от общего объёма.

LLM хорошо распознают явные сигналы в тексте — когда критерий прямо указан. Модель анализирует текст и находит прямые упоминания: «3 года опыта в Python», «работал с Django». Это легкие включения.

Модель также хорошо распознает отсутствие сигналов — когда критерий явно не выполнен. Если в резюме нет Python или указан junior-уровень — это легкое исключение.

Но модель путается с неявными сигналами и контекстом. Например, если Django упомянут в списке технологий, но не в опыте работы — это граничный случай. Модель не всегда понимает разницу между «использовал в pet-проекте» и «коммерческий опыт». Именно здесь нужен человек.

Категоризация по уверенности помогает оптимизировать время: вместо проверки всех резюме вы проверяете только граничные случаи. LLM берёт на себя очевидные решения, вы — сложные.

Оцени каждый элемент по критериям:
{критерии фильтрации}

Для каждого элемента дай:
- Решение: ВКЛЮЧИТЬ / ИСКЛЮЧИТЬ
- Категория: ЛЕГКОЕ ВКЛЮЧЕНИЕ / ГРАНИЧНОЕ ВКЛЮЧЕНИЕ / ГРАНИЧНОЕ ИСКЛЮЧЕНИЕ / ЛЕГКОЕ ИСКЛЮЧЕНИЕ
- Уверенность: 0-100%
- Обоснование: почему такое решение

{список элементов для фильтрации}

Плейсхолдеры:

• {критерии фильтрации} — чёткие критерии включения/исключения
• {список элементов} — данные для фильтрации (резюме, отзывы, идеи, статьи)

Для улучшения точности на граничных случаях:

Добавь после критериев:

Примеры правильных решений:

ВКЛЮЧИТЬ:
{пример 1 - что включать}
{пример 2 - что включать}

ИСКЛЮЧИТЬ:
{пример 3 - что исключать}
{пример 4 - что исключать}

⚠️ Масштаб: В чате можно обработать 20-50 элементов комфортно. Для сотен и тысяч элементов нужны API или специализированные инструменты.

⚠️ Граничные случаи: LLM ошибается на граничных случаях — где критерий упомянут неявно или в другом контексте. Эти случаи требуют ручной проверки.

⚠️ Субъективные критерии: Работает для объективных критериев («3+ года опыта», «упоминание Django»). Для субъективных оценок («креативное мышление», «культурный фит») точность ниже.

Исследователи взяли 137 научных статей из systematic review по time pressure в software engineering. Запустили несколько LLM (через OpenRouter) с критериями включения/исключения. Модели должны были решить — релевантна ли статья для обзора.

Результат удивил: модели НЕ ошибались случайно по всему датасету. Все ошибки сконцентрировались в граничных случаях. Из 137 статей: 6 легких включений — ошибок 0, 107 легких исключений — ошибок 0, 24 граничных случая — все ошибки здесь.

Почему так? В легких случаях критерий явно выражен или явно отсутствует. Например, в статье про time pressure в разработке ПО прямо написано в абстракте: «time pressure is an important stress factor». Модель включает.

В граничных включениях критерий упомянут, но неявно — например, в разделе «findings suggest» написано «time pressure affects...», но не ясно, есть ли эмпирические данные. Модель часто исключает, хотя надо включить.

В граничных исключениях критерий упомянут в мотивационной части («problems arise due to time pressure»), но сама статья про другое (про technical debt prediction). Модель часто включает, хотя надо исключить.

Инсайт: LLM отлично фильтрует очевидное, но путается в контексте. Поэтому логично — дать модели очевидные случаи, а сложные решения оставить человеку. Few-shot примеры помогают модели лучше различать граничные случаи, но не решают проблему полностью.

💡 Адаптация для приоритизации:

Вместо жёсткой категоризации попроси модель отсортировать по вероятности релевантности:

Оцени каждое резюме по критериям и дай оценку релевантности 0-100.

Отсортируй резюме от наиболее релевантных к наименее релевантным.

Критерии:
- 3+ года Python
- Опыт с Django

{список резюме}

Начни просматривать с топа. Установи порог отсечки — например, 10 нерелевантных подряд. Это работает для rapid screening, когда скорость важнее полноты.

💡 Адаптация для множественных критериев:

Для сложных задач с несколькими критериями попроси оценку по каждому критерию отдельно:

Оцени каждое резюме по критериям:

1. Технические навыки (Python 3+, Django): ПОДХОДИТ / НЕ ПОДХОДИТ / НЕЯСНО
2. Уровень (Middle+): ПОДХОДИТ / НЕ ПОДХОДИТ / НЕЯСНО 
3. Релевантный опыт (финтех/e-commerce): ПОДХОДИТ / НЕ ПОДХОДИТ / НЕЯСНО

Общее решение: ВКЛЮЧИТЬ / ИСКЛЮЧИТЬ / ПРОВЕРИТЬ ВРУЧНУЮ

{список резюме}

Это помогает увидеть почему резюме попало в граничный случай — может, один критерий явно выполнен, а другой неясен.

🔧 Техника: несколько моделей → снижение ошибок на граничных случаях

Для критически важных решений попроси оценку у нескольких моделей:

# В ChatGPT (GPT-4):
[твой промпт с критериями]

# В Claude:
[тот же промпт]

# Сравни результаты:
Где модели согласны - скорее всего правильно.
Где расходятся - граничный случай, нужна ручная проверка.

Если обе модели категоризируют элемент одинаково (оба «лёгкое включение» или оба «лёгкое исключение») — высокая уверенность. Если категоризация разная — это граничный случай, требующий вашего внимания.

«AISysRev - LLM-based Tool for Title-abstract Screening» (ICSE 2026)

Инструмент: https://github.com/EvoTestOps/AISysRev

Aleksi Huotala, Miikka Kuutila, Olli-Pekka Turtio, Mika Mäntylä (University of Helsinki)