blog.ruahverce Vol · 2026 · Issue 013 — A field log of LLMs, RAG, and ML systems

Field Log · Entry

RAG Data Quality·Drift·Observability: 조용한 검색 품질 저하를 찾는 법 (8/10)

원천부터 parse·metadata·embedding·index·retrieval까지 lineage와 품질 assertion·metric·trace를 연결해 drift·release gate·영향 범위를 추적하는 RAG 관측 구조

오늘의 결론

  • Pipeline job이 성공했다고 RAG 데이터가 정상인 것은 아닙니다. 성공한 200 응답 안에서도 페이지가 사라지고, 표가 빈 문자열이 되고, ACL이 누락되며, 일부 embedding만 이전 model로 남을 수 있습니다.
  • Data quality는 null 비율 하나가 아닙니다. Source inventory 대비 coverage, parser 구조 보존, stable identity, metadata validity, ACL parity, temporal freshness, embedding compatibility와 serving visibility를 단계별 contract로 둡니다.
  • Lineage는 “어디서 왔는가”, quality assertion은 “기대와 맞는가”, observability는 “지금 어떤 상태인가”에 답합니다. 세 가지를 같은 run·dataset·generation ID로 연결합니다.
  • Drift는 자동으로 장애가 아닙니다. Source 문서 분포가 실제로 바뀐 것인지 parser·schema·model 변경이 원인인지 cohort와 lineage를 따라 진단합니다.
  • Release gate와 production probe를 함께 둡니다. Build 전에 blocking assertion을 통과하고, 배포 뒤에는 canary document·synthetic query로 end-to-end 검색 가능성을 계속 검증합니다.

앞 글에서는 새 index generation의 coverage·ACL·retrieval 품질을 비교한 뒤 전환했습니다. 이번 글은 그 gate를 일회성 migration checklist가 아니라 상시 관측 시스템으로 만듭니다.

source inventory
  → parse and structure
  → identity and metadata
  → chunk and embedding
  → sparse/vector index
  → retrieval and citation

each stage emits:
  lineage + quality assertions + metrics/traces + immutable samples

원천부터 retrieval까지 각 dataset과 job run을 lineage로 연결하고 completeness, parser, metadata, ACL, embedding, index 품질 assertion 및 metric·trace·synthetic probe로 drift와 영향 범위를 찾는 구조

먼저 답하기: 왜 error rate가 0인데 검색 품질이 망가질 수 있는가?

다음 작업은 모두 exit code 0일 수 있습니다.

  • PDF parser가 100페이지 중 82페이지만 반환
  • Table detector가 표를 image로 분류하고 text를 빈 값으로 저장
  • Source owner field rename으로 metadata가 전부 unknown
  • ACL field mapping 누락으로 document가 quarantine되지 않고 public projection
  • Embedding API가 요청 수만큼 vector를 반환했지만 일부 norm이 0
  • Index writer가 성공했지만 active alias는 이전 generation을 계속 가리킴

Transport 성공과 semantic correctness는 다릅니다. 품질 assertion이 output 의미를 확인해야 합니다.

이 글의 대상과 학습 시간

  • 대상: RAG ingestion과 retrieval을 운영하는 초·중급 개발자, data·ML platform 담당자
  • 선수 지식: pipeline stage, metadata, ACL, embedding index와 기본 metric
  • 빠르게 읽기: 약 12분
  • 관측 모델까지 이해하기: 약 35분
  • dashboard·probe 구축 포함: 약 2시간 이상

1. Quality, reliability, relevance를 구분한다

Data quality

Data가 정의된 contract와 source truth를 얼마나 만족하는지 봅니다.

  • Completeness
  • Validity
  • Accuracy
  • Consistency
  • Uniqueness
  • Timeliness
  • Integrity

Pipeline reliability

Job이 예측 가능하게 실행되는지 봅니다.

  • Success rate
  • Retry·timeout
  • Throughput
  • Queue lag
  • Resource saturation

Retrieval relevance

