How Old Is My Data?의 후속 글입니다.

기계가 데이터를 읽을 때 악화되는 실패 모드 (Failure Mode)

전형적인 대시보드에서 오래된(stale) 데이터는 인간의 문제입니다. 누군가가 6시간 전의 숫자를 보고 약간 잘못된 결정을 내리는 식이죠. 짜증은 나겠지만, 재앙적인 경우는 드뭅니다.

이제 동일한 데이터를 검색 증강 생성 (RAG, Retrieval-Augmented-Generation) 파이프라인이나 자율 에이전트 (Autonomous Agent)에게 넘겨준다고 가정해 봅시다. 판돈이 달라집니다. 시스템은 타임스탬프를 확인하며 제정신인지 점검하기 위해 멈추지 않고, 즉각 행동합니다. 그리고 시스템이 행동하는 데이터가 오래되었을 때, 다음 세 가지 현상이 동시에 발생합니다:

• 답변이 확신에 차서 틀립니다.
• 발생할 에러가 없습니다. 쿼리는 성공했고, 모델은 응답했으며, 지연 시간 (Latency)은 정상입니다.
• 대시보드의 다른 모든 신호는 초록색(정상)입니다.

이것은 관측 가능성 (Observability) 측면에서 최악의 조합입니다. 우리가 현재 내보내는 신호로는 완전히 보이지 않는 실제적인 실패가 발생하는 것입니다.

AI 시스템에서 데이터 신선도가 숨어 있는 곳

RAG: 인덱스 (Index) vs 코퍼스 (Corpus). 당신의 벡터 인덱스 (Vector Index)는 특정 시점의 코퍼스를 기반으로 구축되었습니다. 코퍼스는 계속 변합니다. 문서가 추가되고, 수정되고, 철회됩니다. 만약 재임베딩 (Re-embedding) 작업이 중단되거나 뒤처지면, 인덱스는 조용히 시대에 뒤떨어지게 됩니다. 검색기 (Retriever)는 여전히 그럴듯한 청크 (Chunks)를 반환하고, 모델은 여전히 유창한 답변을 작성합니다. 단지 더 이상 존재하지 않는 현실의 버전을 바탕으로 답변할 뿐입니다. 당신이 신경 써야 할 수치는 코퍼스나 인덱스 각각의 연령이 아니라, 소스 대비 인덱스의 상대적인 연령입니다.

피처 스토어 (Feature Stores): 온라인-오프라인 왜곡 (Online–offline skew). 모델이 학습할 때 사용한 피처 (Features)와 서비스할 때 사용하는 피처는 일치해야 합니다. 온라인 스토어가 오프라인 파이프라인보다 뒤처지게 되면, 예측 성능이 저하됩니다. 이는 모델 드리프트 (Model Drift)처럼 보일 수 있지만, 실제로는 데이터 신선도 (Data Staleness)가 변장을 하고 있는 것입니다.

에이전트(Agents): 오래된 공유 상태(stale shared state). 다중 에이전트 시스템은 공유 메모리(shared memory), 스크래치패드(scratchpads), 그리고 컨텍스트를 통해 조정됩니다. 다른 에이전트가 10단계 전에 업데이트한 상태에 대해 추론하는 에이전트는 — 하지만 실제로 전파되지 않은 — 국소적으로는 합리적이지만, 전체적으로는 잘못된 결정을 내립니다. 이것은 새롭거나 이국적인 문제가 아닙니다. 이는 정보의 시대(Age of Information) 이론이 실시간 제어 및 네트워크 시스템에서 분석하기 위해 발명된 바로 그 영역이며, 여기서 액추에이터가 오래된 센서 판독값에 따라 작동하는 것은 알려진 위험 요소입니다.

신선도(Freshness)는 오래된 개념이지만, 우리의 원격 측정(telemetry)에서 이것이 빠져 있다는 것이 새롭게 비용이 많이 드는 문제입니다.

이 모든 것은 새로운 지표가 아닙니다. 신선도 — 즉 가장 최근 업데이트가 소스에서 생성된 시간 — 는 네트워크 시스템 연구에서 정확한 이름으로 불립니다: 정보의 시대(Age of Information):

