Fits Calc
Главная / Блог / ИИ для инженера / Ingestion для RAG: chunking, metadata, revision и инженерные таблицы
ИИ для инженера · rag · Wave AI R5

Ingestion для RAG: chunking, metadata, revision и инженерные таблицы

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

К главномуОткрыть Fits Calc

Короткий ответ

Ingestion для RAG: chunking, metadata, revision и инженерные таблицы — это production-задача, а не демонстрационный prompt. Практический принцип: делить документы по смысловой структуре и сохранять связь чанка с документом, разделом, таблицей, revision и применимостью. Ключевое решение: универсальные чанки фиксированной длины удобны, но часто разрушают технические таблицы, обозначения и контекст ограничений. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.

Agent/RAG-платформы быстро меняются. Технические ссылки этой статьи проверены 02.10.2026; перед внедрением перепроверяются статусы API, preview/GA, лимиты, хранение данных и доступность функций.

Граница системы и предмет контроля

RAG — это не загрузка PDF в чат, а информационно-поисковая система вокруг модели. Качество ответа зависит от версии источника, сегментации, метаданных, прав доступа, retrieval-алгоритма, reranking и того, как контекст передан генератору. В инженерной среде особенно важны revision, статус документа, изделие, материал, обозначение, единицы, применимость и связь с первичным документом.

Слабый retrieval делает сильную модель бесполезной: она убедительно обобщит нерелевантный или устаревший контекст. Поэтому RAG принимают по контрольному набору вопросов и отдельно измеряют поиск и генерацию. Нельзя сводить проверку к субъективному «ответ выглядит правильно»: нужны ожидаемые документы, обязательные цитаты, проверки ACL, сценарии с противоречиями и вопросы, на которые система должна честно ответить «данных недостаточно».

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

Что должно быть определено до запуска

PDF/DOCX/HTML/CAD exportsФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.
структура заголовковФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.
таблицы и подписиФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.
revision metadataХранится с идентификатором источника, версией/статусом и областью применимости; устаревшие данные не смешиваются с действующими.
OCR qualityОпределение, единица, denominator и период измерения фиксируются до сравнения вариантов.

Артефакты и архитектурные границы

В RAG нужно физически разделять ingestion, index, retrieval и generation. Ingestion отвечает за нормализацию и metadata; index — за представление и обновление; retrieval — за отбор кандидатов и reranking; generation — за формирование ответа только из разрешённого контекста. Ошибка любого слоя должна быть локализуема по trace.

Для инженерных документов ключевой объект — не chunk сам по себе, а chunk вместе с document ID, revision, status, ACL, section/page и датой действия. При конфликте revisions система должна уметь отдать приоритет действующему документу или явно показать противоречие, а не смешивать фрагменты в один правдоподобный ответ.

document manifestИмеет стабильный идентификатор, статус приёмки и связь с исходной задачей.
semantic chunksИмеет стабильный идентификатор, статус приёмки и связь с исходной задачей.
table chunksИмеет стабильный идентификатор, статус приёмки и связь с исходной задачей.
metadata schemaКонфигурационно управляемый объект: version, owner, change history и дата действия.
ingestion quality reportEvidence для аудита и сравнения версий; по нему восстанавливается фактическое выполнение.

Практический workflow

Шаг 1. классифицировать типы документов. Определите authoritative corpus и правила исключения superseded документов.
Шаг 2. разобрать структуру и таблицы. При ingestion сохраняйте структуру, units, revision и ACL, а не только plain text.
Шаг 3. создать metadata schema. Retrieval проверяйте на expected document IDs до оптимизации генерации.
Шаг 4. выбрать стратегию chunking по типу. Reranking и filters тестируйте на запросах с близкими обозначениями и конфликтующими revisions.
Шаг 5. провести quality checks. Claims связывайте с конкретными цитатами; отсутствие evidence должно быть видимым.
Шаг 6. версионировать index batch. Отдельно тестируйте denial/ACL и prompt injection внутри документов.
Шаг 7. зафиксировать ingestion report. Любое изменение index/retriever проходит regression на frozen query set.

После retrieval сохраняются query, filters, найденные IDs, scores/reranking и применённые ACL. Если требуемый источник не найден либо найден только superseded документ, генерация должна либо остановиться, либо явно пометить недостаточность доказательств.

Инженерный сценарий

ВходPDF/DOCX/HTML/CAD exports; структура заголовков; таблицы и подписи; revision metadata; OCR quality. Данные должны быть привязаны к проекту, revision и владельцу.
Действиеделить документы по смысловой структуре и сохранять связь чанка с документом, разделом, таблицей, revision и применимостью. Каждый tool-call проходит серверную валидацию и попадает в trace.
Контрольне разрывать строку таблицы от заголовка; хранить parent document ID; помечать OCR confidence; удалять дубли; отмечать superseded. Для критических изменений добавляется независимое подтверждение.
Выходdocument manifest; semantic chunks; table chunks; metadata schema; ingestion quality report. Финальный результат должен быть пригоден для повторной проверки без скрытого контекста.

RAG сначала запускают в shadow/read-only режиме: ответы и цитаты сравниваются с экспертным эталоном. Только после стабилизации retrieval система становится источником контекста для downstream-agentов.

Что измерять