사용자 query에 관련 문서를 찾는지 봅니다.

  • Recall@k
  • MRR·nDCG
  • Citation correctness
  • Answer groundedness

Pipeline reliability가 좋아도 data quality가 나쁠 수 있고, data quality가 좋아도 embedding·ranking이 query intent와 맞지 않아 relevance가 낮을 수 있습니다.

2. Data quality dimension을 RAG 의미로 번역한다

Dimension일반 의미RAG 예
Completeness필요한 값이 존재Source 10,000문서 중 active index 9,980
ValiditySchema·domain 규칙 만족publish_at ISO timestamp, dimension 1024
Accuracy실제 사실과 일치Page 7 표 cell이 원문과 일치
Consistency표현 간 모순 없음Document ACL과 모든 chunk ACL 동일
Uniqueness중복 identity 없음같은 source version이 active 두 개 아님
Timeliness허용 지연 안에 반영Revoke가 SLO 내 검색에서 사라짐
Integrity관계 참조가 유효Chunk의 document·span·entity ID 존재

각 dimension을 하나의 global score로 합치면 원인을 숨깁니다. Stage와 cohort별 metric을 별도로 유지합니다.

3. Stage마다 input·output contract를 둔다

Source inventory

  • Resource ID 수
  • Active·deleted·restricted 상태
  • Source revision·ETag
  • File type·size·page count
  • ACL revision

Parse output

  • Source resource·version 참조
  • Extracted page count
  • Block type distribution
  • Text character·token count
  • Table row·cell·bbox coverage
  • OCR confidence와 language
  • Parser warning·fallback

Canonical document

  • Stable ID와 version uniqueness
  • Content hash
  • Source span validity
  • Metadata schema·vocabulary validity
  • Entity assertion provenance
  • ACL snapshot·valid time

Chunk output

  • Parent document 존재
  • Span이 source range 안에 있음
  • Empty·oversized chunk 비율
  • Overlap·boundary rule
  • Table/header context preservation
  • Chunk count per document

Embedding output

  • Expected dimension
  • Model·revision·prefix·normalization
  • Finite values
  • Norm distribution
  • One vector per eligible chunk
  • No mixed generation

Search index

  • Canonical expected ID coverage
  • Active version only
  • Deleted·unauthorized visibility 0
  • Sparse/vector field parity
  • Alias generation
  • Query probe success

4. Quality assertion을 executable contract로 만든다

문서에만 적힌 규칙은 배포를 막지 못합니다.

assertions:
  - id: source_to_canonical_coverage
    scope: tenant,file_type
    measure: canonical_active / source_active
    severity: blocking

  - id: chunk_parent_integrity
    scope: generation
    measure: orphan_chunk_count
    expected: 0
    severity: blocking

  - id: embedding_dimension
    scope: embedding_revision
    measure: invalid_dimension_count
    expected: 0
    severity: blocking

  - id: parser_empty_text_rate
    scope: parser_revision,file_type
    measure: empty_text_documents / eligible_documents
    severity: warn_or_block_by_cohort

Threshold를 임의의 “95%면 통과”로 두지 않습니다. Security·referential integrity는 0 mismatch가 필요할 수 있고 OCR confidence는 source cohort별 분포로 봐야 합니다.

5. Assertion 결과 자체를 versioned data로 저장한다

{
  "assertion_id": "chunk_parent_integrity",
  "assertion_revision": "qa-17",
  "run_id": "run-82f1",
  "dataset": "canonical_chunks/generation-g2",
  "evaluated_at": "2026-07-16T04:00:00Z",
  "scope": {"tenant": "fab-a", "file_type": "pdf"},
  "observed": 0,
  "expected": 0,
  "status": "pass",
  "sample_refs": [],
  "source_snapshot_id": "kb-snap-8842"
}

결과에 rule revision과 dataset generation이 없으면 어제와 오늘의 pass를 비교할 수 없습니다.

6. Lineage는 artifact와 run의 연결 그래프다

