Извлечение данных из текста LLM я в последний год подключаю к проектам чаще, чем классический парсинг регулярками. Присылают произвольное сообщение из чат-бота, письмо от поставщика, скан чека или комментарий из формы на Тильде, а на выходе нужен предсказуемый JSON: имя, телефон, сумма, дата, статус заказа. Ниже разбираю, как выстраиваю структурированный вывод у нейросети на практике: какие механизмы использую, где модель начинает выдумывать поля и как проверяю результат перед тем, как он попадёт в CRM или таблицу.
Зачем извлекать данные из текста нейросетью, если есть regex и парсеры
Regex отлично работает, пока формат текста стабилен: номер телефона всегда в одном месте письма, сумма всегда после слова «Итого». На практике так бывает редко. Клиенты пишут «плачу через т банк, чек скину завтра», «адрес - дом 12 корпус 3, подъезд со двора», «нужно к пятнице, а лучше к четвергу». Регулярка ловит один шаблон и ломается на втором сообщении с другой формулировкой.
LLM не ищет паттерн по позиции в строке, а разбирает смысл фразы. Из текста «оплатил вчера вечером, около трёх тысяч» модель вытащит сумму 3000 и относительную дату, которую я потом перевожу в конкретное число на своей стороне. Для писем поставщиков, отзывов клиентов, обращений в поддержку и голосовых сообщений, расшифрованных в текст, такой подход дешевле по времени разработки, чем дерево условий под каждую формулировку.
Есть и обратная сторона: модель может «дофантазировать» поле, если его нет в тексте, или перепутать формат даты. Про борьбу с этим - в разделе про валидацию ниже.
Структурированный вывод: JSON Schema, function calling и structured outputs
До массового появления structured outputs извлечение данных сводилось к промпту вида «верни JSON с полями…» и надежде, что модель не добавит пояснение перед скобкой. Сейчас у основных провайдеров есть рабочие механизмы:
- function calling / tool use - модели передаётся описание «инструмента» с JSON Schema, она обязана вызвать его с валидными аргументами;
- structured outputs с response schema - модель напрямую возвращает JSON по заданной схеме, без обёртки в текст и без markdown-разметки вокруг;
- constrained decoding на стороне локальных моделей (llama.cpp, vLLM с grammar) - схема применяется на уровне генерации токенов, а не проверяется постфактум.
Я почти всегда беру function calling или structured outputs через Claude API или OpenAI API - они дают предсказуемый JSON без дополнительного парсинга текста. Схему описываю строго: обязательные поля, типы, enum для статусов, ограничение длины строк. Чем жёстче схема, тем меньше у модели пространства придумать своё поле.
Пример схемы для извлечения данных из обращения клиента в поддержку:
{
"type": "object",
"properties": {
"name": {"type": "string"},
"phone": {"type": "string"},
"issue_type": {"type": "string", "enum": ["доставка", "оплата", "брак", "другое"]},
"order_number": {"type": ["string", "null"]},
"urgency": {"type": "string", "enum": ["низкая", "средняя", "высокая"]}
},
"required": ["name", "issue_type", "urgency"]
}Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как я выстраиваю промпт для извлечения сущностей из текста
Схема задаёт форму ответа, но не гарантирует, что модель верно интерпретирует содержание. На это влияет промпт:
- Указываю роль и контекст: «Ты обрабатываешь обращения из формы обратной связи интернет-магазина одежды».
- Явно пишу, что делать с отсутствующими данными: «Если поле не упомянуто в тексте, верни null, не придумывай значение».
- Даю 2-3 примера входного текста и ожидаемого JSON - это снижает разброс формата дат и телефонов сильнее, чем любые инструкции в свободной форме.
- Прошу не добавлять комментарии и markdown вокруг JSON, даже если используется обычный текстовый режим без structured outputs.
Для писем с уведомлениями об оплате, например при сверке платежей T‑Bank с заказами в WooCommerce, в промпт добавляю список типовых формулировок банка: «Перевод по QR», «Оплата картой», «Возврат». Модель точнее распознаёт тип операции, если видит примеры терминологии, а не гадает по общему смыслу фразы.
Валидация, ретраи и защита от галлюцинаций модели
Даже со schema модель иногда возвращает телефон без кода страны, дату в прошлом году вместо текущего или добавляет email, которого не было в исходном тексте. Три вещи, которые ставлю в продакшене обязательно:
- Валидация на своей стороне через Pydantic (Python) или Zod (Node) поверх ответа модели - схема API гарантирует структуру JSON, но не бизнес-корректность значений.
- Повторный запрос при ошибке валидации с указанием, что именно не так: «поле phone не соответствует формату +7XXXXXXXXXX, повтори». Обычно хватает одного ретрая.
- Отдельное поле confidence или явное «не найдено» вместо пустой строки - так проще отфильтровать записи, которые нужно проверить человеку, а не пускать сразу в автоматическую обработку.
Для задач с финансовой значимостью - суммы в чеках, номера заказов, адреса для расчёта доставки через СДЭК - на первые недели работы всегда добавляю слой ручной проверки. Смотрю, на каких формулировках модель ошибается, и дорабатываю промпт и примеры под конкретный поток сообщений.
Где это применяется на практике: боты, автоматизация, интеграции
Разбор обращений в Telegram-боте
В aiogram-боте для поддержки интернет-магазина ставлю LLM между хендлером сообщения и записью в базу: клиент пишет свободным текстом, бот извлекает номер заказа, тип проблемы и телефон, дальше по этим полям автоматически заводит тикет.
Обработка форм с Тильды
Форма на Тильде часто собирает данные в одно текстовое поле «Комментарий», где человек пишет и адрес, и пожелания по доставке, и удобное время звонка. Вебхук с Тильды прилетает в n8n, там нода с вызовом LLM раскладывает текст на структурированные поля перед отправкой в CRM или в расчёт зоны доставки СДЭК.
Сверка платежей
Для интеграций с эквайрингом извлекаю из уведомлений о платеже (T‑Bank, ЮKassa) сумму, номер заказа и статус, сверяю с заказом в WooCommerce и меняю статус на «Оплачен» без ручной сверки бухгалтером.
Разбор писем поставщиков
Прайс-листы и накладные от поставщиков присылают в почти произвольном текстовом или табличном виде - LLM вытаскивает артикул, количество и цену в единый формат для загрузки в 1С или админку магазина.
Похожие интеграции я собираю на связке n8n и Claude API или через отдельный сервис, если нагрузка выше, чем воркфлоу-инструмент способен обработать без задержек. Если задача похожая - разбор обращений, писем или форм в структурированные данные, можно посмотреть на готовый ИИ-чатбот на Claude в библиотеке скриптов как отправную точку архитектуры, а под конкретный формат данных и объём обращений собираю решение индивидуально.
LLM-экстракция против regex и классического NER
| Критерий | Regex | Классический NER | LLM-экстракция |
|---|---|---|---|
| Гибкость к формулировкам | низкая, один шаблон на формат | средняя, зависит от обучающих данных | высокая, понимает смысл фразы |
| Время на настройку под новый формат | часы на каждый новый шаблон | недели на разметку и дообучение | минуты на правку промпта и схемы |
| Нужен ли датасет для обучения | нет | да, размеченный вручную | нет, только примеры в промпте |
| Стоимость одного запроса | почти ноль | низкая после обучения | несколько копеек за запрос через API |
| Устойчивость к опечаткам и жаргону | низкая | средняя | высокая |
Сроки и стоимость разработки
Простой модуль извлечения полей из одного типа сообщений, например разбор комментария к заказу в форме на Тильде на адрес и телефон, оцениваю как кастомный скрипт для Tilda - от 3 000 ₽, если это доработка существующего сайта без внешних интеграций.
Если нужна связка с CRM, эквайрингом или СДЭК - это уже комплексная интеграция, от 40 000 ₽.
Отдельный сервис на n8n с обработкой входящих писем или сообщений через LLM - автоматизация в n8n, от 25 000 ₽.
Полноценная AI-интеграция с Claude API или OpenAI, включая валидацию схемы, ретраи и обработку ошибок под нагрузкой, - от 50 000 ₽, срок обычно 2-3 недели в зависимости от количества типов документов и полей.
На фрилансе и в студиях цены на подобные интеграции у других разработчиков я видел в диапазоне 30 000-150 000 ₽ - разброс большой из-за того, что многие закладывают доработку промпта отдельными итерациями поверх стоимости кода.
Искусственный интеллект для бизнеса
AI / Claude API
от 50 000 ₽
Подробнее →Частые вопросы
Чем структурированный вывод отличается от обычного ответа нейросети?
Обычный ответ - это свободный текст, который приходится парсить самому и обрабатывать все варианты формулировок вручную. Структурированный вывод задаёт схему заранее через JSON Schema или function calling, модель обязана вернуть данные в этом формате, и на выходе получается объект, который сразу проходит валидацию и уходит в базу без промежуточного разбора текста.
Можно ли доверять LLM извлечение данных из юридически значимых документов?
Напрямую в базу без проверки - нет. Модель иногда добавляет значения, которых не было в тексте, или неверно распознаёт формат чисел и дат. Для чеков, счетов и договоров я всегда добавляю валидацию по схеме, сверку суммы через отдельный числовой парсер и ручную проверку выборки результатов на старте, прежде чем полностью автоматизировать процесс.
Какая модель лучше подходит для извлечения сущностей из текста?
Для большинства задач хватает моделей среднего размера вроде Claude Haiku - извлечение полей не требует сложных рассуждений, а стоимость запроса при этом в разы ниже, чем у топовых моделей. Более крупную модель беру, когда текст многослойный, например письмо с несколькими заказами внутри одного сообщения, и нужно правильно развести сущности между собой.
Сколько стоит внедрить извлечение данных из текста в существующий проект?
Зависит от того, куда встраивается модуль. Доработка формы на Тильде под структурированный вывод - от 3 000 ₽, автоматизация обработки писем или сообщений через n8n - от 25 000 ₽, полноценная AI-интеграция с валидацией и обработкой ошибок под нагрузку - от 50 000 ₽.