От сбора данных до ИИ-агентов: как команды разработчиков используют Document Intelligence — Адит Абрахам, Reducto

Transcript

00:00:00Всем привет, меня слышно? Отлично. У нас есть всего 20 минут, так что давайте сделаем
00:00:20всё быстро. Меня зовут Дит, я сооснователь и CEO Reducto. Сегодня мы хотим поговорить
00:00:25об одной практичной, но, возможно, не самой гламурной части создания агентов, работающих в реальном мире, — о данных. Уверен, вы уже слышали сегодня много докладов о данных. Мы же сфокусированы на инфраструктуре для работы с самыми сложными источниками: неструктурированными изображениями, PDF, таблицами — всем, с чем люди привыкли работать ежедневно. Кто-то из вас уже использовал Reducto или протестировал его? Круто.
00:00:55Думаю, полезно начать с контекста: мы — агентская платформа для обработки документов. Мы помогаем ведущим ИИ-командам мира строить ИИ-приложения и рабочие процессы.
00:01:08Среди них много ИИ-стартапов, о которых вы сегодня слышали: Harvey, Legor, Rogo, а также крупнейшие корпорации. И это важный контекст для нашей темы.
00:01:19Мы работаем с IT-гигантами, мировыми финансовыми институтами, страховщиками — организациями с десятилетними архивами данных, которые раньше было почти невозможно использовать за пределами демо-версий.
00:01:34На данный момент мы обработали миллиарды документов для наших клиентов. Я уже перестал обновлять плюс в конце этой цифры, она постоянно растёт, так что пусть остаётся так.
00:01:46Главный вывод из этого опыта, о котором я хочу поговорить, касается не самого продукта Reducto.
00:01:51Это тонкости, которые мы узнали и которые, надеюсь, вы сможете применить в своей работе.
00:01:58Многие наши наработки связаны с тем, что масштабы ИИ-приложений за последнее время сильно изменились.
00:02:07От простых продуктов для обобщения информации до полноценных автономных агентов.
00:02:13И тут есть несколько ключевых моментов, о которых стоит порассуждать.
00:02:16Во-первых, постановка проблемы и узкие места: почему именно PDF сложны, хотя в X вы видели десятки запусков сервисов для их обработки.
00:02:26Где мы видим сильные и слабые стороны разных инструментов.
00:02:31Мы считаем, что есть своё время и место как для традиционного Computer Vision, так и для VLM.
00:02:35А во второй части выступления мы поговорим о новых рубежах.
00:02:40О том, что стало возможно благодаря участию агентов в цикле обработки.
00:02:43Что мы заметили при использовании тестовых сред для разных типов задач.
00:02:47И наши выводы об оценке качества при переходе от RAG к агентским продуктам.
00:02:53Но начну я с первого пункта, о котором наверняка уже много говорили.
00:02:58Если бы вы пришли на AI Engineer пару лет назад, то на каждом докладе слышали бы слово RAG.
00:03:04Тогда абсолютно все строили те или иные RAG-приложения.
00:03:07Одно время все сервисы сводились к извлечению и синтезу информации, верно?
00:03:12Вы подтягивали данные из контекста — будь то идеальный промпт или загруженный пользователем файл.
00:03:19И делали что-то вроде поискового продукта.
00:03:22Внедряли корпоративный поиск.
00:03:23Или чат-бота, который ответит на простые вопросы по контенту.
00:03:27На этом всё и ограничивалось.
00:03:28Но сегодня главное модное слово, которое вы слышали уже миллион раз, — это агенты.
00:03:34И инженеры среди вас, вероятно, уже поручают Claude Code или аналогичным утилитам выполнение задач от начала до конца.
00:03:41И подобный сдвиг начинается во всех сферах офисной работы.
00:03:46В финансах, страховании или медицине решения начинают приниматься автоматически.
00:03:51Создаются готовые рабочие продукты: не просто ответы на вопросы по PDF, а создание и редактирование этих PDF.
00:03:58И это совсем другой подход.
00:04:00Инструменты и проблемы сильно отличаются от того, с чем сталкиваешься при построении обычной поисковой системы.
00:04:06Суть в том, что в многошаговых пайплайнах эта проблема становится еще более критичной.
00:04:18При обычных ответах на вопросы риск ошибиться касается только одного ответа.
00:04:24Но когда агенты принимают цепочку решений на основе массива файлов и данных из разных источников, риск плохих входных данных становится разрушительным.
00:04:36И именно на этом мы и фокусируемся.
00:04:38Ведь ценность языковых моделей в реальном мире зависят от того, к какому контексту вы этот интеллект применяете.
00:04:48У большинства компаний данные неструктурированы, разрознены и мультимодальны.
00:04:53Это далеко не аккуратно организованное хранилище.
00:04:56Разные отделы сбрасывают файлы в Google Drive, Box и куда угодно ещё.
00:05:04Вы сталкиваетесь с изначально неструктурированными форматами.
00:05:07Вы толком не знаете, что именно лежит в вашей базе знаний.
00:05:11И из этого вытекает масса проблем на следующих этапах.
00:05:14Часть из них касается точности парсинга и извлечения, что невероятно важно.
00:05:18Но проблемы также связаны и с тем, извлекается ли правильный контекст.
00:05:22И с тем, как вы взаимодействуете с этим контекстом и вносите в него изменения.
00:05:27И то, о чем твердим мы в Reducto и другие в нашей сфере: PDF, как ни странно, всё ещё очень сложная проблема.
00:05:36Не знаю, следит ли кто-то из вас за Surge — лабораторией данных, работающей с разработчиками базовых моделей.
00:05:42У них есть классный бенчмарк GDP PDF, где даже передовые модели показывают точность всего около 30%.
00:05:52И всё строится на идее: могут ли модели изучать документы вроде PDF и принимать на их основе правильные решения.
00:06:01Причина этой сложности в том, что формат PDF старый и создавался для совершенно других задач.
00:06:11Я встречал людей, которые занимаются обработкой PDF дольше, чем я живу.
00:06:16Я общался с теми, кто разрабатывал драйверы печати PDF ещё в начале 1990-х.
00:06:21И суть была именно в этом.
00:06:22Нужно было точно передать исходный вид документа, чтобы его можно было без искажений распечатать.
00:06:30Сегодня же требования совершенно иные.
00:06:33Нам нужно представление в формате Markdown, с которым агентам будет удобно рассуждать.
00:06:39А люди кодируют визуально огромный объем контекста.
00:06:44Обычный начинающий аналитик в инвестбанке вовсе не думает о том, сможет ли агент распарсить его презентацию.
00:06:54Они верстают креативные слайды.
00:06:57Вы наверняка видели слайды SoftBank с курицей, несущей золотые яйца.
00:07:01И эти детали имеют значение.
00:07:02Понимаете?
00:07:03Большая часть данных для анализа — это таблицы без чётких границ и с объединёнными ячейками.
00:07:10Там будут графики и диаграммы.
00:07:12Там будет неразборчивый почерк, который даже человеку трудно разобрать.
00:07:17И именно такие проблемы нужно решать при работе с длинным хвостом сложных документов.
00:07:22Мы основали компанию в 2023 году, почувствовав качественный сдвиг в возможностях.
00:07:29Долгое время обработка PDF представляла собой модификацию стандартного NLP-пайплайна.
00:07:37Делался простой прогон через OCR, а затем пытались постобработать текст.
00:07:41И это работало, когда макеты документов были одинаковыми.
00:07:44Так ведь?
00:07:45Если вы знаете, что справка W-2 всегда выглядит одинаково, проблему легко закрыть шаблонами.
00:07:51Но VLM интересны тем, что они универсальны по своей природе.
00:07:56Впервые появился подход: «читай документ так, как это сделал бы человек».
00:08:01И мы смогли эффективно работать с редкими кейсами.
00:08:04Они отлично проявили себя в считывании рукописного текста, с чем обычный OCR не справлялся.
00:08:12Обратная сторона в том, что VLM — это не серебряная пуля.
00:08:16И если вы решаете задачу в масштабах компании с сотнями миллионов документов,
00:08:21возникают вторичные факторы вроде детерминированности.
00:08:25Вас сильно волнует эффективность обработки.
00:08:27Поэтому в некоторых задачах традиционный CV до сих пор очень силен.
00:08:33И это недооценивают, хотя технологии из сферы автопилотов сильно продвинулись.
00:08:37Методы вроде детекции объектов стали куда совершеннее, чем 10 лет назад.
00:08:42И модели объёмом до 100 млн параметров отлично определяют макет документа.
00:08:48Можно зайти очень далеко даже без использования больших базовых моделей.
00:08:52И эти модели могут работать прямо на CPU.
00:08:54Их можно запускать в огромных масштабах.
00:08:55Точечно определяя на уровне областей, какие элементы будут сложны для разбора.
00:09:00А VLM добавляют сюда понимание семантики.
00:09:03Вы можете находить и исправлять ошибки, вероятные для вашего пайплайна.
00:09:09Разбирая проблему на основе семантики и видя все нюансы,
00:09:18когда текст на странице сегментирован и понятно, где рукописный ввод,
00:09:21можно подключить агента прямо в процесс.
00:09:25Раньше разметку и исправление ошибок делала команда асессоров,
00:09:29а теперь VLM дают возможность реализовать концепцию «агентского OCR».
00:09:33Для нас это похоже на то, как Cursor делает быстрые правки в IDE:
00:09:41там применяется спекулятивное декодирование с правками на уровне токенов.
00:09:45Похожий принцип можно применить и здесь: не просто отправлять OCR в Gemini,
00:09:51написав красивый промпт с вежливой просьбой не отходить от оригинала.
00:09:56Потому что при генерации следующего токена
00:09:58появляются новые сценарии потерь, когда очень умные модели
00:10:02начинают исправлять текст вопреки тому, что написано в документе.
00:10:05Они видят слово «Итого», и если человек ошибся в таблице,
00:10:08модели могут сами пересчитать и подставить «правильную» сумму.
00:10:13А вам нужны только точечные правки токенов.
00:10:16Исправить точку на запятую или ноль на букву О —
00:10:19именно такие детали невероятно важны.
00:10:21Задача сводится к тому, чтобы передать то, что увидел бы человек,
00:10:25если бы сам прочитал этот документ.
00:10:27Агентский OCR работает как раз как аналог проверки человеком:
00:10:34первичные данные прогоняются через парсинг с помощью CV и VLM,
00:10:39а затем слой верификации и коррекции выдаёт результат с высокой точностью.
00:10:44Но, как я говорил, спектр задач не ограничивается лишь парсингом и извлечением.
00:10:50Важно детально продумать каждый шаг вашего пайплайна,
00:10:56даже если у вас отличный конвертер документов в Markdown.
00:10:59Отличный пример: если вы строили RAG-платформу,
00:11:04вы наверняка размышляли над обработкой таблиц.
00:11:07Многие вещи можно отлично закодировать в том же Markdown.
00:11:13Но в таблицах вроде этой, где объединённые ячейки несут важный смысл,
00:11:18принципиально важно сохранять подобную структуру.
00:11:20И дело не в ограничениях модели.
00:11:22LLM невероятно эффективно анализируют HTML-структуру такой же таблицы,
00:11:26но при этом расходуется куча токенов, и это быстро становится дорогим.
00:11:29С другой стороны,
00:11:31вы вряд ли захотите кодировать простые таблицы в HTML,
00:11:35поскольку тогда появится множество лишних HTML-тегов.
00:11:38В итоге мы подошли к этому как к динамической задаче:
00:11:42если таблица простая — отлично, репрезентуем эти данные в Markdown.
00:11:47Если же таблица более сложная, уместно использовать HTML.
00:11:50Однако при проектировании пайплайна стоит учитывать не только языковые модели.
00:11:55Если вы работаете с эмбеддингами,
00:11:57вы неизбежно столкнетесь со второй проблемой — поиском этого контекста.
00:12:01Та же таблица, которую я показывал ранее,
00:12:03в формате HTML выглядит крайне перегруженной.
00:12:08Подавляющее большинство фрагмента — это просто HTML-теги,
00:12:11которые лишь описывают структуру документа.
00:12:14И досадно то, что если в общих бенчмарках
00:12:17контент может пытаться выполнять работу за модель,
00:12:22явно указывая именно то, что вы ищете,
00:12:24то реальный пользователь не перечисляет значения из таблицы.
00:12:28Он просто спросит: «Как менялась выручка с течением времени?»
00:12:30И рассчитывает, что вы подтянете нужную таблицу, когда это будет актуально.
00:12:34И хотя языковые модели способны эффективно размышлять над этим текстом,
00:12:37при выборке из крупного корпуса
00:12:39модели эмбеддингов с трудом сопоставляют пользовательский запрос на естественном языке
00:12:44с этой хаотичной мешаниной из чисел и HTML-тегов.
00:12:47Поэтому мощное решение, не требующее больших усилий,
00:12:51— это создание представления, адаптированного под саму модель эмбеддингов.
00:12:55Беря ту же таблицу,
00:12:56вы формируете её описание на естественном языке,
00:12:58чтобы получить лучшее из обоих миров.
00:13:00Передавая данные в модель для логического анализа,
00:13:02вы используете представление таблицы в HTML,
00:13:04а когда хотите гарантировать точный поиск нужных фрагментов —
00:13:07применяете текстовый блок на естественном языке.
00:13:12Кроме того, существует понимание, что задачи выходят далеко за рамки парсинга и извлечения.
00:13:18Думаю, индустрия исторически фокусировалась именно на парсинге и извлечении,
00:13:22поскольку здесь мы видим огромный потенциал для роста.
00:13:25Ранее я упоминал бенчмарк GDP PDF,
00:13:30который служит отличным наглядным примером того, чего можно достичь
00:13:34за счет усовершенствования пайплайна данных.
00:13:37Мы обнаружили, что если взять тот же самый бенчмарк,
00:13:40о котором я говорил — к сожалению, мы не смогли протестировать его на Fable,
00:13:43так как нам закрыли доступ.
00:13:46Но если протестировать другие модели, передав им как оригинальный PDF,
00:13:50так и его структурированное представление,
00:13:52например, результаты парсинга,
00:13:55то независимо от модели — будь то Gemini, Anthropic или OpenAI —
00:13:58итоговая производительность LLM повышается только благодаря более качественным входным данным.
00:14:04Это доходит до того, что модели уровня GPT-4.5 и Opus
00:14:09превосходят системы вроде Fable «из коробки».
00:14:12И дело не только в точности: получая лучшие вводные данные,
00:14:17модели расходуют меньше токенов на рассуждения.
00:14:20Они меньше отвлекаются на интерпретацию данных и сфокусированы на итоговом результате.
00:14:24В итоге снижается задержка,
00:14:27а верный ответ формируется быстрее.
00:14:30Но даже когда такой пайплайн уже настроен
00:14:33и вы досконально проверили всё
00:14:37на уровне парсинга, значительный объем работы человека по-прежнему заключается в том,
00:14:41чтобы понять разнообразие данных в вашем корпусе,
00:14:44направить их в нужный пайплайн, декомпозировать задачу
00:14:48или даже отредактировать и изменить итоговые документы.
00:14:51Поэтому мы постарались взглянуть на проблему под углом:
00:14:54как сделать так, чтобы каждое взаимодействие языковой модели
00:14:57с документом было настолько же эффективным, как если бы его обрабатывал человек?
00:15:00Если вы заполняете форму, как обеспечить точность
00:15:03при вводе данных в нужные поля?
00:15:05Отличным примером с точки зрения оркестрации
00:15:08служит классификация и разделение, которые часто недооценивают
00:15:12как способ выжать максимум из LLM.
00:15:14Разумеется, можно просто взять и загрузить весь доступный контекст.
00:15:17И если вы проводите тест вроде «иголка в стоге сена»,
00:15:19это может сработать.
00:15:20Но на практике избыток информации ведет не только к перерасходу токенов,
00:15:24но и к ощутимому снижению качества ответа.
00:15:28Мы же видим огромный задел для улучшения в том,
00:15:33чтобы грамотно классифицировать нужные документы
00:15:36и направлять их в соответствующий пайплайн.
00:15:38Даже при работе с крупными документами важно гарантировать,
00:15:41что вы передаете только действительно релевантные фрагменты.
00:15:43Мы сталкиваемся со сценариями, когда клиенты получают бумажную корреспонденцию,
00:15:47и эти пакеты документов могут насчитывать сотни страниц.
00:15:50Вы заранее не знаете, что именно окажется внутри.
00:15:53Например, страницы могли случайно перепутать при сканировании,
00:15:57и если заставлять модель разбираться с такой сортировкой,
00:16:01это будет лишь отвлекать её от основной задачи —
00:16:03будь то извлечение данных из писем,
00:16:05их анализ или принятие решения.
00:16:10Как я уже говорил, вторая часть кажется мне
00:16:13куда более интересной: это когда у вас уже есть
00:16:16базовый слой классификации и разделения,
00:16:20и вы настроили сортировку.
00:16:22Главный повод для вдохновения всей нашей команды —
00:16:26это агентские среды (harnesses), которые стали важнейшим рубежом
00:16:29для решения проблем, ранее считавшихся неразрешимыми.
00:16:34Яркий пример, о котором я расскажу прямо сейчас, —
00:16:37это линейные графики.
00:16:39Мы сотрудничаем с крупнейшими хедж-фондами мира,
00:16:41и обработка линейных графиков всегда была
00:16:43крайне сложной задачей: во-первых, это растровые изображения;
00:16:46во-вторых, детализация идет на уровне пикселей,
00:16:49и традиционный энкодер компьютерного зрения
00:16:52просто упустит эти нюансы.
00:16:53Вы получите лишь примерный тренд выручки,
00:16:55но не конкретные точки данных.
00:16:57Поэтому мы задумались: как предоставить агентам
00:17:00инструменты для решения специфических классов задач,
00:17:04с которыми вы сталкиваетесь?
00:17:05В случае извлечения данных из диаграмм, график слева скрывает
00:17:09гигантский массив табличных данных.
00:17:11Если вручную оцифровывать буквально каждый пиксель,
00:17:14это займет невероятно много сил.
00:17:16Но и самой модели тяжело даже приблизительно оценить
00:17:19все изгибы и линии промежуточных значений.
00:17:22И ни одна готовая модель не способна справиться
00:17:24с этим за один проход.
00:17:25Справа вы видите реконструированную
00:17:28Markdown-таблицу, которую нам удалось сгенерировать
00:17:30на основе исходного линейного графика.
00:17:32И единственный способ, которым мы смогли этого добиться,
00:17:34— это использование агента со множеством инструментов.
00:17:36У него есть собственный интерпретатор кода.
00:17:37У него есть возможность визуализировать создаваемый график.
00:17:40И он итеративно продвигается вперед.
00:17:41Он снова и снова находит ошибки на линейном графике,
00:17:45пока не получает конечный результат.
00:17:47Это относится и к таким задачам, как структурированное извлечение данных,
00:17:51где у нас уже какое-то время есть функция перевода
00:17:53документа в структурированный вид.
00:17:55Но вы действительно можете пойти дальше,
00:17:57развернув агентную обвязку вокруг подобной задачи.
00:18:00Родительский агент может задавать критерии валидации,
00:18:03которым будут следовать субагенты.
00:18:05И это значит, что если у вас есть форма CBP
00:18:09с десятками тысяч полей,
00:18:11то в таких задачах обычно возникает
00:18:13множество незаметных проблем.
00:18:15Например, теряются данные, пропускаются строки.
00:18:17Сегодня утром MicroOne выпустили отличный бенчмарк
00:18:20в этой области, показывающий разделение
00:18:23на рынке.
00:18:24Передовые модели с максимальным логическим мышлением очень точны.
00:18:28То есть, если они извлекли строку,
00:18:30скорее всего, она не галлюцинирована.
00:18:31Они действительно извлекли ее верно.
00:18:33Но при этом они незаметно теряют много данных по всему бенчмарку.
00:18:37Полнота охвата у них сильно страдает.
00:18:39С другой стороны, многие специализированные сервисы обработки документов
00:18:42уступают передовым моделям в точности,
00:18:46но сокращают отставание по полноте охвата.
00:18:48И поэтому всегда существовал подобный компромисс.
00:18:51И только благодаря агентной обвязке нам удалось найти
00:18:54своего рода локальный максимум точности и полноты
00:18:57для задач такого типа.
00:19:00Последнее, и, пожалуй, самое важное из этого доклада,
00:19:04заключается в том, что в конечном счете оценки должны лежать в основе
00:19:09всех ваших решений.
00:19:10И это важнейшая часть нашего подхода к продукту.
00:19:12Это касается как готовых датасетов для тестирования,
00:19:16так и вещей вроде мониторинга в реальном времени в продакшене.
00:19:19Потому что ваши данные в продакшене будут отличаться
00:19:21от всего, что есть в ваших искусственных тестовых наборах.
00:19:25И я правда считаю важным рассматривать оценки
00:19:28не просто как общий взгляд с высоты,
00:19:30ведь лучшие команды, с которыми мы работаем,
00:19:33оценивают каждый шаг своего пайплайна на детальном уровне.
00:19:36Первым делом вам, возможно, захочется убедиться,
00:19:38что входные данные вашего пайплайна отличного качества.
00:19:40И, конечно, стоит оценивать работу пайплайна парсинга.
00:19:43Но даже идеальный парсинг при ужасном пайплайне поиска
00:19:47не поможет, если вы передаете не тот контекст.
00:19:50Поэтому важно продумывать такие детали,
00:19:52как ваш пайплайн поиска,
00:19:54форматирование в конце пайплайна,
00:19:56и, в конечном счете, самое главное:
00:19:58удается ли вам повысить итоговую производительность агента.
00:20:03Завершая, я хочу поделиться видением того, куда мы движемся
00:20:06и куда, по нашим наблюдениям, движется вся отрасль.
00:20:08Самое важное, на мой взгляд: по мере того как агенты становятся лучше,
00:20:12вы можете отходить от детерминированных пайплайнов,
00:20:15которые использовались еще пару лет назад.
00:20:17Многие наши клиенты фактически создают файловую систему,
00:20:20по которой их агент может передвигаться,
00:20:22предоставляя ему право решать, какие инструменты использовать.
00:20:25Поэтому мы создаем CLI, где вместо построения сквозного пайплайна,
00:20:28в котором документы всегда проходят строго фиксированный путь,
00:20:32агент сам решает, нужно ли ему прочитать определенный тип документа,
00:20:35и разделяет данные на два набора.
00:20:38Первый — это текстовое содержимое, которое агент читает по мере необходимости,
00:20:41а второй — все необходимые метаданные.
00:20:44Если вы оформляете цитаты, вам могут понадобиться ограничивающие рамки,
00:20:47ну и так далее.
00:20:50Часть про редактирование я пропущу.
00:20:52Думаю, в этой области сейчас ведется много интересной работы.
00:20:54Кое-что мы уже выпустили, но в ближайшие несколько месяцев
00:20:57вы увидите, что мы все больше внимания уделяем генерации документов.
00:21:01Но подводя итог сегодняшней встречи (и я очень ценю ваше время):
00:21:04Во-первых, я настоятельно рекомендую декомпозировать задачу парсинга.
00:21:08Насколько это возможно, подбирайте правильный инструмент под каждую конкретную задачу,
00:21:11чтобы выйти на передовой рубеж по точности, стоимости и задержке.
00:21:16Во-вторых, агентная верификация — это крупнейший сдвиг в отрасли за долгое время,
00:21:21и отличная возможность убедиться, что ваши пайплайны надежно работают в продакшене.
00:21:26В-третьих, проработка деталей требует минимум усилий, но дает огромный прирост —
00:21:31например, форматирование данных под конечного потребителя.
00:21:34Аналогично, чрезвычайно важно думать не только об обработке данных,
00:21:39но и об их оркестрации.
00:21:41Поэтому всегда рассматривайте такие инструменты, как классификация и разделение,
00:21:44в качестве способа усиления вашего пайплайна.
00:21:46В-пятых, обязательно проводите оценку качества на каждом этапе.
00:21:49И в-шестых, продумайте, как для вас выглядит следующий технологический рубеж,
00:21:52поскольку большинство успешных компаний сегодня сильно отошли
00:21:56от методов двух-трехлетней давности.
00:21:59Если у вас есть вопросы, пожалуйста, связывайтесь со мной в любое время.
00:22:03Моя почта: имя@reducto.ai.
00:22:06Вы также можете написать через наш сайт, если мы можем помочь с вашим сценарием.
00:22:10Спасибо.

