Запустить LLM поверх корпуса ГОСТов или патентов технически несложно. Получить точные, верифицируемые ответы — принципиально другая задача. Главный bottleneck — не модель, а инженерия входных данных: качество OCR, структура чанков, метаданные версионности и разметка статуса документа. Без этого система будет уверенно выдавать пункты из отменённых редакций и несуществующие номера патентов. Этот playbook — о том, что нужно сделать до запуска, где ИИ реально ускоряет работу, а где без эксперта нельзя. Три зоны применения: матрица задач и рисков Прежде чем говорить об инженерии данных, нужно зафиксировать, какую задачу вы решаете. Это определяет и требования к данным, и допустимый уровень риска. Зона | ГОСТ | Патент (ФИПС/ЕАПАТИС) | Техническая спецификация Поиск / навигация | ✅ Низкий риск. Нужны: OCR ≥ 95%, метаданные статуса, чанкинг по пунктам | ✅ Средний риск. Нужны: семантический индекс, доступ к актуальной базе, разметка по разделам патента | ✅ Низкий риск. Нужны: структурированный формат, метаданные версии Синтез / сравнение | ⚠️ Средний риск. Сравнение редакций, выявление изменений — только с верификацией | ⚠️ Средний риск. Сравнение формул изобретений — требует эксперта на выходе | ⚠️ Средний риск. Сравнение ТУ разных поставщиков — допустимо как черновик Генерация / черновик | 🔴 Высокий риск. Черновик раздела для нормоконтролёра — только как заготовка, не как финальный документ | 🔴 Высокий риск. Черновик патентной заявки — только с патентным поверенным | 🔴 Средний риск. Черновик ТУ — допустимо при наличии экспертной проверки Ключевой вывод из матрицы: зона поиска и навигации — наиболее зрелая и безопасная для внедрения. Именно здесь RAG даёт измеримый результат: сокращение времени поиска с 15–30 минут до секунд при recall@5 выше 85% на хорошо подготовленном корпусе. Зоны синтеза и генерации требуют human-in-the-loop как обязательного архитектурного элемента, а не опции. Почему данные — это 70% проекта Типичная ошибка при запуске ИИ на нормативных документах: взять PDF из Кодекса или Техэксперта, загрузить в векторный индекс и ожидать работающей системы. Результат предсказуем — система отвечает уверенно, но неверно. Проблема 1: OCR как узкое место. Большинство ГОСТов существуют в виде сканированных PDF. Стандартный OCR-pipeline (Tesseract, ABBYY без тонкой настройки) даёт приемлемое качество на сплошном тексте, но разваливается на таблицах, формулах и многоколоночных схемах. По данным исследований 2026 года, доля страниц с корректно распознанными таблицами при стандартном pipeline — менее 60%. Для ГОСТ это критично: именно в таблицах содержатся допуски, классы точности, коды обозначений. Современный подход — использование VLM (vision-language models) для сложных страниц вместо классического OCR. Это увеличивает стоимость обработки, но поднимает качество распознавания таблиц до 85–90%. Проблема 2: версионность и статус. ГОСТ — живой документ. Стандарт может быть действующим, отменённым, заменённым новой редакцией или изменённым через поправки. Если при индексации не добавить метаданные статуса (действующий / отменён / заменён / дата актуализации), система будет выдавать ответы из отменённых редакций — и пользователь не узнает об этом. Проблема 3: чанкинг по структуре, а не по размеру. Стандартный чанкинг по количеству токенов разрывает логические единицы ГОСТ — пункты, подпункты, таблицы. Правильный подход: чанкинг по структуре документа (раздел → пункт → подпункт → таблица как отдельный чанк с родительским контекстом). Это требует парсинга структуры документа, а не просто нарезки текста. Проблема 4: смешанный индекс без разметки источника. Если в одном индексе лежат ГОСТы, патенты и внутренние ТУ без разметки типа документа, precision падает: система может ответить на вопрос о требованиях ГОСТ цитатой из внутреннего регламента. Разные типы документов — разные индексы или обязательная разметка с фильтрацией на уровне запроса. Чеклист готовности данных перед запуском RAG Пройдите по этому списку до начала индексации. Если хотя бы три пункта не выполнены — система не даст приемлемого качества. OCR и качество текста • OCR quality score ≥ 95% для сплошного текста, ≥ 85% для таблиц (проверяется на выборке из 50–100 страниц) • Формулы и схемы либо распознаны корректно, либо помечены как «требует ручной проверки» и исключены из индекса • Артефакты сканирования (переносы, колонтитулы, номера страниц) удалены из текстового слоя Метаданные и версионность • Каждый документ имеет поля: статус (действующий / отменён / заменён), дата введения, дата последнего изменения, номер заменяющего документа • Staleness rate в корпусе проверен: доля документов с истёкшим статусом не превышает 5% • Источник актуализации зафиксирован (реестр Росстандарта, ФИПС, внутренний регламент) Структура и чанкинг • Чанки соответствуют логическим единицам документа (пункт, подпункт, таблица), а не произвольным размерам • Каждый чанк содержит родительский контекст: номер раздела, пункта, название документа и его статус • Таблицы индексированы как отдельные чанки с заголовком и контекстом строки/столбца Разметка корпуса • Тип документа размечен (ГОСТ / патент / ТУ / внутренний регламент) • Тематическая область размечена для фильтрации (машиностроение, электротехника, строительство и т.д.) • Coverage проверена: какой процент нужных актуальных документов реально есть в корпусе Архитектура pipeline: от скана до верифицированного ответа Упрощённая схема production-pipeline для нормативно-технического корпуса: ``` PDF/скан → OCR (с VLM для таблиц и формул) → Нормализация (удаление артефактов, восстановление структуры) → Парсинг структуры (раздел → пункт → таблица) → Обогащение метаданными (статус, дата, тип документа) → Чанкинг по структуре + родительский контекст → Векторный индекс (+ keyword-индекс для гибридного поиска) → RAG: retrieval → reranking → генерация ответа → Верификация: ссылка на конкретный пункт конкретной редакции → Ответ пользователю со статусом документа → Escalation-флаг при низкой уверенности → передача эксперту ``` Два момента, которые часто пропускают. Первый: гибридный поиск (векторный + keyword) работает лучше, чем чисто семантический, для нормативных документов — потому что точные обозначения (ГОСТ 2.001-2013, МПК B23K 9/00) должны находиться точным совпадением, а не приближённым. Второй: escalation-флаг — не опция, а обязательный элемент для нормативного контекста. Система должна уметь сказать «я не уверен» и передать запрос эксперту. Специфика российских источников: ФИПС, ЕАПАТИС, Кодекс ФИПС / PatSearch — основная база патентов РФ. Публичный PatSearch предоставляет keyword-поиск по реферату и формуле, но не семантический. Полные тексты патентов доступны в PDF, часть — в виде сканов. Для построения RAG-системы нужно либо использовать API ФИПС (платный доступ), либо работать с выгрузками. Ключевое ограничение: PatSearch не покрывает международные патенты (PCT, EP) — для них нужен ЕАПАТИС или Espacenet. ЕАПАТИС — евразийская патентная база. Структурированные данные, лучше поддаётся автоматической обработке, чем часть архива ФИПС. Кодекс / Техэксперт — коммерческие агрегаторы нормативных документов. Дают актуальные редакции ГОСТов в структурированном формате, что существенно снижает стоимость OCR-этапа. Лицензионные условия нужно проверять на предмет допустимости использования для обучения/индексации. Важный нюанс по PatSearch: система работает по ключевым словам, что создаёт проблему терминологической вариативности — одно изобретение может быть описано десятками синонимов. Именно здесь семантический RAG даёт реальное преимущество перед стандартным поиском: он находит релевантные патенты даже при несовпадении терминологии. Корпоративный периметр: почему публичные API неприемлемы Работа с патентными заявками, описаниями ноу-хау и внутренними ТУ через публичные LLM API (ChatGPT, Claude, Gemini) создаёт два типа рисков. Риск утечки. Данные, отправленные в публичный API, могут использоваться провайдером для дообучения модели или храниться на серверах за пределами РФ. Для патентных заявок до подачи это означает потенциальную утрату новизны. Для ноу-хау — утрату режима коммерческой тайны. Регуляторный риск. Если в документах содержатся персональные данные сотрудников (подписи, ФИО в ТУ), передача в зарубежный API требует соответствия 152-ФЗ — включая трансграничную передачу данных. Подробнее об этом аспекте — в статье про регуляторику генеративного ИИ. Практическое решение — on-premise развёртывание открытых моделей (Mistral, Qwen, LLaMA-семейство) или использование российских облачных провайдеров с соответствующими соглашениями. Для задач поиска по нормативным документам модели размером 7–14B параметров при правильной инженерии данных дают качество, сопоставимое с GPT-4 на этой специфической задаче. Стоп-сигналы: когда ИИ нельзя без эксперта Сценарий | Почему нельзя без верификации Патентная чистота перед запуском производства | ИИ находит похожие документы, но не анализирует объём притязаний (claim limitations). Пропуск одного патента = судебный иск Нормоконтроль (подпись под документом) | Юридическая ответственность специалиста. ИИ-ответ без верификации — недопустимо Судебные споры и экспертизы | Любой вывод должен быть верифицирован аттестованным специалистом Сертификация продукции | Ошибка в трактовке пункта ГОСТ = отказ в сертификате или отзыв Разработка патентной заявки | Черновик — только заготовка; формула изобретения требует патентного поверенного Мини-кейс: когда система ошиблась Производственная компания запустила RAG-систему поверх корпуса ГОСТов для ответов на вопросы технологов. Через два месяца после запуска технолог получил ответ с требованиями к сварным соединениям — с корректной ссылкой на номер пункта и номер ГОСТа. Документ выглядел убедительно. Проблема обнаружилась при плановой проверке: ГОСТ был отменён в 2021 году и заменён новой редакцией с изменёнными допусками. Что пошло не так: при индексации метаданные статуса не добавлялись — все документы считались действующими. Staleness rate в корпусе составлял около 18%. Система не имела механизма проверки актуальности и не показывала статус документа в ответе. Как обнаружили: случайно, при сверке с реестром Росстандарта в рамках аудита. Не через метрики системы. Что изменили: добавили обязательное поле статуса в метаданные, настроили еженедельную сверку корпуса с реестром, добавили отображение статуса и даты актуализации в каждом ответе системы. Staleness rate снизился до 2% за месяц. Метрики для оценки системы Оценивать систему по субъективному ощущению — антипаттерн. Минимальный набор измеримых метрик: • Recall@5 / Recall@10 — доля тестовых запросов, где правильный пункт попал в топ-5/10 результатов. Целевое значение для production: Recall@5 ≥ 80% • Citation accuracy — доля ответов, где ссылка на пункт документа корректна и верифицируема. Цель: ≥ 90% • Hallucination rate — доля ответов с несуществующими номерами патентов или пунктами ГОСТ. Тестируется на контрольной выборке с известными правильными ответами. Цель: < 5% • OCR quality score — доля страниц с корректно распознанными таблицами и формулами. Проверяется до индексации. Порог запуска: ≥ 85% • Staleness rate — доля документов в индексе с истёкшим статусом. Цель: < 5%, проверяется ежемесячно • Escalation rate — доля запросов, переданных эксперту из-за низкой уверенности системы. Высокий показатель (> 30%) сигнализирует о проблемах с корпусом или моделью • Время поиска — среднее время от запроса до верифицированного ответа. Типичный результат после внедрения: с 15–20 минут до 30–60 секунд Тестовый набор запросов с известными правильными ответами нужно формировать до запуска системы — вместе с профильными специалистами (нормировщиками, патентными аналитиками). Без него невозможно измерить ни одну из перечисленных метрик. Что читать дальше Если вопрос выбора архитектуры (RAG vs. база знаний) ещё открыт — см. статью про базы знаний и RAG в корпоративном контексте. Если задача шире — запуск LLM в production без выделенной ML-команды — см. production-чеклист для LLM. Регуляторный контекст (152-ФЗ и генеративный ИИ) разобран в отдельном материале. *brezatech — интегратор ИИ в данные и процессы: разработка, BI и автоматизация для B2B.* Ключевые факты • RAG по нормативным документам даёт recall@5 до 92% — но только при качественной подготовке данных; на сырых сканах показатель падает ниже 50%. • Главный bottleneck — не модель, а OCR: таблицы и формулы ГОСТ распознаются корректно менее чем в 60% случаев при стандартном pipeline без специализированной обработки. • Публичные LLM (ChatGPT, Claude) галлюцинируют номера патентов в ~30% случаев на редких темах — и не имеют доступа к базам ФИПС, что делает их бесполезными для реального патентного поиска. • Staleness rate — доля устаревших редакций в индексе — критичнее для ГОСТов, чем для любого другого корпуса: стандарты обновляются, и система без метаданных статуса будет выдавать отменённые пункты. • Инженерия данных для нормативного корпуса занимает 60–70% от общего времени проекта — это не накладные расходы, а ключевой фактор точности.