source:DMS@rev9811
  → job:parse@code_sha
  → dataset:parsed_blocks@snapshot8842
  → job:chunk@chunker4
  → dataset:chunks@g2
  → job:embed@model7
  → dataset:vectors@g2
  → job:index@index_config9
  → dataset:search_index@g2

OpenLineage object model은 Job, Run과 Dataset을 중심으로 input·output 관계를 표현하고, schema·version·data quality metrics와 assertions 같은 facet을 붙일 수 있게 합니다. 반드시 OpenLineage를 사용해야 한다는 뜻은 아니지만 다음 ID를 연결하는 모델은 필요합니다.

  • Job definition과 code revision
  • Run instance
  • Input dataset·snapshot
  • Output dataset·generation
  • Schema·model·parser facet
  • Quality metric·assertion
  • Parent run과 retry

7. RAG 전용 lineage facet을 작게 설계한다

표준에 없는 세부 정보를 custom facet 또는 내부 schema로 추가할 수 있습니다.

{
  "rag_embedding": {
    "_schemaURL": "https://example.invalid/schema/rag-embedding-v2.json",
    "model_revision": "embed-ko-v7",
    "dimension": 1024,
    "normalize": "l2",
    "document_prefix_hash": "sha256:..."
  },
  "rag_chunking": {
    "_schemaURL": "https://example.invalid/schema/rag-chunk-v4.json",
    "algorithm": "layout-semantic-v4",
    "max_tokens": 420
  }
}

OpenLineage 문서는 custom facet name collision을 피하고, immutable version을 가리키는 _schemaURL을 사용하도록 설명합니다. Branch main처럼 바뀌는 URL 대신 tag·commit 기반 schema를 둡니다.

Facet에 raw content, secret, query 원문을 넣지 않습니다.

8. Metrics, traces, logs의 역할을 나눈다

Metrics: 전체 상태와 추세

  • Document processed count
  • Failure·quarantine count
  • Stage duration histogram
  • Queue age
  • Coverage ratio
  • Empty extraction rate
  • Embedding norm quantiles
  • ACL mismatch count
  • Freshness lag histogram

Traces: 한 run·document의 경로

ingestion.run
  ├─ source.fetch
  ├─ parse.document
  ├─ normalize.metadata
  ├─ resolve.acl
  ├─ chunk.document
  ├─ embed.batch
  └─ index.upsert

Logs: 이산 event와 오류 상세

  • Unsupported encryption
  • Schema violation
  • Retry exhaustion
  • Quarantine reason
  • Alias cutover
  • Assertion failure sample ref

OpenTelemetry는 trace, metric과 log가 공통 resource·attribute convention으로 상관될 수 있는 표준을 제공합니다. 모든 RAG attribute가 안정 표준이라는 뜻은 아니므로 현재 semantic convention status를 확인하고 내부 prefix를 사용합니다.

9. Cardinality 폭발을 막는다

Prometheus류 metric label에 다음을 넣으면 위험합니다.

  • document_id
  • query_text
  • chunk_id
  • error_message
  • source_url
  • principal_id

Series 수가 급증하고 민감 정보가 노출됩니다.

Metric label은 제한된 cardinality를 사용합니다.

tenant_tier
source_type
file_type
parser_revision
pipeline_stage
error_class
generation
status

Document ID는 sampled trace나 protected diagnostic store에 둡니다. Metric에서 trace exemplar 또는 run ID로 drill-down할 수 있게 합니다.

10. Baseline을 global 평균이 아닌 cohort로 만든다

PDF와 HTML의 text length 분포는 다릅니다. Scanned PDF와 native PDF도 다릅니다.

cohort = tenant × source × file_type × language × parser_revision

필요하면 document class·page band·OCR 여부를 추가합니다. 너무 세분화해 sample이 작아지지 않도록 최소 sample과 hierarchical fallback을 둡니다.

Baseline 종류:

  • Previous stable generation
  • Rolling 28-day distribution [예시값]
  • Golden corpus
  • Source-provided expected inventory
  • Contract hard range