_
angle age = now − event_time(freshest record)

만약 어떤 소스가 생성을 멈추면, 다른 모든 신호가 건강하게 유지되는 동안 그 나이는 무한히 증가합니다. 데이터 가용성(Data-observability) 공급업체들은 이미 이것을 내부적으로 계산하고 있습니다. dbt source freshness는 dbt를 위해 이를 계산하고, Kafka-lag 도구들은 Kafka를 위해 이를 계산합니다.

부족한 것은 이를 방출하는 표준적이고 이식 가능한 방법입니다 —

AI 시스템을 위한 핵심 통찰은 차분(differential) 사례입니다: 인덱스가 구축된 기반이 되는 코퍼스(corpus) 대비 인덱스의 연령, 또는 프라이머리(primary) 대비 레플리카(replica)의 연령입니다. 단 하나의 숫자("인덱스가 소스보다 40분 뒤처져 있습니다")는 RAG 파이프라인에 꼭 필요하지만 거의 갖춰져 있지 않은 바로 그 알림(alert)입니다.

AI를 위해 가장 중요한 설계 규칙: 절대로 숫자를 조작하지 마십시오

전체 구현을 관통하는 하나의 원칙은 다음과 같습니다: 측정할 수 없는 신선도(freshness) 값은 반드시 가시화되어야 하며, 절대로 조작되어서는 안 됩니다. 빈 테이블, NULL MAX(), 타임아웃, 빈 파티션 등은 각각 특정 error.type을 가진 data.staleness.probe.errors로 나타나야 하며, 조작된 "0초 경과"와 같은 값으로 나타나서는 안 됩니다.

이는 AI에게 두 배로 중요합니다. 실제로 실패했음에도 불구하고 조용히 "신선함(fresh)"이라고 보고하는 신선도 체크는 아예 체크를 하지 않는 것보다 더 나쁩니다. 왜냐하면 RAG 인덱스나 에이전트 상태(agent state)가 가장 심각하게 망가졌을 때 당신을 안심시켜 버릴 것이기 때문입니다.

하나의 AI 워크로드에 적용해 보기

Python SDK — 인덱스와 그 소스에 차분 프로브(differential probe)를 지정하십시오:

bash

pip install data-staleness-otel

python

from otel_staleness import StalenessMonitor, conventions as sc
from otel_staleness.probes import SQLFreshnessProbe

...

Zero-code Collector — 애플리케이션 코드 없이 YAML만으로 SQL, Kafka, Kinesis, 파일, HTTP 및 스키마 레지스트리(schema registries)를 스크레이핑(scrape)하고, 동일한 백엔드로 동일한 data.staleness. extasteriskcentered 메트릭을 방출합니다.

참여하기

"내 모델이 답변하고 있는 데이터가 얼마나 오래되었는가?"라는 질문에 대해 맞춤형 쿼리(bespoke query)와 취약한 대시보드로 답변해야 했던 경험이 있다면, 여러분의 의견을 소중히 듣겠습니다:

해당 컨벤션 제안(convention proposal)은 OpenTelemetry Semantic Conventions 리포지토리(#3909)에서 공개되어 있습니다. 좋아요(thumbs-up), 댓글, 그리고 구체적인 AI 활용 사례(use cases)는 수요를 측정하는 데 진정으로 도움이 됩니다.

코드, 명세(spec), 모델 및 검증: https://github.com/anirudhrajreliability/otel-data-staleness (Apache-2.0).

직접 사용해 보시고(pip install data-staleness-otel), 어떤 부분에서 문제가 발생하는지 알려주세요.

우리가 지연 시간(latency)과 에러(errors)를 표준화한 이유는 기계가 추론을 위해 이식 가능한 신호(portable signals)를 필요로 했기 때문입니다. 데이터에 대해 추론하는 AI 시스템 역시 정확히 동일한 이유로 신선도(freshness)에 대한 이식 가능한 신호가 필요합니다. 이제 AI 시스템에게도 그 신호를 제공합시다.