ingestion successФиксируйте numerator/denominator и сегментируйте по типу/сложности задач; общий процент может скрыть critical slice.
OCR exception rateФиксируйте numerator/denominator и сегментируйте по типу/сложности задач; общий процент может скрыть critical slice.
duplicate rateФиксируйте numerator/denominator и сегментируйте по типу/сложности задач; общий процент может скрыть critical slice.
metadata completenessОпределение метрики, единица, denominator и окно наблюдения фиксируются в metric dictionary.
superseded leakageОпределение метрики, единица, denominator и окно наблюдения фиксируются в metric dictionary.

RAG оценивают минимум в двух слоях: retrieval и generation. Высокий groundedness не компенсирует плохой Recall@k, а высокий recall не компенсирует неверные citations или доступ к запрещённому документу.

Критерии приёмки

КонтрольМинимальный критерий
ScopeДля «Ingestion для RAG: chunking, metadata, revision и инженерные таблицы» однозначно определено, что система делает и что остаётся вне её полномочий.
DataВсе входы имеют источник, revision/status и область применимости; неизвестные значения не подставляются автоматически.
Controlне разрывать строку таблицы от заголовка; хранить parent document ID; помечать OCR confidence.
EvidenceСохраняются document manifest, semantic chunks, table chunks, metadata schema; по ним можно восстановить ход операции.
QualityМинимум две профильные метрики контролируются на versioned eval-наборе: ingestion success и OCR exception rate.
ReleaseИзменяющие действия имеют approval/rollback там, где цена ошибки выходит за согласованный риск.

Failure modes и защитные меры

Главная ошибка — считать наличие цитаты доказательством корректного RAG. Цитата может вести к нерелевантной, устаревшей или недоступной пользователю revision; проверяются retrieval и claim-to-source связь.
  • таблица превращена в набор бессвязных чисел. Защитная мера: не разрывать строку таблицы от заголовка; событие сохраняется как regression/incident case.
  • дубли разных редакций конкурируют. Защитная мера: хранить parent document ID; событие сохраняется как regression/incident case.
  • OCR меняет десятичный разделитель. Защитная мера: помечать OCR confidence; событие сохраняется как regression/incident case.
  • теряются единицы. Защитная мера: удалять дубли; событие сохраняется как regression/incident case.
  • chunk не содержит scope ограничения. Защитная мера: отмечать superseded; событие сохраняется как regression/incident case.

Как переводить из пилота в production

Пилот RAG начинают с ограниченного корпуса с известными owners и revisions. До подключения генерации проверяют retrieval: контрольные вопросы, expected document IDs, фильтры и ACL. Затем добавляют citations/groundedness и только после этого используют ответы в агентном workflow.

Обновление corpus и retrieval configuration выпускают как версию индекса. Для canary сравнивают old/new index на одном query set; новые документы не должны ухудшать critical queries. При деградации переключение на предыдущий индекс выполняется без переиндексации всего источника.

Traceability и эксплуатационная запись

Минимальная запись RAG: query, filters, corpus/index version, retrieved document/chunk IDs, scores и reranking, ACL decision, контекст генерации, claims/citations и итоговый abstention/answer status.

Чек-лист перед production

КонтрактScope, входы, tools и stop condition описаны до запуска.
ПраваRead/write, сеть и секреты ограничены минимально необходимым.
EvidenceКаждый критичный вывод или action связан с источником и trace.
EvalsЕсть обычные, граничные, негативные и regression cases.
RollbackДля side effect проверено восстановление, а не только наличие команды отката.
OwnerНазначен владелец качества процесса и владелец технической платформы.

Навигация по Wave AI R5 · часть 2 из 5

Часть «RAG» содержит 7 связанных материалов. Серия идёт от архитектуры к контролю и измерению; каждая статья самостоятельна и ссылается на соседние элементы общего production-контура.

8. RAG для инженерной документации: полная архитектура от источника до цитаты9. Ingestion для RAG: chunking, metadata, revision и инженерные таблицы10. Hybrid retrieval: keyword + vector + reranking для технических запросов11. Цитаты, provenance и ACL в RAG: как доказать происхождение ответа12. Agentic retrieval: когда RAG должен сам планировать несколько поисковых запросов13. Как измерять RAG: golden questions, retrieval metrics и groundedness14. Failure modes RAG: устаревшие документы, prompt injection и противоречивые источники
← RAG для инженерной документации: полная архитектура от источника до цитатыHybrid retrieval: keyword + vector + reranking для технических запросов →R4: Инженерная база знаний и RAG

Связать AI-контур с проверяемыми данными Fits Calc

Fits Calc целесообразно использовать как детерминированный расчётный и справочный слой: агент получает структурированные входы и результаты через контролируемые tools, а не воспроизводит инженерный расчёт свободным текстом. Это упрощает verifier, traceability и повторную проверку.

Открыть Fits Calc →

Источники и официальная документация

  1. OpenAI — File search
  2. Microsoft — RAG in Azure AI Search
  3. Microsoft — Agentic retrieval overview
  4. Microsoft — Agentic RAG architecture
  5. OpenAI — Evaluate agent workflows
  6. NIST — Generative AI Profile NIST AI 600-1
Проверено: 02.10.2026Production controls обязательныHuman approval — по риску действия