Seasonal 변화가 있으면 같은 요일·월말 batch와 비교합니다.

11. Parser drift를 출력 구조로 감지한다

Parser가 error 없이 품질을 잃는 신호:

  • Pages extracted / source pages 감소
  • Characters per page 급감
  • Empty page ratio 증가
  • Table count·cell count 변화
  • Heading hierarchy depth 변화
  • Image-only fallback 증가
  • OCR confidence 분포 변화
  • Reading-order inversion probe 실패
  • Bounding box outside page count

Ratio만 보지 않는다

Source 문서 자체가 이미지 중심으로 바뀌었을 수 있습니다. Source MIME, page render sample, parser revision과 cohort를 함께 봅니다.

Golden document probe

Layout이 어려운 대표 문서를 고정합니다.

{
  "document": "golden/table-merged-cells-v3.pdf",
  "expected": {
    "pages": 8,
    "tables": 4,
    "key_cells": ["E204", "45 s", "chamber pressure"],
    "heading_path": ["3. Recovery", "3.2 Etcher"]
  }
}

Parser build마다 exact·semantic assertions을 실행합니다.

12. Metadata drift를 schema와 의미로 나눈다

Schema drift

  • Field 추가·삭제·rename
  • Type 변경
  • Cardinality 변경
  • Enum 밖의 값
  • Timestamp precision 변경

Semantic drift

  • owner가 사람에서 조직으로 의미 변경
  • updated_at이 business update에서 sync time으로 변경
  • status=active가 승인 상태가 아닌 존재 상태로 사용
  • Equipment label taxonomy가 merge·split

Schema validator는 의미 변경을 자동으로 알기 어렵습니다. Source owner의 contract revision과 distribution change를 함께 봅니다.

추천 metric:

  • Missing required field
  • Unknown enum·concept rate
  • Entity link abstain·wrong-link sample
  • Source method mix
  • Metadata conflict count
  • Field freshness age
  • Vocabulary revision coverage

13. ACL quality는 별도 security assertion이다

ACL 누락을 일반 metadata completeness warning으로 처리하지 않습니다.

Blocking assertions:

tenant_id missing = 0
active chunk without ACL decision = 0
document-chunk ACL hash mismatch = 0
cross-tenant synthetic retrieval = 0
revoked marker retrieval = 0

ACL source와 index projection의 revision lag도 봅니다. 값이 unknown이면 public으로 처리하지 않고 quarantine 또는 deny합니다.

14. Chunk quality를 길이만으로 판단하지 않는다

Structural

  • Parent·version·span reference integrity
  • Heading context 존재
  • Table row/header 결합
  • Page boundary 보존
  • Overlap과 duplicate span

Size distribution

  • Tokens per chunk quantiles
  • Empty·tiny·oversized rate
  • Chunks per document
  • Truncation count

Information density

  • Boilerplate ratio
  • Repeated header/footer
  • Unique token ratio
  • OCR noise pattern

Tiny chunk가 항상 나쁜 것은 아닙니다. Alarm code, 표 cell, 제목처럼 짧지만 중요한 단위가 있습니다. Document type cohort와 retrieval 평가로 연결합니다.

15. Embedding quality를 shape와 distribution으로 본다

Hard validation

def validate_vector(v, expected_dim):
    assert len(v) == expected_dim
    assert all(isfinite(x) for x in v)
    assert norm(v) > 0

Distribution telemetry

  • Vector norm p1·p50·p99
  • Zero·NaN·Inf count
  • Dimension mismatch count
  • Batch size와 latency
  • Model revision mix
  • Centroid·covariance sketch 변화
  • Pairwise cosine sample distribution
  • Nearest-neighbor score distribution

해석 주의

새 model에서 norm과 score가 바뀌는 것은 정상일 수 있습니다. Model revision을 섞어 baseline하지 않고 generation별로 봅니다.

Embedding drift를 relevance regression의 증거로 단정하지 않습니다. Gold query retrieval과 함께 조사하는 trigger입니다.

