Чому вилучення ключових фраз ламається на живих текстах
Вилучення ключових фраз виглядає простою задачею, поки тексти однотипні й чисті: подали документ — отримали список термінів.
На живому корпусі — договорах, протоколах нарад, сканах, листуванні — точність на реальних текстах падає, і у відповідь разом зі змістом приходять колонтитули, реквізити й уривки таблиць.
Перше джерело втрат — сама термінологія. В одному підрозділі пишуть «вузол обліку», в іншому — скорочення, у третьому — одрук від поспіху, і той самий об’єкт розпадається на десяток написань.
Словник предметної області в кожного замовника свій, а без нього вилучення ключових фраз не розуміє, що вважати варіантом норми.
Друге — шум у документах. Текст приходить із верстки, з таблиць, зі сканів після розпізнавання, де символи склеюються й плутаються. Тоді команда йде в ручний перебір термінів: списки стоп-слів, ручні правила, синоніми під кожен новий шаблон. Конструкція тримається до першої зміни постачальника або форми документа.
Для процесу це обертається тим, що пошук по архіву не знаходить потрібний файл, а зведення за тегами показують неповну картину — рішення ухвалюють за даними, яким не можна довіряти. Розбираємо, як це закривається і чому якість губиться не в моделі, а на вході.
Ефект впровадження: покриття термінів і обсяг ручної розмітки
На старті проєкту з розбору технічних регламентів експерт розмічав терміни вручну: близько чотирьохсот значущих фраз на тисячу сторінок. До третини з них він фізично не встигав позначити — вони виринали пізніше, на погодженні, коли документ уже пішов далі процесом.
Пропущений термін коштує дорожче за зайвий: він не потрапляє в словник, і в наступних документах система знову його не бачить.
Після налаштування вилучення ключових фраз покриття термінології вийшло на 92–96% від експертної розмітки на тому самому типі документів.
Основа — словник предметної області, зібраний з уже розмічених фрагментів; KeyBERT дообучається на цих парах, тому складені назви на кшталт «датчик тиску контуру охолодження» залишаються цілими, а не розпадаються на окремі слова.
Ручна розмітка скорочується приблизно в п’ять разів і змінює характер: експерт не розмічає з нуля, а підтверджує або відхиляє запропоноване, витрачаючи час на спірні випадки.
Клас помилок «пропущений термін» не зникає повністю, але перестає бути системним — на нього припадають поодинокі випадки замість третини корпусу.
Стабільний результат на нових документах тримається завдяки тому, що словник і правила поповнюються під час кожного проходу, а не налаштовуються один раз під перший файл.
Швидкість обробки корпусу змінюється відповідно: пакетний прогін тисяч сторінок займає години, тому повторну розмітку після правок регламенту роблять без окремого проєкту.
Підходи до вилучення: правила, статистика, мовні моделі
Логіка вибору починається не з моделі, а з характеру даних. Там, де термінологія закрита й повторюється — регламенти, номенклатура, типові договори — словникові правила дають передбачувані влучання й не потребують розмітки.
Як тільки корпус стає різнорідним, словник починає відставати: кожне нове формулювання доводиться вносити вручну.
Навчувана модель виграє за стабільного домену й наявності кількох сотень розмічених документів — вона ловить фрази, яких немає в довіднику. Мовна модель підключається там, де буквального збігу немає, а зміст зберігається: перефразування, синоніми, скорочення.
На більшості проєктів ми збираємо гібридну схему: кандидатів постачають правила й статистика, а ранжує їх модель — рідкісні терміни не губляться, а шум відсікається.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Словникові правила | Закрита термінологія, часті повтори, потрібен пояснюваний результат | Не знаходить нові формулювання, словник ведуть вручну |
| Статистична модель, що навчається | Є розмітка, домен стабільний, важлива швидкість на великих обсягах | Залежить від якості розмітки, просідає за зміни тематики |
| Мовна модель | Перефразування, синоніми, потрібне врахування контексту | Потребує ресурсів, обмежена довжиною документа |
| Гібридна схема | Різнорідні документи, високі вимоги до повноти й точності | Складніша в підтримці, потрібен контроль на кожному кроці |
Вибір фіксуємо заміром, а не на словах: проганяємо варіанти на вашій вибірці документів і дивимося частку точних влучань і повноту за кожним класом фраз. Схема при цьому залишається замінною — компоненти змінюються окремо, без переписування всього контуру вилучення.
Як проходить впровадження: від розбору корпусу до передачі рішення
Порядок робіт майже не залежить від того, де застосовується вилучення ключових фраз — у пошуку по базі знань, розборі звернень чи аналітиці відгуків.
Спочатку розбираємо корпус, потім фіксуємо розмітку, і лише потім налаштовуємо модель: якщо кроки поміняти місцями, виходить рішення, яке показує красиві приклади й не переноситься на реальний потік документів.
- Розбір корпусу. Дивимося, з чого складається потік: типи документів, мови, частка дублів і службового тексту, чи є готова розмітка. На виході видно, де потрібна нормалізація — кодування, колонтитули, сміття після розпізнавання сканів.
- Постановка розмітки. Домовляємося, що вважаємо ключовою фразою: довжину, межі, входження в заголовок, обробку синонімів і скорочень. Розмічаємо еталонний набір і рахуємо згоду між розмітниками — без цього метрики якості нічого не значать.
- Схема вилучення. Збираємо контур: базовий шар на статистиці й спільній зустрічальності слів, поверх — модель під домен, плюс нормалізація, стоп-листи й словники термінів замовника.
- Налаштування під домен. Уточнюємо параметри на валідаційній частині, додаємо синоніми й назви продуктів, дообучаємо модель на розмічених прикладах.
- Перевірка на відкладеній вибірці. Тестовий набір фіксуємо заздалегідь і не чіпаємо під час налаштування: рахуємо повноту й точність за фразами, розбираємо помилки за типами. Набір залишається в замовника як регресійний — на ньому перевіряються будь-які подальші правки.
- Передача рішення. Віддаємо код, конфігурації, модель, схему розмітки й регламент оновлення словників. Навчаємо команду, щоб правки вносили без нас.
Що залишається замовнику: конфігурації, розмітка, регламенти
Ми віддаємо не лише робочий сервіс, а й усе, що потрібно для його самостійного розвитку. Комплект передачі розрахований на вашу команду: інженерам — налаштування й код, аналітикам — розмітку й правила, керівнику — регламент, за яким рішення живе далі.
- Конфігурація схеми вилучення: правила нормалізації тексту, стоп-слова, ваги частин мови й пороги відсікання винесені в окремий файл налаштувань, а не заховані в коді.
- Розмічений корпус на 1–3 тисячі документів вашої предметної області: еталонні ключові фрази, розділені на навчальну й перевірну частини.
- Інструкція з розмітки: що вважаємо ключовою фразою, як склеювати складені терміни, як розбирати спірні випадки — щоб нові дані розмічали однаково різні люди.
- Схема обробки тексту від приймання документа до видачі результату: де стоять перевірки, де пишуться журнали подій, куди додавати нові кроки.
- Регламент оновлення словника й моделей: періодичність, хто погоджує зміни, як фіксується просідання якості на перевірній вибірці.
- Набір перевірок і метрики прогону на еталонному корпусі — видно, стало вилучення точнішим чи гіршим після правок.
- Документація з інтеграції: формати запиту й відповіді, обмеження за обсягом, поведінка за порожнього результату.
Кожен пункт — це файл, розділ документації або наданий доступ, а не усна домовленість. Через місяць після запуску ви самі змінюєте поріг відсікання або додаєте свої правила розмітки й одразу бачите ефект на перевірному корпусі.
Кейс: як змінилася якість розбору документів після впровадження
До впровадження розбір тримався на регулярних виразах і словнику термінів, який аналітики доповнювали вручну після кожної скарги.
На потоці однотипних документів — договорів, техпаспортів і додатків до них — цього вистачало на першу сотню сторінок, далі словник розходився з реальними формулюваннями, і перевірка перетворювалася на суцільне перечитування.
Ми розмітили еталонну вибірку за класами полів і почали вимірювати точність і повноту окремо за кожним класом, а не однією середньою оцінкою.
Вилучення кандидатів зібрали на spaCy, додали словникові якорі й дорахунок складених термінів з абревіатурами по всьому документу, а не по абзацу. Поріг упевненості вивели в окрему чергу: аналітик бачить не весь потік, а лише спірні місця.
Метрики до й після
На тому ж потоці повнота зросла з 61% до 93%, точність — з 74% до 96%. Частка документів, що йдуть на ручну перевірку, впала з 100% до 18%, а розбір пакета на 200 сторінок скоротився з трьох годин до пів години.
Клас пропущених термінів теж змістився. Раніше губилися складені терміни й абревіатури, розшифрування яких стояло в іншому розділі; тепер залишкові пропуски — це терміни всередині сканів таблиць і рукописних правок, де текстового шару немає взагалі.
Кожен такий випадок потрапляє в чергу розбору, словник поповнюється, і на наступному типі документів якість не просідає з нуля.
Чим розмітка під задачу відрізняється від готового словника термінів
Готовий словник термінів — це статичний список із нормалізацією форм і порогом збігів. Він упевнено відповідає на питання, чи трапляється відоме нам слово, але не на питання, чи називає ця фраза суть документа.
Такий список прозорий, пояснюється перевіряльнику й правиться одним рядком — тому як відправна точка він доречний майже завжди.
Розмітка під задачу починається не зі списку, а зі схеми: що саме вважаємо ключовою фразою у вашому домені — властивість виробу, дефект, сторону угоди, дію або умову.
Далі на корпусі ваших документів фіксуються критерії, спірні випадки й правило їх розв’язання, а розмітку ведуть кілька людей з регулярним звірянням. Ми окремо рахуємо частку спірних фрагментів: якщо вона висока, інструкція сира, і модель вивчить шум замість закономірності.
Практична відмінність підходів у тому, що словник закриває покриття відомих сутностей — регламентні терміни, коди, усталені найменування, — а розмітка задає межі фрази та її пріоритет серед інших.
Робоча стратегія частіше гібридна: словник слугує джерелом стартових міток і жорстким шаром правил, поверх якого навчена на розмітці модель розбирає живі формулювання.
Вибір стратегії диктує поведінка мови й ціна помилки. Якщо клас термінів закритий і змінюється рідко, словника вистачає надовго; коли формулювання оновлюються, приходять синоніми й скорочення, якість упирається в стелю, яку знімає лише розмітка.
На старті ми проганяємо обидва варіанти на одному наборі документів і показуємо, на якій частці фраз вони розходяться.
Часті технічні сумніви: розмітка, якість, супровід
Інженерні сумніви щодо вилучення ключових фраз рідко стосуються самої задачі — частіше переходу: чи витримає рішення нові типи документів, скільки розмітки доведеться зібрати, за якими критеріями приймати якість і що залишиться команді після передачі. Нижче — відповіді на те, що найчастіше виринає на етапі оцінювання.
Надійдуть документи нового типу — вилучення деградує?
Ознаки на рівні фраз і словники термінів предметної області налаштовуються окремо від моделі, тому зміна типу документа не потребує перезбирання.
Достатньо розмітити вибірку нових документів і прогнати оцінювання на відкладеній її частині: розходження за точністю й повнотою видно до випуску, а не на живому потоці.
Скільки документів потрібно розмітити?
На старті — кілька сотень фрагментів; далі працює активне дообучення: у розмітку першими потрапляють випадки з низькою впевненістю моделі та пограничні терміни. Кожна наступна сотня прикладів дає більше, ніж попередня, і обсяг розмітки зростає повільніше, ніж якість вилучення.
Як приймаємо роботу й рахуємо якість?
Пороги точності й повноти фіксуємо до старту — окремо за кожною категорією ключових фраз, за рідкісними термінами й за документами з поганим сканом. Спірні випадки зводимо в один список: рішення щодо кожного ухвалює ваша сторона, а не метрика наосліп.
Чи зможемо супроводжувати рішення власними силами?
У передачу входить конфігурація вилучення, словники нової термінології, прогін оцінювання на контрольній вибірці й короткий регламент оновлення.
Додавання термінів не потребує перенавчання, а планова перевірка — це прогін оцінювання на свіжих документах із дообученням у разі просідання.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб розмова одразу йшла по суті, додайте до неї зразки: 20–50 реальних документів із тих, що будуть оброблятися, включно з «незручними» — сканами, текстами з таблицями, колонтитулами й побитою версткою.
Чим ближча вибірка до робочого процесу, тим точніше ми оцінимо, де вилучення ключових фраз упирається в якість вихідного тексту, а де достатньо налаштування правил і словника.
Корисно підготувати до обговорення:
- список предметних термінів і сутностей, які обов’язково мають потрапляти в результат;
- приклади «правильних» ключових фраз, розмічені вручну хоча б на десятку документів;
- очікуваний клас помилок: що критичніше — пропустити значущу фразу чи додати зайву;
- вимоги до формату видачі: таблиця, файл, запис у базу або виведення прямо в інтерфейсі;
- обмеження щодо доступів і зберігання: де лежать дані й що не можна виносити за контур;
- цільовий обсяг: скільки документів на день обробляється і з якою швидкістю потрібен результат.
Оцінка будується за етапами, і ви бачите її логіку. Постановка задачі фіксує, що вважаємо ключовою фразою і як вимірюємо якість. Оцінка обсягу робіт показує, які частини розв’язуються словником і правилами, а які потребують моделі та розмітки.
План впровадження розкладає роботу на кроки з перевірним результатом на кожному. Пілотний етап іде на обмеженій вибірці: звіряємо видачу з ручною розміткою, дивимося точність і повноту, і лише потім масштабуємо на весь масив.
Опишіть задачу — повернемося з оцінкою, планом етапів і критеріями приймання пілота.
