paint-brush
ШІ справді добре розуміє документиза@uri
Нова історія

ШІ справді добре розуміє документи

за Uri Merhav9m2024/09/09
Read on Terminal Reader

Надто довго; Читати

Не гламурно, але насправді корисно. LLM дуже добре розуміють вміст документа та витягають із нього інформацію. Їм просто потрібно трохи любові з хорошим OCR і розумінням таблиці.
featured image - ШІ справді добре розуміє документи
Uri Merhav HackerNoon profile picture
0-item

Ви хотіли, щоб роботи готували вашу каву, але замість цього ви отримуєте структуровані виходи JSON із документів.

Щоразу, коли з’являється якась нова технологія, вона тоне в гіперболі. Мій Твіттер повний «інфлюенсерів», які стверджують, що створили повноцінний веб-сайт за допомогою однієї підказки, але будь-хто, хто намагається створювати веб-сайти, знає, що наразі вони достатньо хороші, щоб реалізувати невеликі функції та піти на глибокий кінець будь-якого довгострокове завдання з цілим сховищем коду як контекстом.


Пам’ятаєте, десять років тому нам обіцяли завтра безпілотні автомобілі? Безпілотне керування — це вирішена проблема, — сказав 8 років тому Ілон Маск, найбільший хайп-майстер.


Поки ми чекали, поки Tesla почнуть виготовляти пончики самостійно, менш гламурні спроби йшли повним ходом. Mobileye створив датчик, який подає звуковий сигнал, коли ви збираєтесь натрапити на щось. Вони врятували незліченну кількість життів і зменшили страхові виплати приблизно на 90%. Вони створили компанію вартістю 17 мільярдів доларів.


Я вважаю, що розуміння документів – це технологія Mobileye для магістратури. Розуміння фінансових таблиць, складання таблиць страхових вимог і висновок про медичні коди з нотаток лікаря здається скромним порівняно з високими мріями. Але якщо ви двічі клацнете на цій проблемі, ви побачите, що вона раніше не була вирішена і що вона відкриває багато цінності.

Передісторія

Десять років тому я працював у видатній команді зі стандартизації даних LinkedIn. Ми намагалися вирішити одну оманливо просту проблему: як зрозуміти резюме, незалежно від того, звідки воно походить, і зіставити його заголовки з невеликим набором визнаних заголовків?


Можна подумати, що це буде легко. Я маю на увазі, що «інженер програмного забезпечення» — це досить проста назва, чи не так? А якщо хтось напише «співробітник»? Вони могли складати полиці або отримувати шестизначну зарплату в юридичній фірмі. Що таке робочий на станції (австралійський ковбой), що таке консультант (може означати радник/фрілансер, але це може означати доктор, якщо ви британець і маєте відповідну освіту для цього)? Якщо ви намагаєтеся вписати назви посад у список розпізнаних елементів, щоб ви могли індексувати для пошуку, продажів тощо, як би ви побудували модель, яка б знала нюанси всіх мов і культур і не сплутала «Помічник виконавчого директора» з бути виконавчою, а помічник регіонального менеджера справді є заступником регіонального менеджера?


Добре, це добре, але якщо я працюю на LinkedIn , мені знадобляться конкретні типи даних. Я хочу JSON .


Потрібна додаткова робота, щоб зіставити назви посад у стандартну таксономію – кінцевий список прийнятних попередньо визначених назв посад. Але ви можете побачити, як те, що було дуже важко в минулому, стає тривіальним.

Офісна робота стає майданчиком для штучного інтелекту

Читання резюме є гарним випадком використання, але я думаю, що це не є революцією. LinkedIn є технологічною компанією, яка завжди застосовувала для вирішення проблеми одні з найгостріших бритв. Це може бути дещо краще, але ми лише замінюємо один процес автоматизації коду іншим.


Справи стають набагато цікавішими, якщо замінити виснажливу ручну працю. Величезний шматок економіки базується на тому, що люди виконують експертні завдання, які зводяться до «читання документа, з’ясування, що в ньому написано, і повторення цього процесу до нудоти».