16. Index quality는 write success보다 넓다

확인할 항목:

  • Canonical expected document·chunk coverage
  • Orphan·duplicate ID
  • Active version uniqueness
  • Deleted resource visibility
  • ACL·temporal field parity
  • Sparse/vector pair completeness
  • Shard·replica health
  • Refresh and merge lag
  • Active alias generation
  • Query encoder/index compatibility

Count parity의 함정

Expected 100, actual 100이어도 1개 missing과 1개 duplicate가 상쇄될 수 있습니다. ID set diff와 hash sample을 함께 봅니다.

missing = expected_ids - indexed_ids
extra = indexed_ids - expected_ids
mismatched = ids where projection_hash differs

17. Retrieval drift를 query cohort로 감시한다

Labeled gold set은 주기적으로 실행합니다.

  • Recall@k
  • MRR·nDCG
  • Filtered Recall@k
  • Citation source-span match
  • Empty result rate
  • Score margin
  • Result diversity

Production query는 label이 없으므로 proxy를 봅니다.

  • Reformulation rate
  • Citation click·open failure
  • User abstention acceptance
  • No-answer rate
  • Repeated query within session
  • Retrieval result overlap across generation

Proxy는 사용자 만족의 직접 진실이 아닙니다. Privacy와 confounding을 고려해 diagnostic signal로만 사용합니다.

18. Drift taxonomy를 원인별로 나눈다

Input drift

새 source, file type, language와 document 길이 변화

Schema drift

Field, type와 enum change

Processing drift

Parser·OCR·chunker code나 dependency change

Representation drift

Embedding model, prefix, normalization, vector distribution change

Index drift

Coverage, ANN setting, shard와 alias change

Query drift

사용자 intent, language, entity와 시간 범위 변화

Label drift

Gold relevance나 authority 문서가 시간에 따라 바뀜

Drift alert에 바로 rollback하지 말고 lineage revision과 source cohort를 확인합니다.

19. Synthetic probe로 end-to-end를 확인한다

각 tenant·ACL·document type에 유일 marker를 가진 canary document를 둡니다.

CANARY_FABA_PUBLIC_7Q9
CANARY_FABA_ETCH_2K4
CANARY_FABB_PUBLIC_8M3
CANARY_REVOKED_1X6

Probe 종류:

  • Exact lexical retrieval
  • Dense paraphrase retrieval
  • Metadata filter
  • Entity synonym
  • Temporal current/as-of
  • ACL allow/deny
  • Delete/tombstone
  • Citation source fetch

Probe 결과에는 generation, policy, parser, embedding revision과 trace ID를 남깁니다. Canary content도 production 사용자에게 불필요하게 노출되지 않도록 별도 namespace·filter를 고려합니다.

20. Quality gate를 blocking·warning·diagnostic으로 나눈다

Blocking

  • Cross-tenant result
  • ACL missing·mismatch
  • Invalid embedding dimension
  • Orphan chunk
  • Deleted resource visible
  • Generation mismatch
  • Required source inventory coverage 미달

Warning

  • Parser empty page rate 증가
  • Unknown vocabulary 증가
  • Embedding norm shift
  • Chunk size distribution 변화
  • Freshness SLO burn

Diagnostic

  • Result overlap 변화
  • Source composition 변화
  • Non-critical optional field null
  • Experimental cohort metric

Warning이 누적되어 quality budget을 소진하면 release를 막을 수 있습니다. Severity와 owner를 사전에 정합니다.

21. Alert는 증상보다 행동에 연결한다

나쁜 alert:

embedding_norm_mean changed 12%

좋은 alert:

generation g2 / parser 3.2 / scanned-pdf cohort
empty-page ratio exceeded baseline for 20 minutes
first bad run: run-82f1
affected documents: 1,842
downstream: chunks-g2 → vectors-g2 → index-g2
golden parser probe: failed key cell E204
action: pause activation, quarantine new cohort, inspect samples

Alert에 run, lineage impact, sample reference, owner와 runbook을 포함합니다.

