PDF, текст или Markdown: как я проверю три формата на одной задаче

Один документ, одна модель, одинаковые задания и три представления: PDF, обычный текст и Markdown. Цель - не рейтинг форматов, а карта их реальных границ.

За последние несколько дней у меня получилась цепочка из 3х вопросов.
Сначала я заметил, что PDF быстро расходует контекст Claude.
Потом разобрался, почему из одного PDF текст извлекается нормально, а другой оказывается сканом или ломается на таблицах и колонках.

После этого возник следующий вопрос:

Что лучше передавать нейросети - исходный PDF, обычный текст или Markdown?

В предыдущей статье я попробовал разложить этот выбор теоретически. Получилась простая модель.
PDF нужен, когда документ нужно видеть.
Обычный текст - когда документ достаточно читать.
Markdown - когда документ нужно читать вместе со структурой.

Но пока это только рабочая модель. Теперь я хочу проверить её на одинаковых документах и одинаковых заданиях.

Что именно я хочу проверить

Меня не интересует, какой формат выглядит технологичнее или удобнее человеку. Мне нужен ответ на более прикладной вопрос:

В каком представлении одна и та же нейросеть лучше выполняет одну и ту же работу с документом?

Для этого я хочу взять один исходный PDF и подготовить из него три варианта.

1. Исходный PDF

В первом прогоне модель получает сам файл. Для Claude это означает не только работу с текстом. Anthropic описывает обработку PDF так: текст каждой страницы извлекается, сама страница преобразуется в изображение, после чего модель анализирует оба представления.

Это позволяет учитывать графики, диаграммы, изображения, таблицы и расположение элементов на странице. За это приходится платить контекстом. По документации Anthropic текстовая часть страницы обычно занимает примерно 1500 - 3000 токенов в зависимости от плотности содержимого. Изображение страницы учитывается дополнительно.

2. Обычный текст

Во втором варианте я хочу передавать только извлечённый текст.
Без изображений страниц.
Без специальной попытки сохранить визуальное оформление.
Это минимальное представление для задач, где модели нужно в первую очередь прочитать содержание документа.

3. Markdown

Третий вариант - преобразовать тот же исходник.
Получается один источник и три представления одной информации:

PDF
обычный текст
Markdown

Меняется только то, что получает модель.

Один простой PDF для такого теста не подходит

Если взять десять страниц обычного договора без таблиц и изображений, обычный текст вполне может показать отличный результат. Из этого нельзя будет сделать вывод о PDF вообще.
Поэтому мне нужны документы, на которых форматы сталкиваются с разными типами информации.

Простой линейный документ

Например, договор или статья, где почти всё содержимое находится в последовательном тексте.

Здесь моя гипотеза такая:

визуальный слой даст мало дополнительной пользы.

Но это нужно проверить.

Документ с выраженной структурой

Заголовки, подразделы, списки, вложенные пункты.
Здесь можно проверить, помогает ли Markdown модели понимать отношения между частями документа лучше, чем обычный текст.

Документ с таблицами

Для меня это один из наиболее интересных случаев. Человек легко видит:

После простого извлечения все значения могут сохраниться, но связи между строками и столбцами исчезнуть.
Тогда нужно проверить, помогает ли Markdown сохранить эти отношения и правильно ли они вообще восстанавливаются при преобразовании.

Документ с графиком или диаграммой

Это контрольный случай для визуального слоя.
Если нужная цифра существует только на графике, обычный текст потенциально потеряет её ещё до обращения к модели.
Здесь у исходного PDF должно быть естественное преимущество.
Если его не окажется, придётся разбираться почему.

Сложная страница

Колонки, таблица рядом с текстом, подписи, изображения и несколько блоков на одной странице.
Такой документ нужен, чтобы проверить уже не наличие слов, а сохранение отношений между ними.

В эксперименте должен меняться только формат

Если PDF получит один запрос, обычный текст другой, а Markdown третий, сравнение ничего не покажет.
Поэтому для каждого документа я хочу зафиксировать:

• одну модель;
• один первый запрос;
• одинаковые вопросы;
• одинаковые настройки генерации, если ими можно управлять;
• одинаковые критерии проверки;
• одинаковое число попыток.

Единственная переменная:

представление документа.

Это позволит связать разницу в результате именно с входным материалом, а не с разницей в запросах.

Одного задания тоже недостаточно

Можно попросить:

Сделай краткое содержание документа.

Но такая задача в основном проверяет понимание общего текста.
Она почти ничего не говорит о таблицах, структуре и визуальной информации.
Поэтому я хочу использовать несколько типов работы.

1. Понять общий смысл

Например:

Сформулируй пять главных выводов документа.

На простом текстовом документе я ожидаю небольшую разницу между тремя вариантами.
Если она окажется большой, это уже будет интересным результатом.

2. Найти точный факт

Например:

Какой срок оплаты указан в документе?

Или:

Какая сумма относится к позиции X?

Здесь я проверяю, не потерялось ли конкретное значение при преобразовании.

3. Понять принадлежность текста к разделу

Например:

Какие обязательства относятся к разделу об ответственности?

Найти слова недостаточно.
Модель должна правильно понять структуру документа и связь между элементами.
Именно здесь Markdown потенциально может дать преимущество перед плоским текстом.

4. Прочитать таблицу

Например:

В какой строке план сильнее всего отличается от факта?

Если все цифры сохранились, но связь между строками и столбцами разрушилась, обычный текст может проиграть несмотря на формально полное извлечение содержимого.

5. Понять график

Например:

