CSV → Markdown/JSON: как научить LLM различать заголовки и значения в таблицах

Применяется в одном промпте:

ШАГ 1: Преобразуй CSV в [Markdown/JSON]
 → Таблица где заголовки синтаксически выделены
 
ШАГ 2: Выполни задачу (проверка, анализ, сравнение)
 → Результат проверки на основе правильно понятой структуры

Выбор формата:

• Много текста (описания, параграфы) → Markdown
• Много символов (ID, коды, технические обозначения) → JSON

Задача: У тебя два прайс-листа для Wildberries — старая и новая версии. Нужно найти несоответствия: где цена изменилась, где артикул переименован, где условия доставки не сходятся. Таблицы в Excel, экспортированы в CSV.

Промпт:

Вот два прайс-листа в CSV формате. 

ПРАЙС 1 (старая версия):
[CSV данные прайса 1]

ПРАЙС 2 (новая версия):
[CSV данные прайса 2]

ШАГ 1: Преобразуй оба CSV в Markdown формат, чтобы заголовки таблиц были чётко выделены.

ШАГ 2: Сравни два прайс-листа и найди все несоответствия:
- Изменения цен
- Разные артикулы для одного товара
- Различия в условиях доставки
- Любые другие расхождения

Выведи результат в формате:
- **Тип несоответствия:**
- **Где находится:** (номер строки, название товара)
- **Что изменилось:** (было → стало)
- **Рекомендация:** (нужно ли исправить)

Результат:

