LLM-Based Document Filtering: структурированная оценка по критериям

ШАГ 1: Формулировка критериев
→ Превратить inclusion/exclusion criteria в набор прямых утверждений
→ Каждое правило — либо ДА, либо НЕТ, без двусмысленности

ШАГ 2: Структура промпта
→ Роль эксперта + контекст
→ Инструкции: список правил (в исследовании — 13 правил)
→ Критерии ответа: когда YES/NO/DOUBT
→ Шаблон вывода: формат с уверенностью
→ Few-shot примеры ответов

ШАГ 3: Оценка документа
→ Загрузить документ (PDF через RAG / или напрямую в Claude)
→ Применить все правила
→ Вывести решение + уверенность + обоснование

В исследовании: автоматический pipeline через API
В чате: можно вручную на отдельных документах

Задача: Ты выбираешь подрядчика для разработки сайта. Получил 15 коммерческих предложений. Нужно быстро отсеять неподходящие по жёстким критериям (бюджет, сроки, стек технологий), оставив 3-5 для детального анализа.

Промпт:

Контекст: Ты эксперт по оценке коммерческих предложений от веб-студий. Помоги отобрать подрядчиков для разработки корпоративного сайта.

Инструкции: Оцени каждое предложение по следующим 8 правилам:

ДОЛЖНО выполняться:
- Правило 1: Бюджет не превышает 500,000 рублей
- Правило 2: Срок разработки не более 2 месяцев
- Правило 3: В портфолио есть корпоративные сайты (не лендинги)
- Правило 4: Используют современный стек (React/Vue или аналоги)
- Правило 5: Предлагают техподдержку после запуска

НЕ ДОЛЖНО быть:
- Правило 6: Предложение НЕ является типовым шаблоном без деталей проекта
- Правило 7: Компания НЕ работает только с готовыми конструкторами сайтов
- Правило 8: В предложении НЕТ признаков автоматической генерации текста (явные ошибки, несвязный текст)

Критерии ответа:
- YES — если предложение удовлетворяет всем 8 правилам
- NO — если нарушает хотя бы одно правило
- DOUBT — если информации недостаточно для однозначного решения

Шаблон вывода: 
'<решение>'; "Уверенность = <0-100%>"; '<обоснование>'

Примеры:
- YES; Уверенность = 92%; Бюджет 450к, срок 6 недель, есть кейсы с React, предлагают 3 месяца поддержки.
- DOUBT; Уверенность = 88%; Бюджет подходит, но не указан конкретный стек технологий.
- NO; Уверенность = 95%; Бюджет 750к — превышает лимит в 500к.

[Прикрепить PDF с коммерческим предложением]

Результат:

Модель выдаст оценку в указанном формате: решение (YES/NO/DOUBT), процент уверенности и краткое обоснование, ссылаясь на конкретные правила. Для каждого из 15 предложений получишь структурированную оценку, которая покажет: какие идут в shortlist (YES), какие требуют уточнения (DOUBT), какие сразу отклонить (NO). Обоснование поможет понять, по какому именно критерию отклонено предложение.

LLM плохо справляются с расплывчатыми критериями — когда говоришь "оцени качество" или "подходит ли этот кандидат", модель додумывает сама и результаты непредсказуемы. Добавь сюда противоречивые формулировки (инструкция "отклони если X" → но описание "документ является X"), и модель путается ещё сильнее. Двусмысленность в инструкциях заставляет LLM угадывать твои намерения.

Но LLM отлично следуют чётким правилам типа "если-то" — особенно когда каждое правило проверяет один конкретный факт. Модель умеет: искать информацию в тексте, сопоставлять с условием, делать бинарный вывод (выполнено/не выполнено). Это базовая способность, которая работает стабильно. Чем конкретнее правило, тем меньше простор для интерпретации.

Метод использует эту сильную сторону через структурированный промпт: превращает размытый запрос ("отбери релевантные документы") в набор проверяемых утверждений. Каждое правило — это атомарная проверка факта. Роль эксперта задаёт контекст для интерпретации, примеры показывают формат ответа, шаблон вывода фиксирует структуру. Многоуровневая оценка (YES/NO/DOUBT) честнее бинарной — модель может сказать "недостаточно данных" вместо того чтобы гадать.

Рычаги управления методом:

