ИИ по ГОСТ, патентам и спецификациям: где помогает поиск, где нужна инженерия

Три зоны применения: матрица задач и рисков

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

Ключевой вывод из матрицы: зона поиска и навигации — наиболее зрелая и безопасная для внедрения. Именно здесь 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 на этой специфической задаче.

Стоп-сигналы: когда ИИ нельзя без эксперта

Мини-кейс: когда система ошиблась

Производственная компания запустила 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.