Дозвольте навести кілька прикладів:

  • Управління витратами: у вас є рахунок-фактура, і хтось має перетворити його на список цифр — що було сплачено, кому та в якій валюті. Звучить просто? Не тоді, коли він похований у безладі додаткової інформації, неповних таблиць або PDF-файлів, які виглядають так, наче хтось пропустив їх крізь блендер.


  • Обробка претензій щодо охорони здоров’я: це кошмар, який розв’язує ціла армія суддів у сфері охорони здоров’я. Вони перебирають гори рахунків-фактур, довідок лікарів і рахунків-фактур, які мають зібратися в заплутаний безлад із дублікатами, і мають зіставити це з існуючим полісом медичного страхування та з’ясувати, чи покривається плата, за якою категорією та на яку суму. Але коли ви переходите до цього, це здебільшого просто читання, сортування та маркування. Рішення неважкі; викликом є вилучення даних.


  • Андеррайтинг кредиту: перегляд банківських виписок і класифікація грошових потоків. Знову ж таки, це більше стосується структурування неструктурованої інформації, ніж ракетобудування.


Гламурний? Ні. Корисно? Я так думаю.

Вилучення документів є обґрунтованим завданням

На даний момент LLM сумно відомі галюцинаціями, тобто вигадуванням лайна. Але реальність більш нюансована: галюцинації очікуються, коли ви просите знання світу, але в основному усуваються в обґрунтованому завданні .


LLM не дуже добре оцінюють те, що вони «знають» — це радше побічний продукт того, що вони взагалі можуть це робити, оскільки їх спеціально для цього не навчали. Їхня основна підготовка полягає в тому, щоб передбачати та завершувати текстові послідовності. Однак, коли перед магістром права дається обґрунтоване завдання – таке, де для прогнозування потрібні лише явно надані йому вхідні дані, рівень галюцинацій можна знизити практично до нуля. Наприклад, якщо ви вставите цю публікацію блогу в ChatGPT і запитаєте, чи вона пояснює, як доглядати за вашим домашнім тхором, модель дасть правильну відповідь у 100% випадків. Завдання стає передбачуваним. LLM вміють опрацьовувати шматок тексту та передбачити, як компетентний аналітик заповнить пробіли, одним із яких може бути {«обговорюється догляд за тхором»: false}.


Як колишній консультант зі штучного інтелекту ми працювали над проектами, спрямованими на отримання інформації з документів, зокрема в таких галузях, як страхування та фінанси. Загальноприйнятим побоюванням було те, що «LLM галюцинують», але на практиці найбільші проблеми часто виникали через помилки під час вилучення таблиць або інші невідповідності введених даних. LLM зазнають невдачі лише тоді, коли ми не зможемо представити їм чисті, недвозначні вхідні дані. Є два ключових компоненти успішно автоматизовано обробку документів:


  1. Ідеальне вилучення тексту – це включає в себе перетворення документа в чистий, машиночитаний текст, включаючи обробку таблиць, рукописних нотаток або різноманітних макетів. LLM потребує чіткого, зрозумілого тексту для роботи.


  2. Надійні схеми – ці схеми мають визначати, які результати ви шукаєте, як обробляти граничні випадки та формат даних, гарантуючи, що система точно знає, що витягти з кожного типу документа.


Розрив між потенційними ризиками галюцинації та фактичними технічними перешкодами може бути величезним, але з цими фундаментальними засадами ви можете ефективно використовувати LLM у робочих процесах обробки документів.


Вилучення тексту складніше, ніж здається на перший погляд

Ось що спричиняє збій і згоряння LLM і отримують неймовірно погані результати:

  1. Вхідні дані мають складне форматування, як макет із двома стовпцями, і ви копіюєте та вставляєте текст із, наприклад, PDF-файлу зліва направо, повністю вириваючи речення з контексту.
  2. У введених даних є прапорці, галочки, написані вручну анотації, які ви взагалі пропустили під час перетворення на текст
  3. Ще гірше: ви думали, що можете обійти конвертацію в текст, і сподіваєтеся просто вставити зображення документа, і GPT обґрунтує це самостійно. ЦЕ перенесе вас у місто галюцинацій. Просто попросіть GPT транскрибувати зображення таблиці з кількома порожніми клітинками, і ви побачите, як вона весело скаже і щось вигадує.


Це завжди допомагає пам’ятати, який божевільний безлад відбувається в документах реального світу. Ось довільна податкова форма:

Джерело: наш дружній збирач податків у уряді США


Звичайно, у справжніх податкових формах усі ці поля заповнені, часто рукописно


Або ось моє резюме

Джерело: я


Або загальнодоступний приклад лабораторного звіту (це результат Google на першій сторінці)



Джерело: Research Gate, зображення у відкритому доступі


До речі, найгірше, що ви можете зробити, це попросити мультимодальні можливості GPT транскрибувати таблицю. Спробуйте, якщо наважитесь — це виглядає правильно на перший погляд, абсолютно випадково змінює деякі клітинки таблиці, повністю вириває речі з контексту тощо.

Якщо зі світом щось не так, створіть компанію SaaS, щоб це виправити