22. Lineage로 blast radius를 계산한다

Parser version에 bug가 발견되면 질문은 “어떤 job이 실패했나”가 아닙니다.

parser-3.2 bad window
  → affected parsed datasets
  → affected document versions
  → affected chunks and vectors
  → affected index generations
  → active / inactive serving status
  → cached answers and evaluations

재처리 범위도 이 graph에서 계산합니다. 전체 corpus reindex가 아니라 affected input snapshot과 downstream artifact만 invalidation할 수 있습니다.

23. Incident workflow를 고정한다

Detect

Assertion, drift alert, synthetic probe 또는 사용자 report

Contain

  • Candidate activation 중단
  • Bad source cohort quarantine
  • Active alias rollback
  • Security issue는 emergency deny
  • Cache invalidation

Diagnose

  • First bad run
  • Code·schema·model revision diff
  • Input cohort change
  • Failed sample and source comparison
  • Downstream lineage impact

Repair

  • Fix and new immutable pipeline revision
  • Affected dataset replay
  • Quality gate rerun
  • Index candidate rebuild

Verify

  • Source parity
  • Golden corpus
  • Synthetic retrieval
  • Cohort quality
  • No residual cache

Learn

Missing assertion, delayed alert와 runbook gap을 보완합니다.

24. 가상 반도체 RAG 예시

다음은 설명을 위한 가상 예시입니다.

증상

Pipeline success rate 100%, search latency 정상인데 “E204 압력 기준” query의 citation이 줄었습니다.

관측

  • Native PDF cohort 정상
  • Scanned PDF cohort의 table_cells_per_page p50 급감
  • Parser revision은 동일하지만 OCR runtime image digest가 바뀜
  • Golden merged-cell document에서 45 s key cell 누락
  • Affected run output이 G3 candidate에만 있음

Lineage 진단

ocr-image@digest-new
  → parse runs 1021..1088
  → scanned-pdf parsed blocks
  → chunks G3
  → vectors G3
  → candidate index G3

대응

  1. G3 activation을 중단합니다.
  2. New OCR digest를 rollback합니다.
  3. Affected 1,842개 문서만 replay합니다. [가상 수치]
  4. Page·table assertion과 golden key cell을 통과시킵니다.
  5. table-query cohort Recall@20과 citation span을 재검증합니다.

Error rate만 봤다면 발견하기 어려운 silent semantic failure입니다.

25. 구현 순서

1단계. Critical data path 지도

Source inventory부터 serving index와 citation까지 dataset·job·owner를 적습니다.

2단계. Hard contracts

Identity, ACL, schema, dimension, referential integrity와 deletion invariant를 executable assertion으로 만듭니다.

3단계. Stage metrics

Count, ratio, lag와 distribution을 cohort·revision별로 수집합니다.

4단계. Run·dataset lineage

Input snapshot, code SHA, parser·model revision, output generation과 assertion result를 연결합니다.

5단계. Golden corpus와 synthetic probe

Parser structure와 end-to-end retrieval을 정기 실행합니다.

6단계. Baseline과 drift

Stable generation·rolling window·source inventory 기준을 cohort별로 만듭니다.

7단계. Release gate

Blocking·warning·diagnostic rule, owner와 exception 만료를 정의합니다.

8단계. Incident runbook

First bad run, blast radius, quarantine, replay와 verification 경로를 rehearsal합니다.