• Количество правил — в исследовании эволюция от 5 до 13 правил дала скачок точности. Для простых задач хватит 3-5, для сложных можно до 15-20. Больше правил = выше точность, но дольше обработка.
• Пороги уверенности — в исследовании: >92% = YES, <85% = NO, между = DOUBT. Можешь сдвинуть: строже (YES только при >95%) или мягче (YES при >85%) в зависимости от цены ошибки.
• Формулировка правил — прямые утверждения работают лучше двойных отрицаний. Вместо "документ НЕ должен НЕ содержать..." пиши "документ должен содержать...".
• Few-shot примеры — 2-3 примера достаточно. Если модель ошибается систематически — добавь пример с похожей ситуацией и правильным ответом.
• Формат вывода — можешь убрать процент уверенности (если не нужен), добавить обязательную цитату из документа (если хочешь видеть на что модель опирается), расширить обоснование до 2-3 предложений.

Контекст: Ты {роль эксперта в нужной области}. Помоги {описание задачи}.

Инструкции: Оцени {объект оценки} по следующим {N} правилам:

ДОЛЖНО выполняться:
- Правило 1: {конкретное утверждение}
- Правило 2: {конкретное утверждение}
- Правило 3: {конкретное утверждение}
[... остальные правила включения]

НЕ ДОЛЖНО быть:
- Правило {N-2}: {объект} НЕ {негативное условие}
- Правило {N-1}: {объект} НЕ {негативное условие}
- Правило {N}: {объект} НЕ {негативное условие}

Критерии ответа:
- YES — если {объект} удовлетворяет всем {N} правилам
- NO — если нарушает хотя бы одно правило
- DOUBT — если информации недостаточно для однозначного решения

Шаблон вывода: 
'<решение>'; "Уверенность = <0-100%>"; '<обоснование>'

Примеры:
- YES; Уверенность = {процент}%; {краткое обоснование через факты}
- DOUBT; Уверенность = {процент}%; {что именно неясно}
- NO; Уверенность = {процент}%; {какое правило нарушено}

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

Как заполнять:

• {роль эксперта} — кто должен оценивать (эксперт по найму, маркетолог, юрист, аналитик рынка)
• {описание задачи} — что нужно сделать (отобрать кандидатов, оценить коммерческие предложения, проверить договоры)
• {объект оценки} — что оцениваем (резюме, предложение, статья, отчёт)
• {N} — общее количество правил (обычно 5-13)
• Правила должны быть атомарными — одно правило проверяет один факт
• Примеры — минимум 2, лучше 3: по одному на каждый тип ответа

🚀 Быстрый старт — вставь в чат:

Вот шаблон для многокритериальной оценки документов. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про твою роль, какой объект оцениваешь, какие критерии важны — потому что структура промпта требует конкретики. Она возьмёт паттерн (роль → правила → критерии → примеры) и адаптирует под задачу: подберёт правила, сформулирует чётко, создаст релевантные примеры.

⚠️ Узкий use case: Метод заточен под задачи бинарной фильтрации — когда нужно отсеять явно неподходящее и оставить потенциально релевантное. Если задача требует глубокого анализа, сравнения нюансов или креативной оценки — метод не поможет. Он для первичной сортировки, не для финального решения.

⚠️ Garbage in, garbage out: Качество результата полностью зависит от качества правил. Если критерии расплывчатые ("документ должен быть качественным") или противоречивые — модель будет ошибаться. Плохо сформулированные правила хуже, чем их отсутствие.

⚠️ Не заменяет экспертизу: В исследовании инструмент отклонил 5,447 документов и оставил 237 для анализа людьми. Это помощник для грубой фильтрации, не замена эксперту. Модель может пропустить важное (false negative) или включить мусор (false positive) — особенно в пограничных случаях. Все документы с оценкой DOUBT требуют человеческого взгляда.

⚠️ Чувствительность к формулировкам: Небольшое изменение в формулировке правила может дать другой результат. В исследовании переход от негативных инструкций к прямым утверждениям повысил точность на 15-20 процентных пунктов. Будь готов итеративно уточнять промпт.

⚠️ Масштаб без автоматизации: В чате применимо для 5-20 документов вручную. Для сотен или тысяч документов нужна автоматизация (код + API), что выходит за рамки работы в интерфейсе. Метод экономит время на каждом документе, но не решает проблему объёма.

Команда столкнулась с реальной болью: нужно обработать 8,482 документа для литературного обзора по тестированию софта в авиации. Предварительная выборка показала, что только 4% документов релевантны — остальное мусор. При этом каждый документ должны оценить три исследователя, потом провести голосование. Вручную это месяцы работы.

