Почему лучший кандидат не всегда правильный
Рабочее название прототипа: Tender Semantic Engine (TSE)
Если фрагмент оказался неправильным ответом на один вопрос, сначала стоит проверить, не является ли он правильным ответом на другой.
Задача, которая только кажется простой
Я разрабатываю настольную систему для работы с тендерами. Один из ее модулей должен читать комплект закупочной документации и переносить в карточку тендера конкретные условия: порядок оплаты, аванс, срок и место поставки, гарантию, обеспечение, штрафы и другие обязательства сторон.
Обычно один комплект состоит из договора, технического задания, спецификаций, приложений и Excel‑таблиц. В текущем контуре обрабатываются Word, Excel и PDF с текстовым слоем. Сканированные документы и OCR пока рассматриваются как отдельная задача.
Сначала кажется, что достаточно регулярных выражений, ключевых слов, классификатора или современной LLM. Но основная проблема не в том, чтобы найти предложение со словами «поставка», «оплата» или «гарантия». Нужно понять, какое действие оно выражает и к какому условию относится числовое значение.
Поставщик обязан уведомить Покупателя о готовности товара
не позднее чем за 5 рабочих дней до предполагаемой даты поставки.
Здесь есть поставщик, товар, пять рабочих дней и слово «поставка». Однако пять дней относятся не к поставке, а к уведомлению.
Недостатки, выявленные в гарантийный период, должны быть устранены
Поставщиком в течение 10 рабочих дней.
Здесь много гарантийной лексики, но десять дней являются сроком устранения недостатков, а не сроком гарантии.
Шаблонные поля вроде «Указать предлагаемые условия оплаты: ________», желательные условия и ссылки «согласно спецификации» выглядят убедительно для тематического классификатора, но не всегда содержат фактическое обязательство.
Почему top-1 недостаточно
Первая версия конвейера была обычной: найти кандидатов, начислить баллы и выбрать лучший фрагмент. Такая схема всегда возвращает победителя, даже когда правильного ответа среди кандидатов нет.
Документы
↓
Поиск кандидатов
↓
Score каждого кандидата
↓
Top-1
↓
Карточка тендера
Если настоящего срока поставки нет, но найдено красивое предложение про уведомление за пять дней до поставки, оно легко становится top-1. Лучший кандидат не обязательно является правильным кандидатом. Добавление новых регулярных выражений постепенно превращало систему в коллекцию исключений, поэтому я начал описывать не слова, а смысловые действия.
Структурированный глиф
Каждый кандидат преобразуется в упрощенное структурированное представление действия. В проекте я называю его structured glyph, или структурированным глифом.
actor = supplier
action = notify
object = readiness
recipient = buyer
value = 5
unit = working_days
relation = before
event = delivery
modality = obligation
У предложения о поставке структура будет другой:
actor = supplier
action = deliver
object = goods
value = 45
unit = calendar_days
after = contract_signing
modality = obligation
Лексически предложения похожи, но первое описывает уведомление, а второе фактическую поставку. Для извлечения условия важны не отдельные слова, а связка «кто делает что, над каким объектом, кому, при каком событии и с каким значением».
Смысловые контейнеры и эталонные глифы
Полученные глифы сопоставляются со смысловыми контейнерами: PAYMENT, DELIVERY_TIME, GUARANTEE_TERM, DELIVERY_ADDRESS, SECURITY, NOTICE_TERM, EXPERIENCE_TIME и другими.
С каждым контейнером связан структурированный эталонный глиф. Он задает обязательные роли и действия, допустимые объекты и значения, события‑основания, стоп‑сценарии, слабые ссылочные фреймы и конкурирующие смыслы.
DELIVERY_TIME
Обязательное:
действие поставки
объект поставки
временное значение или дата
Конкурирующие смыслы:
уведомление
устранение дефектов
срок действия договора
приемка
передача документов
Это не просто список ключевых слов. Контейнер проверяет, является ли найденное число значением именно целевого действия.
Ложный кандидат может быть полезным фактом
Пусть фраза «уведомить за пять рабочих дней до поставки» была найдена как кандидат на DELIVERY_TIME. Обычная система после проверки выбросит ее. В TSE она проходит повторную смысловую маршрутизацию.
Кандидат для DELIVERY_TIME
↓
ACTION = notify
↓
DELIVERY_TIME: несовместим как main
↓
NOTICE_TERM: подтвержден
↓
Сохранить NOTICE_TERM
↓
Использовать как negative evidence для DELIVERY_TIME
Правильная альтернативная классификация одновременно дает новый факт и запрещает использовать этот же фрагмент как главный ответ соседнего контейнера.
Тот же принцип применим к сроку устранения дефектов, монтажу, приемке, сроку действия договора и передаче документов. Часть этих смыслов уже оформлена как активные контейнеры, часть пока остается направлением расширения онтологии. Новый контейнер появляется только тогда, когда смысл регулярно встречается, имеет самостоятельную бизнес‑ценность и устойчиво отличается от соседних классов.
Поэтому расширение онтологии потенциально повышает не только полноту новых сущностей. Оно может повышать точность старых контейнеров, поскольку у ложного кандидата появляется явный альтернативный тип.
Admission gate до ранжирования
До выбора победителя кандидат получает одну из ролей:
• main: полноценное фактическое условие;
• needs_split: в одном фрагменте объединено несколько действий;
• reference: ссылка на другой документ или раздел;
• incomplete: отсутствует существенная часть действия;
• wrong_container: выражено другое условие;
• noise_or_placeholder: шаблон, заголовок или служебный текст.
Документы
↓
Атомарные смысловые фрагменты
↓
Структурированный глиф
↓
Эталонные глифы контейнеров
↓
Semantic admission gate
↓
Малые ML‑модели
↓
Semantic winner
↓
Контролируемый fallback
↓
Граф обязательств и карточка тендера
Ranking начинается только среди допущенных кандидатов. Если hard gate установил semantic contradiction или wrong_container, высокий статистический score не должен вернуть фрагмент в main.
Небольшой ML вместо тяжелой модели в runtime
Полностью покрыть язык правилами тоже трудно. Поэтому в runtime используются две небольшие модели scikit‑learn на признаках TF‑IDF word n‑grams и char 3–5 grams с LinearSVC. Одна различает keep_main и not_main, вторая уточняет причину отклонения.
На одном из этапов обучающий корпус содержал 5262 кандидата смешанного происхождения. Это не полностью ручной gold‑набор. Модели занимают считаные мегабайты, работают на CPU и нужны для обобщения на незнакомые формулировки. Они не отменяют жестко установленное семантическое противоречие.
Natasha используется как источник морфологических и сущностных сигналов и как demoter для части неподходящих фраз, но не принимает окончательное решение. FrameBank использовался как источник вариантов глагольного управления и семантических ролей при расширении словаря и эталонных фреймов.
Qwen как учитель и аудитор
Локальная Qwen3.8–27B в квантовании UD‑Q3_K_XL не вызывается для каждого нового документа. Она используется в лаборатории как teacher и auditor: разбирает сложные расхождения, определяет действие и контейнер, после чего результат проверяется и переносится в исполняемые правила, эталонные глифы или обучающие метки.
TSE verdict
↓
Qwen verdict
↓
Расхождение
↓
Адъюдикация
↓
Trusted gold
↓
Класс ошибки
↓
Правило / глиф / контейнер / gate
В одном наборе из 100 сложных расхождений итоговая метка после проверки совпала с решением Qwen3.8–27B в 81 случае, с решением прежней Qwen3.5–9B в 14 случаях; еще в пяти случаях потребовалась отдельная корректировка. Это распределение решений внутри спорного набора, а не самостоятельная оценка точности каждой модели.
После переноса закономерностей regression‑набор прошел 100 из 100 по укрупненному решению main / split / non‑main. Это не означает 100% на новых документах: тот же набор участвовал в развитии правил. Независимый blind test остается обязательным следующим этапом.
Реальный обезличенный пример: три платежа и один ложный победитель
В одном из рабочих закупочных комплектов условия были распределены между договором, спецификацией и приложением. Покупатель должен был перечислить 30% аванса, затем 40% после уведомления о готовности товара и оставшиеся 30% после подписания УПД.
Рядом находилась обязанность поставщика выставить счет. По платежной лексике она выглядела сильным кандидатом, и одна из промежуточных версий выбирала ее как основное условие оплаты.
Покупатель → перечисляет → деньги → Поставщику
Поставщик → уведомляет → о готовности товара → Покупателя
Поставщик → выставляет → счет → Покупателю
После разбора ролей первое действие относится к PAYMENT, второе становится событием‑основанием для платежного этапа, а третье относится к обязанности предоставить расчетный документ. Payment gate отклоняет ложного победителя, после чего контролируемый fallback ищет следующего кандидата только среди фрагментов, прошедших payment‑фреймы. В результате сохраняется полный граф 30% + 40% + 30%, а выставление счета не теряется, но перестает подменять оплату.
На регрессионном наборе из 2068 платежных кандидатов усиление payment‑фреймов с использованием результатов Qwen и данных FrameBank повысило exact match с 59,33% до 76,50%. Эти цифры показывают изменение внутри рабочего корпуса, а не качество на независимой выборке.
Условия превращаются в граф обязательств
Плоской JSON‑карточки недостаточно, потому что события договора связаны между собой:
CONTRACT_SIGNING
→ DELIVERY
→ UNLOADING
→ INSTALLATION
→ COMMISSIONING
→ DOCUMENT_SUBMISSION
→ ACCEPTANCE
→ ACT_SIGNING
→ PAYMENT
→ WARRANTY
Фраза «Оплата в течение 60 дней после подписания акта приемки» задает не только PAYMENT_TIME = 60 days, но и связь PAYMENT AFTER ACCEPTANCE_ACT_SIGNING. А подписание акта может зависеть от поставки, монтажа, ПНР и передачи документов.
Отдельная проблема возникает при ссылках между файлами. Договор может устанавливать, что срок определяется спецификацией, а спецификация содержит значение 30 календарных дней с даты ее подписания. Тогда нужно сохранить источник правила, источник значения, событие‑основание и связь между документами.
Почему не заменить систему одной LLM
Большая модель хорошо различает многие близкие классы и полезна для сложного reasoning. Но понимание одного примера и воспроизводимая промышленная обработка документов не одно и то же.
Исполняемое правило ACTION = notify → NOTICE_TERM → incompatible_as_main(DELIVERY_TIME) одинаково применяется при следующем запуске, после смены модели и после изменения prompt. Кроме ответа система может показать исходный фрагмент, распознанное действие, выбранный контейнер, сработавшее противоречие, причину недопуска и источник победившего условия.
Поэтому LLM находится рядом с runtime: как teacher, auditor и возможный judge действительно спорных случаев, но не как единственный источник истины.
Это не изобретение онтологического IE
Ontology‑based information extraction существует десятилетиями. В ABBYY Compreno использовались семантико‑синтаксический анализ, предметные онтологии, правила извлечения и проверки онтологических противоречий. В опубликованном описании конфликтующее сопоставление отбрасывается, а алгоритм не рассматривает альтернативы.
В работе 2018 года Industrial information extraction through multi‑phase classification using ontology for unstructured documents применялись многоуровневая промышленная онтология и двухфазная классификация предложений и слов. Подход проверялся на 35 реальных тендерных документах энергетической отрасли примерно по 800 страниц каждый.
Поэтому моя гипотеза уже: не просто обнаружить противоречие, а сохранить альтернативную семантическую интерпретацию как самостоятельный факт и использовать ее как negative evidence против первоначального контейнера до ranking.
Что пока не доказано
Я не утверждаю, что TSE лучше любой современной LLM. Сейчас есть рабочий pipeline, регрессионные корпуса, измеряемые классы ошибок, онтология, малые ML‑модели и локальная LLM для аудита. Но честное сравнение требует заморозить код и взять полностью новый корпус.
В blind test я хочу сравнить direct Qwen, Qwen со структурированным prompt, TSE и TSE с Qwen Judge. Измерять нужно container accuracy, boundary accuracy, winner accuracy, value accuracy, source attribution, false rejection и особенно wrong‑main rate.
Для бизнес‑системы отсутствие ответа часто безопаснее, чем уверенное утверждение «срок поставки пять дней», когда пять дней на самом деле относятся к уведомлению.
Вместо заключения
Популярный конвейер обработки документов выглядит как PDF → chunks → embeddings → RAG → LLM → JSON. Для множества задач этого достаточно. Но если результат автоматически записывается в бизнес‑систему и участвует в расчетах, цена семантически неверного top-1 становится выше.
Поэтому Tender Semantic Engine развивается как связка атомарных смысловых фрагментов, структурированных глифов, контейнеров, обязательной и запрещающей семантики, admission gate, статистического обобщения, контролируемого fallback и графа обязательств.
Если фрагмент оказался неправильным ответом на один вопрос, сначала стоит проверить, не является ли он правильным ответом на другой.
Возможно, именно из таких «неправильных» фрагментов получается наиболее полезная часть онтологии.
Ищу независимую проверку и конструктивную критику.
Буду рад критике от тех, кто строил ontology‑based IE, LegalTech/NLP‑системы или работал с промышленной документацией. Особенно интересны примеры semantic rerouting, где ложный кандидат не только отклоняется, но сохраняется в своем действительном классе и влияет на выбор основного результата.
Ссылки
ABBYY Compreno: алгоритм извлечения информации, часть 1. https://habr.com/ru/companies/contentai/articles/269191/
ABBYY Compreno: алгоритм извлечения информации, часть 2. https://habr.com/ru/companies/contentai/articles/269273/
Rajbabu, Srinivas, Sudha. Industrial information extraction through multi‑phase classification using ontology for unstructured documents. Computers in Industry, 2018. https://doi.org/10.1016/j.compind.2018.04.007
Автор: Geiser