Какой показатель сильнее всего вырос на диаграмме?

Если информация существует только визуально, в обычном тексте её быть не должно.
Это позволяет проверить реальную ценность визуального слоя PDF.

6. Найти противоречие

Например, в основном тексте договора указано одно условие, а в приложении - другое.
Здесь одновременно нужны полнота документа, понимание структуры и способность сопоставить удалённые друг от друга части.

Сначала нужен эталон, потом нейросеть

Это для меня принципиальная часть эксперимента.
Если я просто спрошу модель:

Какая ответственность предусмотрена договором?

она может дать очень убедительный ответ.

Но убедительность не означает правильность. Поэтому до запуска каждого теста я хочу вручную зафиксировать правильные ответы.

Для каждого документа:

• какие факты должны быть найдены;
• какие элементы связаны между собой;
• какие данные существуют только визуально;
• как устроены проверяемые таблицы;
• какой результат считается правильным;
• какие ошибки считаются критическими.

И только после этого запускать модель.

Иначе я буду сравнивать впечатление от ответов, а не их качество.

Как я хочу оценивать результат

Одной оценки вроде «ответ хороший» здесь тоже недостаточно.
Я хочу отдельно фиксировать минимум четыре показателя.

Правильность

Совпадает ли ответ с заранее подготовленным эталоном.

Полнота

Получена ли вся необходимая информация.

Ложные утверждения

Добавила ли модель сведения, которых нет в исходном документе.

Необходимость ручной проверки

Можно ли использовать результат сразу или человеку приходится снова открывать исходный PDF и проверять работу модели.
Для автоматизации последний показатель особенно важен.
Формат может выглядеть эффективным по токенам, но проигрывать, если после каждого результата сотрудник вынужден вручную восстанавливать контекст.

Отдельно хочу посчитать контекст и стоимость

Вся эта цепочка исследований началась именно с расхода токенов.
Поэтому качество ответа я хочу сопоставлять с ценой его получения.

Для каждого варианта имеет смысл фиксировать:

• размер исходного файла;
• объём обычного текста;
• объём Markdown;
• количество входных токенов, если платформа позволяет его получить;
• стоимость обработки;
• время выполнения.

Меня интересует не минимальное число токенов само по себе. Интереснее другое:

Сколько контекста требуется, чтобы получить правильный результат нужного качества?

Победителя заранее нет

Я вижу несколько возможных результатов.

PDF окажется лучше

Тогда визуальная информация даёт достаточно пользы, чтобы оправдать дополнительный контекст хотя бы для части документов.

Обычного текста будет достаточно

Тогда для большого класса линейных документов можно не передавать модели визуальный слой.

Markdown выиграет на структурированных документах

Тогда появится практическая граница между обычным текстом и представлением, где сохраняются заголовки, списки и таблицы.

Универсального победителя не будет

Сейчас эта гипотеза кажется мне наиболее правдоподобной. Но пока она ничем не подтверждена.

Эксперимент как раз и нужен, чтобы перестать выбирать формат по ощущению.

Если универсального формата нет, задача становится интереснее

Тогда вопрос:

Во что конвертировать каждый PDF?

поставлен неправильно.

Нужен другой:

Какое представление требуется для этой конкретной работы?

Например:

• обычный договор -> текст;
• регламент с разделами -> Markdown;
• отчёт с диаграммами -> PDF;
• скан -> распознавание текста;
• сложная таблица -> отдельное структурное извлечение.

Это уже похоже не на универсальный конвертер, а на систему подготовки документов к следующей работе.

Для одного документа всё это может быть избыточно

Если я раз в месяц задаю Claude один вопрос по небольшому договору, проще загрузить PDF и не строить вокруг этого отдельную архитектуру.
Экономический смысл появляется с повторяемостью.
100 документов в месяц.
1000.
Один и тот же тип работы.

Тогда стоимость контекста, ошибки преобразования и ручная проверка повторяются вместе с каждым документом.
И выбор представления становится частью стоимости всей функции.

От PDF в текст я постепенно пришёл к другой задаче

В начале я искал решение довольно узкой проблемы:

Получить текст из PDF.

Потом выяснилось, что даже здесь есть несколько разных операций:

• извлечь существующий текст;
• распознать скан;
• восстановить структуру.

Теперь появился следующий слой:

В каком виде передать полученную информацию дальше?

А если документов много, за этим следуют уже другие действия.
Получить документ.
Определить его тип.
Извлечь данные.
Сохранить нужную структуру.
Передать модели.
Проверить результат.
Записать его в следующую систему.

Поэтому эксперимент PDF / текст / Markdown для меня уже не просто спор о формате. Это проверка одного этапа потенциальной автоматизации обработки документов.

Какой результат эксперимента мне нужен

Я не хочу закончить таблицей:

PDF - 8 баллов.
Markdown - 9 баллов.
Текст - 7 баллов.

Такой рейтинг мало что даст.
Мне нужна карта границ.
Для каких документов обычного текста достаточно?
Где Markdown действительно помогает сохранить структуру?
Где он ничего не добавляет?
Какая информация исчезает без исходного PDF?
Как меняется расход контекста?
В каких случаях человеку всё равно приходится открывать оригинал?

После этого можно будет отдельно принять два решения.
Первое - какие функции нужны простому инструменту для работы с документами.
Второе - какие повторяющиеся цепочки уже имеет смысл исследовать как бизнес-функцию для автоматизации.
Пока у меня есть только гипотезы.

Следующий шаг - взять реальные документы и проверить их на одинаковой работе.