MRM Thread MRM 스레드
MRM 스레드 MRM Thread
Model risk management for AI recommendation systems.
[MRM Thread] Ep 6 — Modular Adaptability: When Regulations Evolve, Architecture Doesn't
The early design temptation was a single ComplianceReporter class parametrised on jurisdiction. We rejected it after walking through what amendment-driven change would look like. The five separate generators, sitting on a regulation-agnostic substrate of audit log + XAI + retrieval, are the structural bet that pays off only when regulations actually start to move.
[MRM 스레드] 에피소드 6 — Modular Adaptability · 규제는 변해도 아키텍처는 변하지 않는다
한국 AI 기본법 시행령, EU AI Act 개정안, 미래의 미국 규제 프레임워크 — 이 모든 변화는 언젠가 현실이 될 것이다. 5개의 규제 산출물 생성기는 동일한 감사 로그 기반 위에서 동작하는 5개의 독립된 모듈이지, 매번 새로 작성해야 하는 5개의 문서가 아니다. 아키텍처의 모듈성이 왜 앞선 다섯 에피소드의 논의를 비로소 의미 있게 만드는 장기적인 베팅인지 살펴본다.
[MRM Thread] Ep 5 — RAG + LanceDB: Why Audit Infrastructure Is a Retrieval Problem
We started with the idea that the audit log was a write-only archive. The first time a risk officer needed similar-case context inside a five-minute decision window, that idea broke. RAG over LanceDB is what came out of refusing to maintain two copies of the same source of truth — and what unlocked human oversight, fairness monitoring, and quarterly aggregation as queries on the same store.
[MRM 스레드] 에피소드 5 — RAG + LanceDB · 감사 인프라가 결국 검색 문제인 이유
감사 로그는 단순한 쓰기 전용 데이터가 아니다. 질의 가능한 지식 베이스다. 운영 및 감사 검색 인프라를 컬럼형, 버전 인식, 시간 여행 기능이 결합된 RAG와 LanceDB로 구성한 이유를 설명한다. 그리고 그 결과로 인적 감독, 운영 파이프라인 위에서의 공정성 모니터링, 분기별 집계 문제가 어떻게 해결되는지 살펴본다.
[MRM Thread] Ep 4 — When Explanation Is Architecture: Inherent XAI and FD-TVS Scoring
Post-hoc XAI (SHAP, LIME) wobbled on us when we ran the cost and stability numbers. We chose architectural XAI instead — the gate weights of seven heterogeneous PLE experts as the explanation, with CEH attribution and Mahalanobis OOD as the second and third layers. FD-TVS is the operational scoring philosophy that grew out of fixing the on-prem per-product weights model.
[MRM 스레드] 에피소드 4 — 설명이 아키텍처가 될 때: 내재적 XAI와 FD-TVS 스코어링
사후적 XAI(SHAP·LIME)는 운영 환경에서 불안정하며 모델과도 분리되어 있다. 우리는 PLE의 7개 이종 전문가 모델 위에서 게이트 가중치 자체를 설명으로 활용하는 방식을 택했다. 추론 경로의 자연스러운 결과물로 매 예측의 근거를 확보하는 구조다. FD-TVS는 그 위에 얹어진 운영 스코어링 철학이다.
[MRM Thread] Ep 3 — Auditing the Auditors: Chain of Custody and Consensus Arbitration
Seven audit tables and an HMAC hash chain give you 'continuity of record'. But who verifies the record? The trap of the single-LLM auditor, multi-agent consensus with α/β/γ perspectives, a minority-report-that-never-gets-deleted design, and why AWS parallel voting and on-prem 2-round deliberation chose different paths.
[MRM 스레드] 에피소드 3 — 감사의 감사자들: Chain of Custody와 컨센서스 중재
7개 감사 테이블과 HMAC 해시 체인이 '기록의 연속성'을 보장한다면, 그 기록을 누가 검증하는가. 단일 LLM 판정의 함정과 다중 에이전트 컨센서스(α·β·γ) 구조, 소수 의견을 지우지 않는 설계, 그리고 AWS 병렬 투표와 온프렘 2-Round 심의가 서로 다른 방식을 택한 이유.
[MRM Thread] Ep 2 — Champion-Challenger as a Gate
A Monday-3am walkthrough of `_decide_promotion()` — the 4-step short-circuit ladder (force-promote, bootstrap, fidelity floor, competition) that replaces a 2-to-4-week MRM committee cycle with seconds, and every outcome writes one HMAC-signed audit entry.
[MRM 스레드] 에피소드 2 — 관문으로서의 Champion-Challenger
월요일 새벽 3시 `_decide_promotion()` 안에서 일어나는 일 — 4단계 단락 평가 사다리(force-promote · bootstrap · fidelity floor · competition)가 2-4주짜리 MRM 위원회 주기를 수초로 대체하고, 모든 판정이 HMAC 서명 감사 엔트리를 남긴다.
[MRM 스레드] 에피소드 1 — MRM 은 검증이 아니라 아키텍처에 속한다
검증 우선의 MRM 체계는 모델이 LLM 에이전트 파이프라인으로 전환될 때 한계를 가진다. 다단계 실패 모드와 검증 주기 내 드리프트 등의 문제를 해결하기 위해, MRM 의무를 사후 검토 캘린더가 아니라 아키텍처 자체에 반영해야 하는 이유를 설명한다.
[MRM Thread] Ep 1 — Why MRM Belongs in the Architecture
The validation-first view of Model Risk Management breaks once the model becomes an LLM agent pipeline — multi-step attack surface, non-traditional failure modes, drift between validation cycles. Push MRM into the architecture itself, not the review calendar.