Field Log · Entry
RAG Metadata Schema·Ontology·Entity Resolution: 검색 필터를 지식 계약으로 (4/10)
오늘의 결론
- RAG metadata는 vector DB의 JSON payload가 아니라 값의 type, vocabulary, source, confidence, valid time과 schema revision을 가진 assertion입니다.
tags: [식각기, etcher, Etch]처럼 자유 문자열을 쌓지 않습니다. Concept ID에 preferred label, alias, notation, broader·narrower 관계를 연결해 표시 문자열과 의미 identity를 분리합니다.- 문서에 나온
EX-01,Etcher X,식각 1호기가 같은 실제 장비인지는 별도 entity resolution 문제입니다. 후보 생성, evidence 비교, link·new·abstain 결정을 추적합니다.- Provenance와 uncertainty를 값 옆에 둡니다. Source field, parser 추출, 규칙, LLM enrichment, 사람 검수는 신뢰 수준과 재실행 조건이 다릅니다.
- Canonical metadata store와 search projection을 분리합니다. Sparse·vector index에는 query와 filter에 필요한 typed field만 flatten하고, 정본 assertion에서 언제든 다시 만듭니다.
앞 글에서는 locator, source object, business version, parser representation과 chunk span을 분리했습니다. 이제 그 안정 ID에 장비·공정·문서 유형·시간·품질·provenance를 연결합니다.
raw source fields and text mentions
→ validate typed metadata contract
→ map labels and codes to controlled concepts
→ resolve mentions to canonical real-world entities
→ store assertions with provenance, confidence, valid time
→ project selected fields into search indexes
→ parse query into the same concept and entity IDs이 글에서 답하는 질문
- Metadata field를 어떤 책임과 type으로 나눠야 하는가?
- 자유 태그, taxonomy, ontology, entity는 어떻게 다른가?
- 장비 alias와 alarm code를 canonical ID로 어떻게 정규화하는가?
- LLM이 추출한 metadata의 confidence와 provenance를 어떻게 저장하는가?
- Schema와 vocabulary가 바뀔 때 index를 어떻게 재생성하는가?
- Query text와 document metadata를 같은 semantic ID로 연결하는 방법은 무엇인가?
그림 1. Index payload는 검색을 위한 projection이다. Metadata의 정본은 누가·어떤 근거로·언제·어떤 schema와 vocabulary에서 값을 주장했는지 설명하는 versioned assertion이다.
1. 자유 Tag가 늘어날수록 검색은 불안정해진다
초기에는 다음처럼 시작합니다.
{
"tags": ["Etcher", "식각기", "EX-01", "Alarm", "E204", "최신"]
}곧 이런 값이 추가됩니다.
etcher · Etch · ETCH · 식각 · 식각장비
EX01 · EX-01 · Etcher-X-1 · 1호기
alarm-E204 · E-204 · error 204
approved · 승인 · final · 최종 · 최신문제:
- 같은 의미가 여러 string으로 분산됩니다.
- 같은 string이 다른 의미를 가질 수 있습니다.
최신은 시간이 지나면 거짓이 됩니다.- Hierarchy expansion이 어렵습니다.
- Alias 변경이 모든 document rewrite로 이어집니다.
- Filter recall과 cardinality를 예측하기 어렵습니다.
- 누가 값을 만들었는지 알 수 없습니다.
Tag는 사람이 입력한 label일 수 있지만 canonical semantic key가 되어서는 안 됩니다.
2. Metadata의 다섯 책임
1. Identity와 Provenance
document_id: doc_...
document_version_id: docv_...
source_namespace: manual-repository
source_object_id: item-1234
source_revision: etag-8
raw_digest: sha256:...
representation_id: repr_...
ingestion_run_id: run_...문서와 처리 실행을 추적합니다.
2. Content와 Business Facet
document_type_id: doctype:approved-procedure
language: ko
title: "E204 Vacuum Alarm Recovery"
owner_org_id: org:process-engineering
site_id: site:fab-a
process_id: process:etch
equipment_model_id: model:etcher-x
equipment_ids: [equipment:EX01]
alarm_codes: [alarm:E204]검색·분류에 쓰는 업무 의미입니다.
3. Temporal
issued_at: 2026-07-15
valid_from: 2026-07-15T10:00:00+09:00
valid_to: null
observed_at: 2026-07-15T10:03:21+09:00
recorded_at: 2026-07-15T10:04:02+09:00“언제부터 사실인가”와 “언제 시스템이 알았는가”를 구분합니다.
4. Security와 Governance
tenant_id: tenant-a
acl_snapshot_id: acl_...
classification_id: class:internal-restricted
retention_policy_id: retention:manual-7y
pii_categories: []
legal_hold: falseSecurity field는 추천용 tag가 아니라 강제 policy input입니다.
5. Quality와 Processing
parser_revision: parser-config-7
layout_quality: 0.97
ocr_low_confidence_spans: 2
metadata_schema_revision: metadata-v5
vocabulary_revision: domain-v12
review_status: auto_validated어떤 품질의 파생물인지 설명합니다.
3. Descriptive와 Operational Metadata를 구분한다
Descriptive
Title, creator, subject, language처럼 자원을 설명합니다. DCMI Metadata Terms는 title, creator, subject, identifier, issued, modified 등 재사용 가능한 metadata term을 제공합니다.
Structural
Heading path, page, table, parent element, reading order처럼 문서 내부 구조를 설명합니다.
Administrative
Source, owner, rights, retention, classification, license를 설명합니다.
Operational
Parser revision, processing state, confidence, quarantine reason, index generation을 설명합니다.
이들을 한 flat map에 섞으면 display field와 authorization field가 같은 방식으로 취급됩니다. Namespace 또는 nested object로 책임을 드러냅니다.
{
"descriptive": {},
"structural": {},
"administrative": {},
"operational": {}
}4. Field마다 Semantic Contract를 쓴다
필드 이름과 type만으로 부족합니다.
field: valid_from
definition: "이 document version의 내용이 업무상 효력을 갖기 시작한 시각"
type: timestamp-with-timezone
cardinality: exactly-one
source_priority:
- approved_source_field
- signed_document_header
- human_review
forbidden_sources:
- filesystem_mtime
null_semantics: "효력 시각을 알 수 없음"
timezone_policy: "source timezone required; UTC normalized"
update_semantics: "new assertion, never silent overwrite"
used_by:
- temporal_filter
- latest_version_selectionmodified_at을 source file mtime, parser 실행 시각, 업무 수정일 중 무엇으로 쓰는지 명확히 합니다.
5. Null, Empty, Unknown, Not Applicable은 다르다
null / unknown = 값을 아직 모름
[] / none = 확인했으나 값이 없음
not_applicable = 이 document type에는 해당하지 않음
redacted = 값은 있으나 공개할 수 없음
extraction_failed = 값 후보를 얻지 못함모두 빈 문자열로 저장하면 completeness와 filter 의미가 깨집니다.
{
"equipment_ids": [],
"equipment_ids_status": "reviewed_none",
"equipment_ids_assertion": "assert_..."
}6. Type을 Search Engine 편의에 맞춰 왜곡하지 않는다
bad:
issued_at: "2026년 7월쯤"
confidence: "높음"
equipment_ids: "EX01, EX02"
better:
issued_at:
value: 2026-07
precision: month
confidence:
score: 0.91
calibration_set: metadata-ko-v3
equipment_ids:
- equipment:EX01
- equipment:EX02Canonical store는 의미 type을 보존하고, search projection에서 keyword·date·numeric field로 변환합니다.
7. Schema Validation을 Ingestion Gate로 둔다
JSON document에는 JSON Schema Draft 2020-12를 사용할 수 있습니다.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://example.internal/schema/rag-metadata-v5",
"type": "object",
"required": ["document_version_id", "document_type_id", "provenance"],
"properties": {
"document_version_id": {"type": "string", "pattern": "^docv_"},
"document_type_id": {"type": "string"},
"equipment_ids": {
"type": "array",
"items": {"type": "string", "pattern": "^equipment:"},
"uniqueItems": true
},
"valid_from": {"type": ["string", "null"], "format": "date-time"}
},
"unevaluatedProperties": false
}RDF graph를 쓰는 경우 SHACL은 node와 property shape로 RDF graph의 구조와 constraint를 검증합니다.
Schema 통과는 semantic correctness를 보장하지 않습니다. equipment:EX99가 존재하지 않거나 document type과 retention policy 조합이 금지됐는지는 referential·business rule gate가 필요합니다.
8. 자유 문자열에서 Controlled Vocabulary로
Vocabulary concept 예시:
concept_id: concept:equipment-type/etcher
scheme_id: scheme:equipment-taxonomy
pref_labels:
ko: 식각 장비
en: Etcher
alt_labels:
ko: [식각기, 에처]
en: [Etch tool]
notation: ETCH
broader: concept:equipment-type/process-tool
narrower:
- concept:equipment-type/plasma-etcher
- concept:equipment-type/wet-etcher
related:
- concept:process/etch
status: active
valid_from: 2026-01-01SKOS Reference는 concept URI, prefLabel, altLabel, notation, broader, narrower, related, concept scheme과 mapping relation을 정의합니다. 모든 조직이 RDF를 써야 한다는 뜻이 아니라 taxonomy를 string list보다 명시적으로 모델링할 수 있는 공통 언어입니다.
9. Concept와 Entity를 구분한다
Concept
일반적인 종류·분류입니다.
concept:equipment-type/etcher
concept:alarm-type/vacuum
concept:document-type/approved-procedureEntity
실제 개별 대상입니다.
equipment:EX01
site:FAB-A
organization:process-engineering
document:alarm-manual-42Etcher는 concept일 수 있고 FAB-A의 EX-01은 entity입니다. Entity는 model, serial, site, valid time과 상태를 가집니다.
{
"entity_id": "equipment:EX01",
"entity_type": "equipment",
"instance_of": "concept:equipment-type/plasma-etcher",
"labels": ["EX-01", "Etcher X 1호기"],
"site_id": "site:FAB-A",
"model_id": "model:ETCHER-X",
"valid_from": "2025-01-10T00:00:00+09:00",
"valid_to": null
}10. Label은 Identity가 아니다
Entity의 표시 이름은 바뀔 수 있습니다.
old label: Etcher-X-01
new label: EX-01
local alias: 1호기
maintenance nickname: Blue Chamber모든 document를 새 label로 rewrite하기보다 assertion은 entity ID를 유지하고 display 시 현재 label을 resolve합니다. Historical citation에서는 당시 label을 보여줄 수 있도록 mention text도 보존합니다.
11. Entity Resolution의 다섯 단계
Step 1. Mention Detection
Document text·table·source metadata에서 entity 후보 span을 찾습니다.
{
"mention_text": "EX-01",
"element_id": "elem_142",
"char_span": [18, 23],
"context": "EX-01 chamber pressure alarm E204"
}Step 2. Normalization
Unicode, whitespace, punctuation을 보수적으로 정규화합니다. Domain code의 hyphen과 leading zero는 의미가 있을 수 있습니다.
Step 3. Candidate Generation
alias exact match
+ normalized code match
+ same entity type
+ site/model constraints
+ lexical or embedding retrieval전체 entity와 expensive model 비교를 하지 않고 후보 set을 만듭니다.
Step 4. Candidate Scoring
features:
alias_exact: true
code_exact: true
site_match: true
model_match: true
surrounding_alarm_compatibility: true
temporal_overlap: true
source_field_authority: 1.0Step 5. Decision
LINK existing entity
CREATE new entity
ABSTAIN ambiguous or insufficient evidence
REVIEW high-impact uncertain case모든 mention을 억지로 link하면 wrong merge가 발생합니다. Abstention은 실패가 아니라 안전한 결과입니다.
12. Candidate Generation Recall을 먼저 측정한다
Correct entity가 후보 set에 없으면 scorer가 아무리 좋아도 실패합니다.
candidate_recall@k
= correct entity included in top-k candidatesAlias dictionary, code index, site partition과 lexical/dense candidate retrieval을 분리 평가합니다.
| Stage | Metric |
|---|---|
| Mention detection | Span precision·recall |
| Candidate generation | Recall@k |
| Linking | Accuracy·macro F1 |
| Abstention | Risk-coverage curve |
| New entity | Duplicate creation rate |
| Merge | Wrong-merge rate |
장비·사람·조직·alarm code처럼 entity type별로 난이도가 다르므로 macro와 class별 지표를 봅니다.
13. Alias Dictionary도 Versioned Data다
alias: "1호기"
entity_id: equipment:EX01
scope:
site_id: site:FAB-A
document_owner: org:etch-team
valid_from: 2025-03-01
valid_to: 2026-01-31
source: approved-equipment-registry
asserted_by: sync-job-v4
confidence: 1.0다른 site의 “1호기”는 다른 entity일 수 있습니다. Alias를 global map으로 만들지 않고 scope와 valid time을 둡니다.
14. Code System과 Human Label을 분리한다
Alarm code E204도 model별로 뜻이 다를 수 있습니다.
bad identity:
alarm:E204
safer identity:
alarm-code:<vendor>/<model-family>/E204entity_id: alarm-code:vendor-x/etcher-x/E204
notation: E204
label_ko: 진공 압력 인터록
applies_to_model: model:ETCHER-X
valid_from: 2025-01-01
source_authority: vendor-alarm-registry-v8사용자가 E204만 입력하면 equipment context와 tenant corpus로 candidate를 좁힙니다.
15. Assertion에 Provenance를 붙인다
{
"assertion_id": "assert_01j...",
"subject_id": "docv_01j...",
"predicate": "mentions_equipment",
"object_id": "equipment:EX01",
"source": {
"type": "document_span",
"element_id": "elem_142",
"char_span": [18, 23]
},
"method": {
"type": "entity_linker",
"revision": "entity-linker-v6"
},
"confidence": 0.96,
"calibration_set": "equipment-ko-v3",
"valid_from": "2026-07-15T10:00:00+09:00",
"recorded_at": "2026-07-15T10:04:02+09:00",
"review": null
}W3C PROV-O의 Entity·Activity·Agent와 wasGeneratedBy, used, wasDerivedFrom 관점은 metadata value의 기원을 표현하는 데도 적용할 수 있습니다.
16. Source Priority와 Conflict를 명시한다
같은 field에 서로 다른 값이 올 수 있습니다.
source DMS field: equipment = EX-01
document title: equipment = EX-02
entity linker: equipment = EX-01, confidence 0.91
human review: equipment = EX-02Last writer wins로 덮지 않습니다.
resolution_policy:
field: equipment_ids
source_priority:
- approved_asset_registry
- human_review
- signed_document_metadata
- source_dms_field
- deterministic_rule
- learned_extractor
allow_multiple: true
conflict_action: quarantine_if_high_impact원 assertion을 모두 보존하고 active projection을 만드는 resolution decision을 별도 record로 남깁니다.
17. LLM Metadata Extraction을 어떻게 다룰까
LLM은 long-tail label과 context-dependent entity를 찾는 데 유용하지만 출력을 사실로 바로 저장하지 않습니다.
LLM proposal
→ structured schema validation
→ source-span grounding check
→ controlled vocabulary lookup
→ deterministic business rules
→ confidence / abstention
→ review for high-impact classes{
"proposed_document_type": "doctype:approved-procedure",
"evidence_element_ids": ["elem_2", "elem_7"],
"model_revision": "model-x@sha256:...",
"prompt_revision": "metadata-extract-v4",
"raw_output_ref": "s3://runs/...",
"validation": "failed_missing_approval_signature"
}Model confidence를 calibration 없이 0.98로 출력하게 하지 않습니다. Evidence와 rule result를 우선합니다.
18. Search Index에는 Projection만 둔다
Canonical assertion store는 rich하지만 query engine에는 너무 복잡할 수 있습니다.
{
"chunk_id": "chk_...",
"document_version_id": "docv_...",
"text": "...",
"document_type_id": "doctype:approved-procedure",
"equipment_ids": ["equipment:EX01"],
"equipment_type_ids": ["concept:equipment-type/plasma-etcher"],
"alarm_code_ids": ["alarm-code:vendor-x/etcher-x/E204"],
"site_id": "site:FAB-A",
"valid_from_epoch": 1784077200,
"valid_to_epoch": null,
"acl_principal_ids": ["group:etch-engineers"],
"metadata_projection_revision": "search-meta-v8"
}Index에는:
- Canonical ID를 filter field로 둡니다.
- Label은 display와 lexical match 보조용으로 둡니다.
- Provenance 전체 대신 assertion ID를 둡니다.
- High-cardinality raw trace는 별도 store에 둡니다.
- Null semantics와 array behavior를 query engine에 맞게 test합니다.
19. Document와 Chunk Metadata Inheritance
Document metadata를 모든 chunk에 복사할 수 있지만 inheritance를 명시해야 합니다.
document-level:
owner, tenant, document type, valid time
section-level:
heading path, process step, warning scope
table-row-level:
equipment, alarm code, parameter values
chunk-level projection:
resolved union + provenance referencesChild가 parent 값을 override하는지 union하는지 field별 rule을 둡니다.
inheritance:
tenant_id: immutable_parent
acl_snapshot_id: most_restrictive
equipment_ids: union
document_type_id: document_only
heading_path: nearest_structural_parent
valid_time: intersectionACL은 단순 union하면 권한이 넓어질 수 있으므로 security semantics를 별도 설계합니다.
20. Hierarchy Expansion은 Query Policy다
사용자가 식각 장비를 검색하면 하위 concept를 포함할 수 있습니다.
concept:equipment-type/etcher
├─ plasma-etcher
└─ wet-etcher하지만 모든 hierarchy를 무제한 확장하면 recall은 늘고 precision이 무너집니다.
expansion_policy:
field: equipment_type_id
include_self: true
include_narrower_depth: 2
include_related: false
vocabulary_revision: domain-v12Query trace에 expansion set을 남겨 검색 결과를 재현합니다.
21. Query Entity Linking도 같은 Registry를 사용한다
Document ingestion만 entity link하고 query는 raw text로 검색하면 filter와 의미가 연결되지 않습니다.
query: "EX-01 E204 최신 복구 절차"
parsed intent:
equipment_id = equipment:EX01
alarm_code_id = alarm-code:vendor-x/etcher-x/E204
temporal = active_at(now)
document_type = doctype:approved-procedureQuery linker는 dialog context, user site·tenant, previous turn의 equipment를 활용할 수 있습니다. Ambiguous하면 Agent가 clarification을 요청하거나 여러 candidate로 bounded retrieval을 합니다.
22. Filter-before-Retrieve와 Filter-after-Retrieve
Typed metadata가 있어도 적용 위치가 중요합니다.
pre-filter:
allowed and relevant candidate space 안에서 ANN 탐색
post-filter:
ANN top-k를 뽑은 뒤 metadata로 제거Restrictive filter를 post-filter하면 k보다 훨씬 적은 결과가 남을 수 있습니다. OpenSearch vector filtering 문서도 efficient k-NN filtering과 post-filtering의 결과 수 차이를 설명합니다.
Security filter는 recall 최적화가 아니라 반드시 enforcement boundary 안에서 적용합니다. 자세한 ACL 설계는 다음 글에서 다룹니다.
23. Schema Evolution
변경을 세 종류로 나눕니다.
Additive
Optional field 추가, 새 concept 추가. 보통 backward compatible하지만 consumer가 unknown field를 허용하는지 확인합니다.
Semantic Change
Field 이름은 같지만 정의가 바뀝니다.
old site_id = document owner site
new site_id = equipment physical site이름을 재사용하지 말고 새 field 또는 major schema를 만듭니다.
Breaking Structural Change
String을 array로, label을 canonical ID로 바꿉니다. Dual-read/dual-write와 backfill이 필요합니다.
schema_revision: metadata-v6
compatible_readers: [v5, v6]
migration:
from: equipment_name
to: equipment_ids
resolver_revision: equipment-map-v424. Vocabulary Evolution
Concept도 split·merge·deprecate됩니다.
{
"old_concept": "concept:etcher",
"status": "deprecated",
"replaced_by": [
"concept:plasma-etcher",
"concept:wet-etcher"
],
"change_type": "split",
"effective_at": "2026-07-01",
"mapping_note": "기존 문서는 자동 단일 매핑 불가"
}Split을 한 concept로 임의 선택하면 잘못된 metadata가 됩니다. unresolved_legacy_concept로 두고 문서 evidence를 다시 보거나 review합니다.
SKOS의 exactMatch, closeMatch, broadMatch, narrowMatch처럼 mapping strength를 구분하는 것이 유용합니다.
25. Entity Merge와 Split
두 entity가 같은 것으로 밝혀질 수 있습니다.
equipment:EX-01-old
equipment:ETCHER-X-1
→ same physical equipmentHard delete와 ID rewrite보다 redirect relation을 둡니다.
{
"from_entity": "equipment:EX-01-old",
"to_entity": "equipment:EX01",
"relation": "merged_into",
"effective_at": "2026-07-10",
"evidence": "asset-registry-ticket-182",
"reversible": true
}잘못 merge됐다면 split할 수 있도록 original assertion과 mention mapping을 보존합니다.
26. Metadata Quality Metric
Completeness
required field completeness
conditional completeness by document typeApproved procedure에는 valid_from, owner, approval state가 필수지만 일반 note에는 아닐 수 있습니다.
Validity
- Schema type·pattern
- Vocabulary ID 존재
- Entity reference 존재
- Allowed combination
- Temporal interval consistency
Accuracy
Gold document에서 field exact match, entity linking precision·recall을 봅니다.
Consistency
같은 document version에서 source field와 text assertion 충돌, entity site와 document site 불일치 등을 봅니다.
Timeliness
Vocabulary·entity registry 변경 후 search projection 반영 지연을 봅니다.
Uniqueness
Duplicate entity 생성과 alias collision을 측정합니다.
27. Release Gate
metadata_release: search-meta-v8
gates:
schema_valid_rate: 1.0
required_field_complete:
approved_procedure: ">= 0.999"
unknown_concept_rate: "<= baseline"
entity_candidate_recall_at_20: ">= 0.995"
entity_wrong_link_rate: "<= 0.001"
high_impact_wrong_link: 0
stale_entity_reference: 0
acl_reference_missing: 0
projection_count_parity: 1.0
query_filter_regression: "pass"수치는 예시값입니다. Wrong link 비용이 높은 equipment·safety entity에는 더 엄격한 gate와 human review를 둡니다.
28. 가상 반도체 문서 적용 예시
아래는 실제 회사 metadata가 아닌 가상 예시입니다.
title: "Etcher X 1호기 E204 조치"
source field equipment: "EX01"
body: "식각기 X-1의 chamber pressure가..."
site: "FAB A"Pipeline 결과:
EX01,Etcher X 1호기,식각기 X-1mention을 검출합니다.- Alias·site·model evidence로
equipment:EX01후보를 link합니다. E204는 equipment model context를 사용해alarm-code:vendor-x/etcher-x/E204로 연결합니다.식각기는concept:equipment-type/plasma-etcher로 mapping합니다.- Source field와 text linker assertion을 모두 보존합니다.
- Approved equipment registry와 일치해 active projection을 만듭니다.
- Query의
1호기도 user site scope 안에서 같은 entity로 resolve합니다.
다른 FAB에 1호기가 있다면 site context 없이는 abstain하거나 clarification을 요청합니다.
29. 최소 구현 순서
1단계. Field Dictionary
현재 payload field의 정의, type, source, null semantics, consumer를 표로 만듭니다.
2단계. Typed Schema와 Validation
Stringified list·date를 고치고 unknown field와 invalid ID를 quarantine합니다.
3단계. 핵심 Vocabulary 1개
Document type 또는 equipment type처럼 filter 가치가 높은 축부터 concept ID와 alias를 만듭니다.
4단계. Entity Registry
Source asset registry처럼 authoritative ID가 있는 entity부터 시작합니다. LLM으로 없는 master data를 만들어내지 않습니다.
5단계. Assertion Provenance
Source field, rule, model, human review를 구분하고 active value resolution policy를 둡니다.
6단계. Search Projection과 Query Linking
Canonical ID를 document와 query 양쪽에 적용하고 gold query로 filter recall을 검증합니다.
실전 체크리스트
- Metadata를 identity·descriptive·structural·administrative·operational 책임으로 분리했다.
- Field마다 definition, type, cardinality, null, source와 consumer가 있다.
- Unknown·empty·not applicable·redacted·failed 상태를 구분한다.
- Timestamp timezone과 precision을 보존한다.
- Canonical schema를 ingestion에서 검증하고 invalid record를 드러낸다.
- 자유 label 대신 stable concept·entity ID를 filter key로 쓴다.
- Preferred label, alias, notation과 hierarchy가 versioned vocabulary에 있다.
- Concept 종류와 실제 entity instance를 구분한다.
- Alias에 scope와 valid time이 있다.
- Entity linking을 mention·candidate·score·decision 단계로 분해했다.
- Link·new·abstain·review 결과와 evidence를 저장한다.
- Candidate recall과 wrong-link rate를 따로 본다.
- Source·rule·model·human assertion을 provenance로 구분한다.
- Conflict를 last-writer-wins로 숨기지 않는다.
- LLM 제안은 source span·schema·vocabulary와 business rule을 검증한다.
- Canonical assertion store와 search projection이 분리돼 있다.
- Document→section→chunk inheritance rule이 field별로 정의돼 있다.
- Query도 같은 vocabulary와 entity registry로 link한다.
- Schema·vocabulary·entity merge/split migration이 reversible하다.
- Metadata release gate가 completeness뿐 아니라 accuracy·timeliness를 포함한다.
스스로 확인하기
Q1. Vector DB payload schema가 있으면 metadata contract가 충분한가?
아닙니다. Storage type 외에 field 의미, source priority, null semantics, vocabulary, valid time, provenance와 evolution rule이 필요합니다. Vector DB payload는 canonical metadata의 검색 projection으로 두는 편이 안전합니다.
Q2. Alias를 많이 넣으면 entity resolution 없이도 되지 않는가?
단일 scope의 unique code에는 충분할 수 있습니다. 그러나 1호기, E204처럼 site·model·시간에 따라 다른 대상을 뜻하면 candidate와 context evidence, abstention이 필요합니다.
Q3. LLM이 metadata를 잘 추출하면 confidence score만 저장하면 되는가?
아닙니다. Model·prompt revision, source span, schema·vocabulary validation, calibration set과 review 상태가 있어야 합니다. Self-reported confidence를 사실 확률로 해석하지 않습니다.
Q4. Concept label을 바꾸면 모든 index를 다시 만들어야 하는가?
Canonical ID를 유지하고 label만 바뀌면 display·lexical alias projection만 갱신할 수 있습니다. Concept split·merge처럼 의미가 바뀌면 affected assertion을 재판정하고 새 generation을 검증합니다.
Q5. Metadata filter는 dense retrieval 뒤에 적용해도 되는가?
Restrictive filter는 post-filter 후 top-k가 부족해질 수 있고, ACL은 unauthorized candidate가 downstream에 노출될 수 있습니다. Engine이 지원하는 filtered retrieval과 authorization boundary를 설계해야 합니다.
마무리
Metadata의 목표는 tag를 많이 붙이는 것이 아니라 document와 query가 같은 의미 identity를 공유하게 만드는 것입니다.
typed field contracts
+ controlled concepts
+ canonical entities
+ scoped aliases and valid time
+ assertion provenance and uncertainty
+ rebuildable search projections
= trustworthy metadata retrieval layer다음 글 RAG ACL·Multi-tenancy·Security Filtering에서는 source 권한을 document·chunk에 전파하고, tenant isolation과 filtered ANN, revoke SLO, cache·citation까지 권한을 유지하는 방법을 다룹니다.
참고문헌
- W3C, SKOS Simple Knowledge Organization System Reference, W3C Recommendation, 2009.
- W3C, Shapes Constraint Language (SHACL), W3C Recommendation, 2017.
- W3C, PROV-O: The PROV Ontology, W3C Recommendation, 2013.
- Dublin Core Metadata Initiative, DCMI Metadata Terms, DCMI Recommendation, 2020.
- JSON Schema, Draft 2020-12 Specification, 2022.
- OpenLineage, Core Model and Facets, accessed 2026-07-16.
- OpenSearch Project, Filtering Vector Search Results, accessed 2026-07-16.
검증 메모 — 표준과 공식 문서는 2026년 7월 16일 확인했습니다. Metadata field, vocabulary와 entity registry는 조직마다 다르며 본문의 equipment·alarm namespace와 release threshold는 가상 예시입니다. 실제 master data owner, source authority, tenant·ACL·temporal semantics를 먼저 합의하고 domain-stratified entity pair와 query set에서 candidate recall, wrong link, abstention, filter 결과와 migration replay를 검증해야 합니다.