Relation Extraction на реальных текстах: где теряется точность
В договорах, протоколах и технических описаниях семантические связи между сущностями есть всегда: кто кому подчиняется, что на что ссылается, какое условие ограничивает поставку. Пока извлечение связей из текста делается вручную, эти связи живут только в голове аналитика и в его выписках. Ручной разбор документов не масштабируется: на корпусе в десятки тысяч страниц он превращается в отдельное направление работы со своими сроками и очередью.
Первый очевидный шаг — шаблоны и регулярные выражения — ломается на живых формулировках. «Поставка осуществляется до», «не позднее», «в срок, согласованный сторонами» описывают одно и то же отношение, а шаблон ловит только первый вариант и дальше выдаёт ложные срабатывания. Чем больше типов связей, тем сложнее поддерживать правила: каждое новое слово требует нового исключения, а исключения начинают конфликтовать между собой.
Но главная потеря точности происходит не в модели, а до неё — в качестве разметки. Связь нужно пометить отдельным объектом: тип, направление, точные границы участников. Поэтому разметка ведётся в инструменте, который хранит связь как самостоятельную сущность, — например, Label Studio, — иначе модель учится угадывать связь по близости слов и добавляет собственные ложные срабатывания поверх тех, что уже есть.
Дальше разбираем, как это закрывается: схема типов связей под предметную область, регламент разметки, замер согласия между разметчиками и отчёт по точности отдельно по каждому типу связи — вместо одной средней цифры, которая на живых текстах ничего не объясняет.
Эффект внедрения: скорость разбора, полнота и точность связей
Первый измеримый эффект — скорость обработки документов. Модуль извлечения связей разбирает типовой договор или протокол за секунды, тогда как ручная разметка того же текста занимает у аналитика десятки минут. На однотипных документах поток идёт пакетом: правило, настроенное на шаблон, дальше применяется без участия человека.
Полноту извлечения связей считаем на отложенной выборке, которую модель не видела при обучении. Фиксируем не одну цифру, а профиль: доля связей, найденных без ручной правки, отдельно по типам отношений — «поставщик — товар», «сотрудник — роль», «документ — основание». Точность модели настраивается порогом срабатывания: выше порог — меньше ложных связей, но больше пропусков, и этот баланс мы подбираем под задачу, а не под красивую метрику.
Доля ручной правки — главный рабочий показатель. На старте она может доходить до половины найденных связей, после дообучения на разметке заказчика опускается до единиц процентов на знакомых типах текстов. Рост доли правок мы читаем как сигнал: изменился формат входящих документов или появился новый поставщик с другой версткой.
Устойчивость на новых типах текстов держится на цикле: непокрытые примеры уходят в разметку, модель дообучается, качество сверяется с контрольным набором. Разметку сущностей и связей ведём на открытом стеке — spaCy и совместимых с ним форматах, поэтому данные остаются переносимыми и не привязаны к одному поставщику.
Подходы к Relation Extraction: правила, модели, гибридные схемы
Выбор схемы определяется структурой корпуса и ценой ошибки, а не модностью метода. Если формулировки однотипны и нужно объяснить каждое срабатывание — работают правила и словари. Если тексты живые, с перефразировками и опечатками — ни правила, ни обученная на малой выборке модель не держат качество на редких типах связей.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правила и словари | Узкий домен, устойчивые формулировки, требуется объяснимость каждого срабатывания | Поддерживаются вручную; ломаются на перефразировках; при росте числа правил появляются конфликты между ними |
| Обученная модель на своей разметке | Есть несколько тысяч размеченных связей, домен стабилен, типы связей фиксированы | Нужна согласованная разметка; при смене домена или формата документов качество падает и требует переобучения |
| Предобученная языковая модель с дообучением | Мало разметки, разнообразные формулировки, длинные тексты | Слабее на редких классах; тяжелее в эксплуатации, нужен контроль утечек и регулярное обновление на новых данных |
| Гибридная схема: правила плюс модель | Смешанный корпус, где часть связей задаётся жёсткими условиями | Сложнее в отладке: два источника ошибок и нужен отдельный слой разрешения конфликтов |
На практике чаще выигрывает гибридная схема: правила отсекают заведомо ложные срабатывания и закрывают связи с жёстким контекстом, модель добирает перефразировки. Качество при этом замеряется отдельно по каждому типу связи — средняя цифра скрывает провал на редком классе, который как раз и определяет применимость решения.
Как строится проект: от аудита корпуса до передачи модели
Связи между сущностями задаёт не текст, а схема: если типы связей описаны приблизительно, модель выучит шум и будет уверенно ошибаться на новых документах. Поэтому работа идёт от измерения корпуса к передаче, и каждый этап заканчивается проверяемым результатом.
- Аудит корпуса. Считаем реальный объём, дубли и встречающиеся типы сущностей, отмечаем, каких связей для обучения не хватает.
- Схема разметки. Фиксируем типы связей, их направление и правила спорных случаев — отрицания, перечисления, упоминания в скобках. Схему согласуем до разметки, иначе инструкции переписывают вместе с готовым материалом.
- Разметка и контроль качества. Часть документов размечают двое независимо, расхождения уточняют инструкцию. Согласие считаем в процентах: низкое значение означает, что задачу по-разному понимают и человек, и модель.
- Обучение. Модель на предобученном языковом представлении дообучается на корпусе; отдельно смотрим редкие типы связей, которые теряются первыми.
- Проверка на отложенной выборке. Метрики считаем на документах вне обучения и по каждому типу связи отдельно — средняя оценка скрывает провал на редких классах.
- Встраивание в процесс. Подключаем модель к текущему контуру: пакетная обработка, оценка уверенности по каждой связи, ручная проверка сомнительных случаев. Порог уверенности настраиваем так, чтобы поток на проверку не рос быстрее, чем команда его разбирает.
- Передача. Отдаём веса, конфигурацию развёртывания, схему разметки и разбор метрик — дообучение на новых данных команда ведёт сама.
Что передаём на руки: схема разметки, модель, регламент работы
Решение по извлечению связей бесполезно, если логика разметки живёт в голове одного инженера, а модель нельзя переобучить без автора. Поэтому вместе с работающей моделью мы передаём команде заказчика набор артефактов — по ним новый специалист воспроизводит результат, а relation extraction продолжает работать на данных, которые появляются после запуска.
- Схема разметки. Типы сущностей и допустимые связи между ними, правила границ, приоритет при пересечении и разбор спорных случаев, на которых разметчики расходятся чаще всего.
- Инструкция для разметчиков. Порядок работы, примеры «верно / неверно» на реальных фрагментах и критерий согласованности — доля совпавших связей у двух разметчиков.
- Документация по модели. Какие типы связей извлекаются, на каких данных обучена модель, где граница применимости и какого класса ошибки она допускает на коротких и неполных текстах.
- Набор контрольных примеров. Размеченные фрагменты с эталонными связями: прогон по ним после каждого дообучения показывает, не деградировала ли модель.
- Регламент дообучения. Когда собирать новые данные, как размечать их по той же схеме, как проверять качество до выката и в какой момент откатывать предыдущую версию.
- Отчёт по качеству и пороги. Точность и полнота по каждому типу связи отдельно, плюс порог уверенности, ниже которого связь уходит на ручную проверку, а не в систему.
Кейс: извлечение связей между сторонами в договорах и заявках
Задача пришла из юридического сервиса: несколько тысяч договоров и заявок в месяц, связи между сторонами вытаскивали эвристиками по шаблонам. Роли путались, а нетиповая оговорка ломала разбор документа целиком. Контрольный корпус собрали из размеченных документов и сверили разметку с открытым набором CUAD — метрики считали только по нему, чтобы результат не зависел от одной выгрузки.
Классы ошибок и что с ними сделали
| Класс ошибки | Причина | Что изменили | Доля до → после |
|---|---|---|---|
| Связь уходит на соседнюю сторону | Разметка не разделяла роли плательщика и поручителя | Отдельные метки ролей и словарь триггеров по типам оговорок | 18% → 4% |
| Обрыв связи между абзацами | Окно анализа обрывалось на границе абзаца | Учёт внутренних отсылок по всему тексту документа | 12% → 3% |
| Ложные связи в реквизитах | Шапка разбиралась как тело договора | Фильтр по смысловым секциям и структуре документа | 9% → 1% |
Точность по связям на контрольном корпусе выросла с 0,74 до 0,92, доля документов, уходивших на ручную проверку, — с 41% до 9%. Решающим было не усложнение модели, а разделение ролей в разметке: привязка стороны к обязательству перестала зависеть от порядка упоминаний в тексте.
Контрольный корпус остался в проекте как регресс-набор: каждая итерация прогоняется по нему целиком, а новый тип связи добавляется через разметку, а не правкой кода. Это даёт предсказуемый откат — при падении метрики видно, на каких именно документах разошлась разметка.
Чем извлечение связей отличается от поиска по ключевым словам
Поиск по ключевым словам отвечает на вопрос, в каких документах встречается слово, и возвращает список файлов по релевантности. Этого хватает, чтобы найти первоисточник, но не чтобы понять, как связаны люди, компании и события. Документ остаётся для системы закрытым: ответ лежит внутри, а наружу выходит только название файла.
Извлечение связей работает глубже. Модель размечает в тексте сущности — организации, персоны, даты, юридические роли — и определяет связь между сущностями: кто кому подчиняется, кто кому поставляет, кто с кем подписал договор. Выход — не список документов, а тройки «сущность — отношение — сущность», то есть структурированные данные.
Из этих троек собирается граф знаний: узлы — сущности, рёбра — типы связей с указанием документа и фрагмента, откуда связь извлечена. По графу проходят цепочки, недоступные поиску: два контрагента могут быть связаны через общего руководителя в третьей компании, хотя вместе в одном тексте они не упоминаются.
Особенно заметна разница в аналитике по документам. Ключевой поиск даёт долю текстов, где встретилось упоминание, граф отвечает на вопрос, сколько контрагентов связано с организацией и через какой тип отношений. Первое измеряет присутствие слова, второе — структуру предметной области, и только на нём строятся запросы вида «кто связан с X не напрямую».
Сомнения по данным, разметке и поддержке модели
Сомнения перед стартом обычно одни и те же: хватит ли данных, что делать с уже размеченным корпусом, потянет ли модель разнородные тексты и кто отвечает за качество после запуска. Разбираем типовые случаи.
У нас мало размеченных данных — модели хватит?
Объём считаем не в абсолютных числах, а по покрытию типов связей. Идём итерациями: стартовая разметка, замер на отложенной выборке, добор примеров только там, где модель ошибается. Тексты без разметки тоже работают — формулировки, которых нет в выборке, модель всё равно видит.
Разметка частично есть, но сделана под другую задачу
Существующую схему связей сопоставляем с целевой онтологией — заново размечаем только отсутствующие типы, а их обычно меньшинство. Отношения, которые надёжно выводятся правилами, в ручную разметку не попадают.
Документы разнородные: договоры, переписка, сканы, таблицы
Несколько типов документов разводим на отдельные ветки подготовки, но приводим к единой онтологии связей — иначе результаты несравнимы между собой. Модель обучаем на выборке из каждого типа, чтобы один формат не перетянул предсказания на себя.
Что происходит с моделью после запуска?
Поддержка — это цикл, а не разовый замер: следим за долей уверенных извлечений и новыми формулировками, ошибки уходят в следующую итерацию дообучения. Версионируем модель и разметку, поэтому откат на предыдущую рабочую версию — вопрос минут.
Оставшиеся вопросы — про доступы, форматы выгрузки результата и критерии приёмки — снимаем до старта, чтобы не переделывать разметку в процессе.Обсудим вашу задачу извлечения связей и объём корпуса
Разговор по делу начинается с корпуса, а не с обсуждения модели. Извлечение связей проверяется только на ваших текстах: на однотипных документах любая схема выглядит рабочей, а на реальных договорах, отчётах или переписке сразу видно, каких типов связей не хватает и где правило не срабатывает.
От вас полезно показать:
- 20–50 реальных документов или выгрузку — как есть, вместе с шумом, сканами и нестандартным оформлением;
- перечень сущностей и связей, которые нужны на выходе: типы, направление, кратность;
- один документ с ручной разметкой — эталон, по которому будем считать качество;
- откуда берутся данные и куда возвращается результат: хранилище, база, внутренние системы;
- ограничения по доступам: где можно обрабатывать тексты и что нельзя выносить за ваш контур.
Со своей стороны уточняем критерии приёмки: какую долю связей нужно извлекать на ваших документах, какой уровень ложных срабатываний допустим, что считаем пропуском, а что — лишней связью. От этого зависит и объём работ, и порядок этапов.
Дальше готовим план проекта с точками проверки: где вы смотрите результат на своих текстах и что можно скорректировать до финальной сдачи. Опишите задачу и объём корпуса — вернёмся с оценкой и планом.