Description

The newest frontier model scores about thirty percent on a data lab's benchmark of decisions from PDFs, and Adit Abraham has met people who worked on PDF processing before he was born. The format was built to print, not to be reasoned over, and humans encode meaning visually: merged cells, line charts, unreadable handwriting. Reducto has processed billions of them, and the talk is the lessons, not the product. RAG meant a bad parse cost one answer; with agents, bad inputs compound across every step. VLMs finally read the long tail like a human, but they are not one size fits all: small detectors still find layout on a CPU at scale, and a VLM asked to rewrite OCR will helpfully recompute a total the human got wrong. His agentic OCR applies token level corrections, a zero for an O, instead of regenerating the page. Simple tables go to markdown and complex ones to HTML, but embedding models cannot match how did revenue change to a blob of tags, so a natural language rendering serves retrieval. Parsed structure rather than raw PDFs lifted other frontier models past the newest one on that benchmark and cut reasoning tokens. Classification and splitting keep a hundred page mail packet from distracting it. Agent harnesses crack problems no model solves in one shot, turning a line chart into a data table with a code interpreter and repeated self checks, and they beat a trade off a new benchmark exposed, where frontier models are precise but silently drop rows and document services do the reverse. He closes on evals at every stage and customers who give agents a file system, not a fixed pipeline. Speaker info: - https://reducto.ai Timestamps: 0:00 - Reducto, and the less sexy part of agents that work: data 2:04 - From RAG to agents: bad inputs compound across steps 5:28 - Why PDFs are still hard, and a benchmark frontier models fail 7:19 - Traditional CV versus VLMs: the right place for each 9:07 - Agentic OCR: token level correction, not rewrites 10:42 - Tables: markdown versus HTML, and a form for the embedding model 13:15 - Better inputs lift frontier models and cut reasoning tokens 14:41 - Classification and splitting as orchestration 16:17 - Agent harnesses: line charts to tables, precision and recall together 18:57 - Evals at every stage 20:06 - Where this heads: a file system and CLI for agents 21:00 - Six takeaways

Community Posts

No posts yet. Be the first to write about this video!

Write about this video