Модель сначала покажет Markdown-версию обеих таблиц (с # для заголовков и чёткой структурой), затем выдаст список несоответствий с указанием конкретных мест и изменений. Например: "В строке 15 цена изменилась с 1200₽ на 1250₽", "Артикул WB-12345 переименован в WB-12346 для товара 'Футболка хлопок'".

Слабость LLM: CSV данные не содержат явной информации о заголовках. Когда модель обучалась, она видела CSV как последовательность строк через запятую. Она не училась различать "это заголовок" и "это значение". Поэтому при анализе сложных таблиц модель может перепутать заголовок с данными или не заметить важные элементы структуры.

Сильная сторона LLM: Модель отлично понимает Markdown и JSON, потому что в этих форматах заголовки синтаксически выделены. В Markdown это #, |, **, в JSON это "key": "value". Во время обучения модель видела связь между заголовком и данными в этих форматах, поэтому может правильно их интерпретировать.

Как метод использует сильную сторону: Вместо прямой подачи CSV, мы сначала конвертируем данные в формат, где структура явная. Это работает как Chain-of-Thought для данных — модель сначала разбирает структуру (конверсия), потом работает с задачей. Двухшаговый процесс помогает модели не потерять контекст о том, что есть что.

Рычаги управления:

• Формат конвертации (Markdown vs JSON) → меняй в зависимости от типа данных: текстовые описания лучше в Markdown, технические ID и коды — в JSON
• Детализация инструкций → добавь "выдели каждый заголовок как отдельную строку" для особо сложных таблиц
• Промежуточный вывод → попроси "покажи сначала Markdown версию" чтобы видеть как модель поняла структуру

У меня есть {описание_таблицы} в CSV формате.

CSV ДАННЫЕ:
{csv_данные}

ШАГ 1: Преобразуй CSV в {Markdown/JSON} формат, где заголовки таблицы чётко выделены от значений.

ШАГ 2: {твоя_задача}

Выведи результат в формате:
{желаемый_формат_вывода}

Что подставлять:

• {описание_таблицы} — что за таблица: "прайс-лист товаров", "отчёт по продажам", "список задач"
• {csv_данные} — сами данные таблицы
• {Markdown/JSON} — выбери Markdown если таблица с текстом, JSON если много ID/кодов/символов
• {твоя_задача} — что сделать: "найди несоответствия", "проверь на ошибки", "суммируй по категориям"
• {желаемый_формат_вывода} — как хочешь получить результат

🚀 Быстрый старт — вставь в чат:

Вот шаблон для работы с таблицами. Адаптируй под мою задачу: {твоя задача}. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит что за таблица у тебя и какая задача — потому что ей нужно понять тип данных (Markdown или JSON) и сформулировать конкретные инструкции для проверки. Она возьмёт паттерн двухшагового процесса из шаблона и адаптирует под твою таблицу.

⚠️ Длинные документы: После 5000 символов точность падает. Модель либо теряет информацию при конвертации, либо пропускает несоответствия. Для больших таблиц лучше разбить на части или использовать специализированные решения.

⚠️ Сложная структура: Если в CSV вложенные таблицы, объединённые ячейки или нестандартная логика заголовков — конвертация может исказить данные. Проверяй Markdown/JSON версию перед основной задачей.

⚠️ GPT-3.5 требует более чёткие инструкции: В экспериментах GPT-3.5 turbo чаще делал неполную конвертацию или отвечал общими фразами вместо конкретного анализа. GPT-4 и GPT-4o работают стабильнее.

Команда из Fujitsu взяла реальные дизайн-документы из банковских систем, написанные в Excel (типичная практика в Японии — 41 из 47 документов в формате Excel). Исследователи сначала определили 11 перспектив ревью — от проверки соответствия стандартам до проверки согласованности между документами. Потом отсеяли перспективы, которые требуют глубокой экспертизы (feasibility, compliance) — они для специализированных LLM. Остались перспективы уровня 1-2, которые доступны обычным LLM без fine-tuning.

Для тестов выбрали consistency check (проверка согласованности) — самую чувствительную к пониманию структуры таблиц. В документы намеренно внесли ошибки: изменили ID процессов ("execute" → "execution"), перепутали типы переменных, несоответствия в номерах и метках. Проверяли bidirectional consistency — когда одно и то же должно совпадать в обоих документах.

Сравнивали три подхода: (1) сырой CSV без изменений, (2) CSV → Markdown, (3) CSV → JSON. Тестировали на GPT-3.5 turbo, GPT-4, GPT-4o. Для каждой пары документов — 10 прогонов, всего 50 экспериментов на паттерн.

Результаты удивили конкретностью: Markdown-конвертация улучшила recall на 0.43-0.63 по сравнению с сырым CSV. Precision оставался стабильным (~0.93-0.99), но модель стала находить в разы больше ошибок. Почему? Потому что в Markdown заголовки явно выделены (#, |), и модель понимала КАК элементы связаны друг с другом. В CSV всё смешивалось в кучу.

Ещё неожиданный инсайт: для символьных данных (ID, коды) JSON работал лучше Markdown. Когда в таблице много технических обозначений, Markdown часто упрощал структуру до простых | pipe-разделителей и терял контекст. JSON сохранял вложенность и связи. А для текстовых описаний наоборот — Markdown побеждал, потому что JSON создавал излишне вложенные структуры, где терялись заголовки.

Логика исследования: Идея простая — LLM обучалась на данных где в Markdown/JSON заголовки явно отличимы от значений. Значит, если преобразовать CSV в эти форматы, модель автоматически поймёт структуру. Это подтвердилось: improvement не в промптах, а в форме подачи данных.

Проверили масштабируемость: до 5000 символов метод работает отлично (recall 0.83-0.94 на GPT-4/4o). После 5000 символов — резкий обрыв (recall падает до 0.14-0.48). Это критично, потому что в реальных проектах 70% документов длиннее 5000 символов. Но 30% документов метод покрывает уже сейчас — и это практичный результат для внедрения.

Контекст: Исследователи использовали этот промпт для проверки согласованности между двумя дизайн-документами. Промпт простой, но эффективность зависит от предварительной конвертации CSV в Markdown/JSON.

[Request] Based on the two input design documents, please conduct a review from the perspective of consistency.

[Output Format]
- Perspective:
- Presence of Inconsistencies: (Yes or No)
- Inconsistent Locations:
- Suggested Corrections:
- Justification:

[Supplementary Notes]
- If no inconsistencies are found, state "Presence of Inconsistencies: No".
- There may be multiple points of inconsistency.

💡 Адаптация для финансовых отчётов:

Принцип тот же — конвертация CSV в понятный формат перед анализом. Подходит для сверки бюджетов, проверки расхождений в балансах, сравнения версий договоров.

У меня два бюджетных отчёта — план и факт — в CSV.

ПЛАН:
{csv_план}

ФАКТ:
{csv_факт}

ШАГ 1: Преобразуй оба CSV в Markdown, выдели заголовки статей расходов.

ШАГ 2: Найди расхождения:
- Где факт превысил план более чем на 10%
- Где статья есть в плане, но отсутствует в факте
- Где категория расходов изменилась

Для каждого расхождения укажи:
- Статья расходов
- План vs Факт (суммы)
- Процент отклонения
- Возможная причина

🔧 Техника: Промежуточная проверка конвертации → видимость процесса

Если хочешь убедиться что модель правильно поняла таблицу, добавь инструкцию показать результат конвертации:

ШАГ 1: Преобразуй CSV в Markdown и ПОКАЖИ результат конвертации.

ШАГ 2: Только после этого выполни проверку.

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

💡 Адаптация для контент-менеджмента:

Проверка согласованности между версиями контента — например, описания товаров на сайте vs маркетплейсе, меню ресторана на сайте vs в приложении.

Вот два описания товара — с сайта и с Wildberries.

САЙТ:
{описание_сайт}

WILDBERRIES:
{описание_wb}

ШАГ 1: Преобразуй оба описания в структурированный Markdown:
- Название товара
- Характеристики (размеры, материал, цвет)
- Цена
- Условия доставки

ШАГ 2: Найди несоответствия в:
- Названии товара
- Характеристиках
- Цене
- Условиях доставки

Для каждого несоответствия укажи что нужно исправить и где.

Development of Automated Software Design Document Review Methods Using Large Language Models — Takasaburo Fukuda, Takao Nakagawa, Keisuke Miyazaki, Susumu Tokumoto (Fujitsu Ltd., Япония)

Исследование основано на SDEM (Standard for Software Development and Management) — внутреннем стандарте Fujitsu, совместимом с ISO/IEC 12207.

Упоминания стандартов: IEEE 1028-2008 (Software Reviews), ISO/IEC 20246:2017 (Work Product Reviews)