Коли ми з моїм співзасновником Нітаєм Діном поставили завдання розібратися в таких документах, ми були збентежені тим, що не існує жодних готових рішень для того, щоб зрозуміти ці тексти.


Деякі люди стверджують, що вирішують це, наприклад AWS Texttract. Але вони роблять численні помилки в будь-якому складному документі, який ми тестували. Потім у вас є довгий хвіст дрібних необхідних речей, як-от розпізнавання галочок, радіокнопок, перекресленого тексту, рукописних каракулів на формі тощо.


Отже, ми створили Docupanda.io — який спочатку генерує чисте текстове представлення будь-якої сторінки, яку ви на нього накидаєте. Ліворуч ви побачите оригінальний документ, а праворуч ви побачите вихідний текст.


Джерело: docupanda.io


Таблиці обробляються аналогічно. Під капотом ми просто конвертуємо таблиці у формат уцінки, який читається людиною та LLM:

Джерело: docupanda.io


Останньою частиною розуміння даних за допомогою LLM є створення та дотримання жорстких вихідних форматів. Чудово, що ми можемо змусити штучний інтелект формувати свій вихід у JSON, але щоб застосовувати правила, міркування, запити тощо до даних, нам потрібно змусити його працювати регулярно. Дані мають відповідати попередньо визначеному набору слотів, які ми заповнюємо вмістом. У світі даних ми називаємо це схемою .

Створення схем — це процес проб і помилок... Це LLM може зробити

Причина, по якій нам потрібна схема, полягає в тому, що дані марні без регулярності. Якщо ми обробляємо записи пацієнтів, і вони відображаються на «чоловіки», «чоловіки», «m» і «M» — ми робимо жахливу роботу.


Отже, як створити схему? У підручнику ви можете побудувати схему, довго сидячи, дивлячись на стіну та визначаючи, що ви хочете витягти. Ви сидите там, обмірковуєте свою операцію з даними охорони здоров’я та говорите: «Я хочу отримати ім’я пацієнта, дату, стать та ім’я його лікаря. О, і стать повинна бути M/F/Other.


У реальному житті, щоб визначити, що витягти з документів, ви дивитеся на свої документи… багато. Ви починаєте з чогось подібного до вищезазначеного, але потім дивитесь на документи й бачите, що в одному з них є СПИСОК лікарів замість одного. А в деяких із них вказана ще й адреса лікарів. Деякі адреси мають номер підрозділу та номер будівлі, тож, можливо, для цього вам потрібен слот. Все далі і далі.


Те, що ми зрозуміли, так це те, що можливість точно визначити, які саме речі ви хочете витягти, є нетривіальною, важкою та легко вирішуваною за допомогою ШІ.


Це ключова частина DocuPanda. Замість того, щоб просити магістра імпровізувати результат для кожного документа, ми створили механізм, який дозволяє вам:


  1. Укажіть, що вам потрібно отримати з документа вільною мовою
  2. Налаштуйте наш штучний інтелект на карту багатьох документів і створіть схему, яка відповідає на всі запитання та враховує недоліки та невідповідності, які спостерігаються у фактичних документах.
  3. Змініть схему за допомогою відгуків, щоб адаптувати її до потреб вашого бізнесу


У кінцевому підсумку ви отримуєте потужну схему JSON — шаблон, який точно вказує, що ви хочете отримати з кожного документа, і відображає сотні тисяч із них, вилучаючи відповіді на всі з них, дотримуючись правил, як-от завжди витягувати дати в той самий формат із дотриманням набору попередньо визначених категорій тощо.

Джерело: docupanda.io

Багато іншого!

Як і в будь-якій кролячій норі, тут завжди більше речей, ніж здається на перший погляд. З часом ми виявили, що потрібно більше речей:

  • Часто організаціям доводиться мати справу з вхідним потоком анонімних документів, тому ми автоматично класифікуємо їх і вирішуємо, яку схему до них застосовувати

  • Документи іноді є об’єднанням багатьох документів, і вам потрібне інтелектуальне рішення, щоб розбити дуже довгі документи на атомарні, окремі компоненти

  • Запитувати потрібні документи за допомогою згенерованих результатів надзвичайно корисно


Якщо з цього допису можна зробити один висновок, то це те, що вам слід розглянути можливість використовувати LLM для того, щоб звичайним чином зрозуміти документи. Якщо є два висновки, то це те, що ви також повинні спробувати Docupanda.io . Причина, чому я будую це, полягає в тому, що я вірю в це. Можливо, це вагома причина, щоб спробувати?


Майбутній офісний працівник (Джерело: unsplash.com)