Таблиця посилань Анотація та вступ Домен і завдання 2.1. Джерела даних і складність 2.2. Визначення завдання Схожа робота 3.1. Видобуток тексту та огляд досліджень НЛП 3.2. Видобуток тексту та НЛП у промисловому використанні 3.3. Видобуток тексту та NLP для закупівель 3.4. Висновок з огляду літератури Пропонована методика 4.1. Знання предметної області 4.2. Вилучення вмісту 4.3. Зонування ділянки 4.4. Виявлення предметів партії 4.5. Розбір партії 4.6. Синтаксичний аналіз XML, об'єднання даних та розробка індексів ризику Експеримент і демонстрація 5.1. Оцінка компонентів 5.2. Демонстрація системи Обговорення 6.1. «Промислова» спрямованість проекту 6.2. Неоднорідність даних, багатомовність і багатозадачність 6.3. Дилема алгоритмічного вибору 6.4. Вартість навчальних даних Висновки, подяки та література 2. Домен і завдання Ця робота зосереджена на закупівлях у сфері охорони здоров’я, які рідко досліджувалися в літературі. Основною метою проекту є розробка платформи, яка дозволяє динамічно створювати «профіль ризиків постачальника» для кожного постачальника медичних послуг. Ми передбачаємо, що такий профіль буде складатися з різних «індексів», які оцінюють різні точки зору (наприклад, потужність для постачання певних продуктів, географічне охоплення) «ризиків» для потенційних покупців підписати контракти з постачальником. Це дозволить легко відповісти на такі питання, як «хто постачальники можуть постачати цей вид ліків», «в якому обсязі вони здатні постачати для цієї країни» або «чи можуть вони постачати таку кількість». Такі питання часто є вирішальними для прийняття рішення покупцем. Однак поточний процес закупівель залежить від ручного перегляду багатьох довгих документів для пошуку відповідей. Це дуже ресурсозатратний процес. Зрозуміло, що засобом для досягнення нашої головної мети буде структурована база даних даних про історичні контракти постачальників медичних послуг. Таким чином, другорядною метою проекту є розробка такої бази даних і заповнення її історичними даними про закупівлі медичних послуг. Незважаючи на те, що дані про державні закупівлі дуже доступні, як ми пояснимо нижче, існує суміш структурованих, напівструктурованих і неструктурованих багатомовних даних, які потрібно видобути та зв’язати. Тому основною частиною роботи проекту є розробка рішень для аналізу тексту та NLP, які автоматично обробляють великі обсяги неструктурованих даних про закупівлі для отримання інформації, яка може бути використана для заповнення бази даних. Таким чином, мета цієї статті полягає в тому, щоб повідомити про розвиток цих методів аналізу тексту та НЛП. 2.1. Джерела даних і складність Проект націлений на дані про закупівлі з платформи «Tenders Electronic Daily» (TED), яка використовується урядами ЄС для публікації своїх проектів, пов’язаних із державними закупівлями. Щороку TED публікує понад 460 000 тендерів і контрактів 26 офіційними європейськими мовами на суму близько 420 мільярдів євро. Кожен тендер можна розділити на кілька «лотів», де лот є найменшою одиницею контракту. Кожен лот може містити кілька необхідних елементів. Як приклад, у повідомленні про тендер «2019/S 180-437985»[1] перелічено 47 лотів із тендеру NHS (Великобританія), розміри яких коливаються від 2 до понад 30 предметів. Якщо тендер забезпечує успішні пропозиції, буде зроблено «присудження контракту» (або кілька присуджень) і зареєстровано в TED для тендеру. У подальшому, для пояснення, ми припускаємо, що для кожного тендеру є одна присудження (однак на практиці наші методи застосовуються до всіх присуджень, доступних для тендеру). Зверніть увагу, що лоти, запропоновані в тендері, і контракти, які присуджуються, формують відносини «багато до багатьох». Зокрема, кілька лотів можуть бути присуджені одній організації та задокументовані в одному контракті; один лот також може бути присуджений кільком організаціям, утворюючи кілька контрактів; крім того, один контракт може включати один або кілька лотів. На TED кожен тендер і відповідний(і) контракт(и) мають структурований XML-файл, у якому задокументовано ключові елементи інформації. Ми називаємо їх «tender XML» і «award XML». Приклад тендерного XML-файлу показано на малюнку 1. XML-файли тендеру зазвичай мають однакову структуру. XML-файли тендерів документують таку інформацію, як покупець, лоти, елементи лотів, критерії контракту тощо. XML-файли присудження документують покупця, лоти, постачальників, яким надано контракт для кожного лота, вартість контракту, кількість тощо. Кожен тендер також може мати колекція «додатків», які містять додаткові відомості про тендер, особливо щодо лотів і предметів («додатки до тендеру») Враховуючи наявність XML-файлів тендерів і тендерів, можна вважати завдання розробки та заповнення бази даних нескладним. Однак насправді дані набагато складніші. Перш за все, XML-файли тендеру та угоди часто є неповними. Переважна відсутня інформація – це інформація про лот і позицію. Як приклад, тендерний XML для «2019/S 180-437985» згадує 47 лотів у тендері, без детального опису конкретних позицій, але з посиланням на номер лота. Ця важлива інформація доступна з масового завантаження 7 тендерних вкладень (PDF). І тендер, і тендер XML-файли перехресно посилаються на ці джерела даних за допомогою посилань на лот. Відновлення такої інформації має вирішальне значення для побудови профілю ризику постачальника, який повинен враховувати асортимент і кількість продуктів, які постачальник постачав у минулому. По-друге, не кожен тендерний додаток відповідає нашій меті. Серед тих, що стосуються «2019/S 180-437985», два PDF-файли містять перелік фактичних лотів і позицій (наприклад, малюнок 2), тоді як інші документують специфікації, вимоги, правила та протоколи тощо. По-третє, не кожна сторінка відповідного вкладення містить відповідні інформації. Наприклад, на малюнку 3 показано, що в іншому тендері лоти та елементи описані на одній сторінці, але в різних розділах великого документа. По-четверте, як уже показано на малюнках 2 і 3, існує значна розбіжність у тому, як описується інформація про партії та одиниці в одній країні або навіть в одній організації. Ця невідповідність спостерігалася на різних рівнях, таких як: використання структурованого форматування (наприклад, вільний текст проти таблиць/списків); кількість закодованої інформації (наприклад, таблиця на рисунку 2 містить 16 стовпців (атрибутів) для кожного елемента) навіть для тих самих видів продуктів/послуг; і семантика структури, де прийняті структури (наприклад, порядок і назви стовпців). Такий високий рівень складності та неузгодженості може бути однією з головних причин, чому не вистачає досліджень із аналізу тексту та НЛП або програм для закупівель у сфері охорони здоров’я. Автори: (1) Ziqi Zhang*, Інформаційна школа, Університет Шеффілда, Regent Court, Шеффілд, UKS1 4DP (Ziqi.Zhang@sheffield.ac.uk); (2) Томас Ясайтіс, Vamstar Ltd., Лондон (Tomas.Jasaitis@vamstar.io); (3) Річард Фрімен, Vamstar Ltd., Лондон (Richard.Freeman@vamstar.io); (4) Rowida Alfrjani, Інформаційна школа, Університет Шеффілда, Regent Court, Шеффілд, UKS1 4DP (Rowida.Alfrjani@sheffield.ac.uk); (5) Адам Функ, Інформаційна школа, Університет Шеффілда, Рігентський суд, Шеффілд, UKS1 4DP (Adam.Funk@sheffield.ac.uk). Цей папір є за ліцензією CC BY 4.0. доступний на arxiv [1] https://ted.europa.eu/udl?uri=TED:NOTICE:437985-2019:TEXT:EN:HTML, останній доступ: листопад 2022 р.
