Всякий раз, когда появляется какая-то новая технология, она тонет в гиперболе. Мой Twitter полон «влиятельных лиц», которые утверждают, что создали полноценный веб-сайт с помощью одной подсказки, но любой, кто пытается создавать веб-сайты, знает, что они уже достаточно хороши для реализации небольших функций и погружения в любую долгосрочную задачу с целым репозиторием кода в качестве контекста.
Помните, как нам обещали беспилотные автомобили завтра около десяти лет назад? Беспилотные автомобили — это решенная проблема, сказал Илон Маск, главный мастер хайпа, 8 лет назад .
Пока мы ждали, когда Tesla начнет делать пончики самостоятельно, менее гламурные попытки были в самом разгаре. Mobileye создал датчик, который издает звуковой сигнал, когда вы собираетесь во что-то врезаться. Они спасли бесчисленное количество жизней и сократили страховые иски примерно на 90%. Они построили компанию стоимостью 17 миллиардов долларов.
Я считаю, что понимание документов — это технология Mobileye для LLM. Понимание финансовых таблиц, табулирование страховых требований и выведение медицинских кодов из записей врача кажутся скромными по сравнению с возвышенными мечтами. Но если дважды щелкнуть по этой проблеме, вы обнаружите, что она ранее не была решена, и что она открывает большую ценность.
Десять лет назад я работал в знаменитой команде по стандартизации данных LinkedIn. Мы пытались решить одну обманчиво простую проблему: как понять резюме, независимо от того, откуда оно взято, и сопоставить его заголовки с небольшим набором признанных заголовков?
Вы могли бы подумать, что это будет легко. Я имею в виду, «инженер-программист» — довольно простая должность, верно? Но что, если кто-то напишет «ассоциированный»? Они могут расставлять товары на полках или получать шестизначную зарплату в юридической фирме. Что такое Station Hand (австралийский ковбой), что такое consultant (может означать advisor/freelance, но может означать Doctor, если вы британец и у вас есть для этого подходящее образование)? Если вы пытаетесь вписать названия должностей в список распознаваемых элементов, чтобы можно было индексировать для поиска, продаж и т. д. — как бы вы построили модель, которая знает нюансы всех языков и культур и не перепутала бы «исполнительного помощника» с руководителем, в то время как помощник регионального менеджера на самом деле является заместителем регионального менеджера?
Хорошо, это хорошо, но если я работаю в LinkedIn , мне понадобятся конкретные типы данных. Мне нужен JSON .
Необходимо больше работы, чтобы сопоставить названия должностей со стандартной таксономией — конечным списком приемлемых предопределенных названий должностей. Но вы можете видеть, как то, что было очень сложным в прошлом, становится тривиальным.
Чтение резюме — это хороший вариант использования, но я не думаю, что это революционно. LinkedIn — технологическая компания, и она всегда применяла самые острые бритвы к этой проблеме. Она может стать немного лучше, но мы всего лишь заменяем один процесс автоматизации кода другим.
Все становится гораздо интереснее, когда вы заменяете нудный ручной труд. Огромная часть экономики основана на людях, выполняющих экспертные задачи, которые сводятся к «чтению документа, выяснению того, что в нем говорится, и повторению этого процесса до тошноты».
Позвольте мне привести вам несколько примеров:
Управление расходами: у вас есть счет, и кто-то должен превратить его в список цифр — что было оплачено, кому и в какой валюте. Звучит просто? Не тогда, когда он завален лишней информацией, неполными таблицами или PDF-файлами, которые выглядят так, будто кто-то пропустил их через блендер.
Обработка медицинских претензий: Это кошмар, который решает армия арбитров по медицинским претензиям. Они просеивают горы счетов, записок врачей и счетов-фактур, которые все должны собраться в запутанный беспорядок с дубликатами, и должны сопоставить это с существующим полисом медицинского страхования и выяснить, покрывается ли плата, в какой категории и на какую сумму. Но когда вы доходите до этого, это в основном просто чтение, сортировка и маркировка. Решения несложные; проблема заключается в извлечении данных.
Андеррайтинг кредита: проверка банковских выписок и категоризация денежных потоков. Опять же, это больше касается структурирования неструктурированной информации, чем ракетостроения.
Гламурно? Нет. Полезно? Я так думаю.
В настоящее время LLM печально известны своими галлюцинациями — то есть выдумыванием дерьма. Но реальность более тонка: галлюцинации ожидаются, когда вы просите о мировых знаниях, но они, по сути, устраняются при выполнении обоснованной задачи .
LLM не особенно хороши в оценке того, что они «знают» — скорее, это побочный продукт удачи, что они вообще могут это делать, поскольку их специально этому не обучали. Их основная подготовка заключается в прогнозировании и завершении текстовых последовательностей. Однако, когда LLM получает обоснованную задачу — такую, где для прогнозирования требуются только явно предоставленные ему входные данные, частота галлюцинаций может быть сведена практически к нулю. Например, если вы вставите этот пост в блог в ChatGPT и спросите, объясняет ли он, как ухаживать за вашим домашним хорьком, модель даст правильный ответ в 100% случаев. Задача становится предсказуемой. LLM умело обрабатывают фрагмент текста и предсказывают, как компетентный аналитик заполнит пробелы, одним из которых может быть {“ferret care discussion”: false}.
Как бывший консультант по ИИ, мы работали над проектами, направленными на извлечение информации из документов, особенно в таких отраслях, как страхование и финансы. Распространенным страхом было «галлюцинации LLM», но на практике самые большие проблемы часто были связаны с ошибками при извлечении таблиц или другими несоответствиями ввода. LLM терпят неудачу только тогда, когда мы не можем предоставить им чистые, недвусмысленные вводные данные. Для успешной автоматизации обработки документов есть два ключевых компонента:
Идеальное извлечение текста – это включает преобразование документа в чистый, машиночитаемый текст, включая обработку таблиц, рукописных заметок или различных макетов. LLM нужен ясный, понятный текст для работы.
Надежные схемы . Эти схемы должны определять, какие выходные данные вы ищете, как обрабатывать пограничные случаи и формат данных, гарантируя, что система точно знает, что извлекать из каждого типа документа.
Разрыв между потенциальными рисками галлюцинаций и реальными техническими препятствиями может быть огромным, но, имея эти основы, вы можете эффективно использовать степень магистра права в рабочих процессах обработки документов.
Вот что заставляет LLM-программы зависать и выдавать смехотворно плохие результаты:
Всегда полезно помнить, какой сумасшедший беспорядок творится в реальных документах. Вот случайная налоговая форма:
Конечно, в настоящих налоговых формах все эти поля заполнены, часто рукописно.
Или вот мое резюме
Или общедоступный пример лабораторного отчета (это результат на первой странице поиска Google)
Кстати, самое худшее, что вы можете сделать, это попросить мультимодальные возможности GPT транскрибировать таблицу. Попробуйте, если осмелитесь — на первый взгляд выглядит правильно, но в некоторых ячейках таблицы выдает совершенно случайные вещи, полностью вырывает вещи из контекста и т. д.
Когда нам с моим соучредителем Нитаем Дином поручили разобраться в подобных документах, мы были озадачены тем, что не существует готовых решений для понимания этих текстов.
Некоторые утверждают, что решают эту проблему, например, AWS Textract. Но они делают множество ошибок в любом сложном документе, который мы тестировали. Затем у вас есть длинный хвост мелких необходимых вещей, таких как распознавание галочек, радиокнопок, зачеркнутого текста, рукописных каракулей на форме и т. д. и т. п.
Итак, мы создали Docupanda.io — который сначала генерирует чистое текстовое представление любой страницы, которую вы ему подкидываете. Слева вы увидите исходный документ, а справа — текстовый вывод.
Аналогично обрабатываются и таблицы. Под капотом мы просто преобразуем таблицы в формат markdown, понятный человеку и LLM:
Последний этап осмысления данных с помощью LLM — это генерация и соблюдение жестких форматов вывода. Замечательно, что мы можем заставить ИИ формировать свой вывод в JSON, но чтобы применять правила, рассуждения, запросы и т. д. к данным, нам нужно заставить его вести себя регулярно. Данные должны соответствовать предопределенному набору слотов, которые мы заполним содержимым. В мире данных мы называем это Схемой .
Причина, по которой нам нужна схема, заключается в том, что данные бесполезны без регулярности. Если мы обрабатываем записи пациентов, и они сопоставляются с «мужской» «Мужской» «м» и «М» — мы делаем ужасную работу.
Так как же построить схему? В учебнике вы можете построить схему, долго и упорно сидя и глядя в стену, и определяя, что вы хотите извлечь. Вы сидите там, обдумываете операцию с данными здравоохранения и говорите: «Я хочу извлечь имя пациента, дату, пол и имя его врача. О, и пол должен быть М/Ж/Другой».
В реальной жизни, чтобы определить, что извлечь из документов, вы чертовски долго смотрите на свои документы... Вы начинаете с чего-то вроде вышеизложенного, но затем вы смотрите на документы и видите, что в одном из них есть СПИСОК врачей вместо одного. А в некоторых из них также указан адрес врачей. В некоторых адресах есть номер подразделения и номер здания, так что, возможно, вам нужен слот для этого. И так далее.
Мы пришли к выводу, что возможность точно определить, что именно нужно извлечь, — это нетривиальная и сложная задача, но при этом вполне решаемая с помощью ИИ.
Это ключевая часть DocuPanda. Вместо того, чтобы просто просить LLM импровизировать вывод для каждого документа, мы создали механизм, который позволяет вам:
В итоге вы получаете мощную схему JSON — шаблон, который точно описывает, что именно вы хотите извлечь из каждого документа, и сопоставляет сотни тысяч документов, извлекая ответы на все из них, соблюдая при этом такие правила, как всегда извлекать даты в одном и том же формате, учитывать набор предопределенных категорий и т. д.
Как и в любой кроличьей норе, всегда есть больше вещей, чем кажется на первый взгляд. Со временем мы обнаружили, что требуется больше вещей:
Часто организациям приходится иметь дело с входящим потоком анонимных документов, поэтому мы автоматически классифицируем их и решаем, какую схему к ним применить.
Документы иногда представляют собой объединение многих документов, и вам необходимо интеллектуальное решение для разбиения очень длинных документов на отдельные атомарные компоненты.
Запрос нужных документов с использованием сгенерированных результатов очень полезен
Если есть один вывод из этого поста, так это то, что вам следует рассмотреть возможность использования LLM для понимания документов обычным способом. Если есть два вывода, так это то, что вам также следует попробовать Docupanda.io . Причина, по которой я создаю его, заключается в том, что я верю в него. Может быть, это достаточная причина, чтобы попробовать?