실전 체크리스트

  • Data quality, pipeline reliability와 retrieval relevance metric을 분리한다.
  • Completeness·validity·accuracy·consistency·uniqueness·timeliness·integrity를 RAG 의미로 정의했다.
  • Source inventory가 expected denominator를 제공한다.
  • 각 stage에 input·output contract가 있다.
  • Quality assertion이 code로 실행되고 revisioned 결과를 남긴다.
  • Run, job, input/output dataset과 code·model revision이 lineage로 연결된다.
  • Custom lineage schema가 immutable version URL을 가진다.
  • Metric·trace·log의 역할이 구분돼 있다.
  • Metric label에 document ID·query 원문 같은 high cardinality·민감 값을 넣지 않는다.
  • Baseline이 file type·language·parser revision cohort별이다.
  • Golden parser document가 page·table·reading order를 검증한다.
  • Metadata schema drift와 semantic drift를 구분한다.
  • ACL missing·mismatch는 blocking security assertion이다.
  • Chunk parent·span integrity와 table/header context를 본다.
  • Embedding dimension·finite·norm·revision mix를 확인한다.
  • Vector drift를 relevance regression으로 단정하지 않는다.
  • Index count뿐 아니라 ID set diff와 projection hash를 본다.
  • Retrieval metric을 query cohort별로 평가한다.
  • Synthetic probe가 lexical·dense·filter·temporal·ACL·delete·citation을 포함한다.
  • Gate가 blocking·warning·diagnostic으로 분류돼 있다.
  • Alert에 first bad run, impact graph, sample, owner와 action이 있다.
  • Lineage로 affected artifact와 replay 범위를 계산할 수 있다.
  • Incident containment와 repair verification을 rehearsal했다.

스스로 확인하기

Q1. 모든 document가 index에 있으면 completeness가 100%인가?

Document ID coverage만 100%일 수 있습니다. Page, table, chunk, ACL, embedding field와 active version coverage도 확인해야 합니다.

Q2. Drift가 감지되면 항상 rollback해야 하는가?

아닙니다. 실제 input 분포 변화나 의도한 model update일 수 있습니다. Lineage revision, cohort와 gold relevance를 확인해 harmful drift인지 판단합니다.

Q3. Trace를 모든 document에 저장하면 가장 좋은가?

비용과 민감 정보 위험이 큽니다. Aggregate metric, sampled trace, failure·canary full trace와 protected diagnostic store를 조합합니다.

Q4. Quality score 하나로 dashboard를 단순화할 수 있는가?

경영 요약에는 가능하지만 운영 판단을 대체하면 안 됩니다. Security mismatch 1건과 optional metadata null 1%를 같은 평균에 섞을 수 없습니다.

Q5. OpenLineage와 OpenTelemetry 중 하나만 선택해야 하는가?

아닙니다. Lineage는 dataset transformation과 영향 관계, telemetry는 runtime signal과 성능 관측에 강합니다. 공통 run·job·generation ID로 연결할 수 있습니다.

Q6. Production query label이 없는데 retrieval drift를 어떻게 아는가?

Gold query를 정기 실행하고, shadow overlap·empty result·reformulation 같은 proxy와 synthetic probe를 함께 봅니다. Proxy만으로 품질을 확정하지 않습니다.

마무리

RAG data observability의 목표는 dashboard를 많이 만드는 것이 아니라 silent partial failure를 사용자보다 먼저 발견하고 영향 범위와 복구 입력을 즉시 아는 것입니다.

stage contracts and assertions
  + run-to-dataset lineage
  + low-cardinality metrics and sampled traces
  + cohort baselines and golden probes
  + security-aware release gates
  + impact-driven incident repair
  = observable RAG knowledge pipeline

다음 글 RAG Deletion·Retention·Privacy Governance에서는 삭제 요청을 source, chunk, embedding, index, cache, snapshot과 backup까지 전파하고 legal hold·retention과 충돌하지 않게 증명하는 방법을 다룹니다.

참고문헌

검증 메모 — 공식 문서는 2026년 7월 16일 확인했습니다. OpenLineage와 OpenTelemetry의 spec·semantic convention status는 계속 변경될 수 있으므로 구현 version을 고정해야 합니다. 본문의 cohort, baseline window, 문서 수와 threshold는 가상 예시입니다. 실제 시스템에서는 raw source sample과 annotation policy를 정하고 parser·metadata·ACL·embedding·index·query cohort별 baseline을 구축한 뒤 schema change, partial output, mixed model, event loss와 alias 오류를 fault injection으로 검증해야 합니다.