Решили автоматизировать через LLM. Главный вопрос: как убедиться, что инструмент не вносит больше bias, чем люди? Взяли выборку 58 документов, которые оценили три эксперта (Fleiss' Kappa = 0.49 — умеренное согласие даже между людьми). Это стало бенчмарком.

Дальше — итерационный prompt engineering с ноября 2024 по февраль 2025: написали первый промпт, прогнали на 58 документах, посчитали Positive Percent Agreement (сколько процентов отклонённых документов совпали с человеческой оценкой). Получили 60% — плохо. Изменили промпт, перезапустили — 70%. Ещё итерация — 79%. Пять мажорных версий промпта, десятки мелких твиков.

Ключевой инсайт появился при переходе от версии 2.3 к 3.0: негативные инструкции путают модель. Было: "отклони документ если он является инструкцией". Модель путалась между "отклони" (негатив) и "является" (позитив). Переформулировали в прямые утверждения: "документ НЕ является инструкцией" в списке правил с инструкцией "выбери если ВСЕ правила выполнены". PPA подскочило с 79% до 87%.

Финальная версия (V4.1) дала 90% согласия на контрольной выборке 58 документов. Но это могло быть overfitting. Взяли репрезентативную выборку 368 документов (статистически значимо для популяции 8,482 при доверительном интервале 95%, погрешность 5%). Каждому из трёх исследователей дали по 73-74 документа. Результат: PPA = 96% — инструмент согласуется с людьми почти идеально на новых данных.

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

Также тестировали влияние температуры модели (0.5 vs 0.1) и разные LLM (llama3, llama3.1, dolphin-llama3). Температура почти не влияла. Смена модели сильно меняла результат — один и тот же промпт давал PPA от 65% до 90% на разных моделях. Вывод: промпт и модель связаны — нельзя просто взять промпт и перенести на другую LLM без адаптации.

Финальный прогон на всех 8,482 документах занял 36 часов на workstation с RTX 4090. Инструмент отклонил 5,447 документов, оставил 224 для включения и 13 с сомнением. Это сократило объём ручной работы в 20-30 раз — вместо проверки 8,482 документов исследователям нужно проверить только 237.

Главный урок: высокая точность достигается не выбором "лучшей" модели, а тщательной калибровкой промпта под конкретную задачу и модель через итеративное тестирование на контрольной выборке.

Финальный промпт (Prompt V4.1) из исследования:

Context: You are an expert in context-aware software testing. You must choose software 
testing documents to support testing context-aware avionics software systems for manned 
civil aircraft in the industry. You consistently and professionally follow instructions 
and criteria to support your choice and provide an answer.

Instructions: 
1. Clear all of your previous document evaluations.
2. Evaluate the documents based on the following 13 rules:

- Rule 1: The document concerns a manned or piloted aircraft.
- Rule 2: The document concerns an aircraft operating within civil aviation.
- Rule 3: The document indicates the aircraft's software.
- Rule 4: The document describes the design, execution, or reporting of the testing 
 of avionics software systems.
- Rule 5: The document describes techniques, technologies, processes, or standards 
 for avionics software testing.
- Rule 6: The document describes the planning, design, execution, or reporting of 
 testing avionics software systems.
- Rule 7: The document describes an application in the industry.
- Rule 8: The document is not an operating or installation manual.
- Rule 9: The document does not describe instruments, equipment, or toolkits to 
 support software testing in general.
- Rule 10: The document does not describe military applications.
- Rule 11: The document does not describe space aircraft or airspace applications.
- Rule 12: The document does not describe formal verification and validation methods.
- Rule 13: The document does not describe static analysis or verification techniques.

3. Provide your answer observing a Response Criteria and using an Output Template.

Response Criteria:
Set the '<choice>' to "YES" if the software testing document satisfies all 13 rules.
Set the '<choice>' to "NO" if the software testing document does not satisfy any 
of the 13 rules.
Set the '<choice>' to "DOUBT" if you cannot decide based on the rules.
Justify your decision by filling in an '<explanation>' with two short phrases 
extracted from the software testing document.
Set the '<confidencelevel>' with a 0-100% value to indicate your decision confidence.

Output Template: 
'<choice>'; "Confidence = "; '<confidencelevel>'; '<explanation>'

Examples of Output:
- YES; Confidence = 94%; The document explains how to test context-awareness software.
- DOUBT; Confidence = 91%; The document regards model-based testing to support the 
 generation of context-awareness test cases.
- NO; Confidence = 82%; The document explains how to use formal methods to test 
 software systems.

Контекст исследования: Этот промпт использовался для оценки релевантности PDF-документов в контексте Multi-Vocal Literature Review о тестировании context-aware систем в авиации. Документы загружались через RAG (retrieval-augmented generation), текст извлекался, разбивался на chunks с overlap, эмбеддинги создавались через mxbai-embed-large, а инференс делал dolphin-llama3 (8B параметров). Temperature = 0.1 для большей детерминированности.

💡 Адаптация для оценки вакансий кандидатами:

Вместо оценки документов исследователем — оценка вакансий кандидатом. Та же логика: набор чётких критериев (зарплата, локация, удалёнка, стек) + трёхуровневая оценка (подходит / не подходит / нужно уточнить).

Контекст: Ты карьерный консультант, помогаешь кандидату отобрать релевантные вакансии 
из потока предложений на hh.ru и LinkedIn.

Инструкции: Оцени вакансию по следующим 10 правилам:

ДОЛЖНО выполняться:
- Правило 1: Зарплата от 150,000 рублей (или не указана)
- Правило 2: Локация: Москва, Санкт-Петербург или remote
- Правило 3: Возможна полная удалёнка или гибрид (не офис 5/2)
- Правило 4: В стеке есть Python или Go
- Правило 5: Роль: backend-разработчик, data engineer или близкое
- Правило 6: Не требуется руководство командой (senior IC роль, не тимлид)

НЕ ДОЛЖНО быть:
- Правило 7: Вакансия НЕ от аутсорс-компании или аутстаффа
- Правило 8: Описание НЕ содержит фразы "ищем звезду" или "суперзвезду"
- Правило 9: НЕТ требования переезда в другой город
- Правило 10: НЕТ упоминания "стартап на ранней стадии без финансирования"

Критерии ответа:
- YES — если вакансия удовлетворяет всем 10 правилам → добавить в shortlist
- NO — если нарушает хотя бы одно правило → пропустить
- DOUBT — если информации недостаточно → запросить детали у рекрутера

Шаблон вывода: 
'<решение>'; "Уверенность = <0-100%>"; '<обоснование>'

Примеры:
- YES; Уверенность = 93%; Remote, зарплата 200к, Python backend, senior IC роль в продуктовой компании.
- DOUBT; Уверенность = 87%; Зарплата подходит, но не указано про удалёнку — уточнить у рекрутера.
- NO; Уверенность = 96%; Аутсорс-компания — не по критериям.

[Вставить текст вакансии]

Как это работает: Кандидат копирует текст вакансии из hh.ru → вставляет в чат → получает структурированную оценку с обоснованием. За 10-15 минут можно обработать 20-30 вакансий, оставив только те, которые реально подходят по жёстким критериям. DOUBT-вакансии — список вопросов для рекрутера.

🔧 Техника: добавить цитаты → видеть на что опирается модель

В оригинале обоснование — это две короткие фразы. Можно усилить:

Justify your decision by filling in an '<explanation>' with:
1. Direct quote from the document (in quotation marks)
2. Which specific rule it addresses
3. Your interpretation in one sentence

Эффект: Вместо абстрактного "документ описывает тестирование" получишь "Цитата: 'We perform integration testing of avionic systems' → Rule 4 → Явно упоминается тестирование авионики". Это помогает отлаживать ложные срабатывания — видно на какой текст модель опирается.

🔧 Техника: строгие vs мягкие пороги уверенности → управление риском ошибки

В оригинале: YES при >92%, NO при <85%, DOUBT между ними. Можно сдвинуть пороги в зависимости от цены ошибки:

Строгий режим (низкий риск пропустить важное):

If your suggested confidence level is > 95, the <response> is YES.
If your suggested confidence level is < 75, the <response> is NO.
If your suggested confidence level is > 75 and < 95, the <response> is DOUBT.

Мягкий режим (низкий риск тратить время на мусор):

If your suggested confidence level is > 85, the <response> is YES.
If your suggested confidence level is < 90, the <response> is NO.
If your suggested confidence level is > 85 and < 90, the <response> is DOUBT.

Эффект: Строгий режим даёт больше DOUBT → больше проверок вручную, но меньше пропущенных документов. Мягкий режим агрессивнее отсекает → экономит время, но рискует пропустить пограничные случаи. Выбор зависит от задачи: для критичных решений (юридические договоры, медицинские заключения) — строгий. Для массовой фильтрации спама — мягкий.

Accelerating Discovery: Rapid Literature Screening with LLMs (2025). Santiago Matalonga (University of the West of Scotland), Domenico Amalfitano (University of Naples Federico II), Jean Carlo Rossa Hauck (Universidade Federal de Santa Catarina), Martín Solari (Universidad ORT Uruguay), Guilherme H. Travassos (Universidade Federal do Rio de Janeiro).

Replication package: https://git-lab.cos.ufrj.br/contextaware/llm

Исследование фокусируется на Multi-Vocal Literature Reviews в Software Engineering, конкретно на тестировании Context-Aware Software Systems (CASS) в авиационной индустрии. В статье упоминаются предыдущие работы команды по CASS testing в автомобильной промышленности.