RAG와 평가

Retrieval-Augmented Generation(RAG, 검색 증강 생성)의 핵심은 모델 가중치 안의 parametric memory와 외부 index의 non-parametric memory를 결합하는 데 있습니다. 원 RAG 논문은 검색된 passage와 생성 모델을 함께 다루며 지식 갱신과 provenance 문제를 출발점으로 삼습니다. 그러나 논문의 특정 Wikipedia·dense retriever 실험 결과가 모든 사내 문서에 그대로 재현된다는 뜻은 아닙니다. 실제 제품에서는 어떤 사용자의 어떤 질문을 어느 원문으로 답할지 업무 계약부터 고정해야 합니다.

첫 문서는 기능 목록이 아니라 질문·증거 계약입니다. 대표 질문, 경계 질문, 답을 거부해야 하는 질문마다 정답 문자열만 적지 말고 필요한 source document ID, 유효 revision, 절·표·행 범위와 허용되는 무응답을 기록합니다. “답이 자연스러운가”만 보면 모델이 원문 없이 맞힌 경우와 틀린 문서를 근거로 그럴듯하게 답한 경우를 구분할 수 없습니다. 검색 정답과 생성 정답을 함께 갖춘 평가 묶음이 있어야 어느 단계가 고장 났는지 설명할 수 있습니다.

원문 intake에는 소유자, 수집 경로, content hash, 문서 revision·시행일·만료일, 언어, 보안 등급, tenant·group ACL, 재사용 권리와 삭제 책임자를 둡니다. PDF 파일명 하나만 남기면 같은 이름의 개정본이 들어왔을 때 어느 답이 어느 byte를 근거로 했는지 복원할 수 없습니다. Parser·OCR·table extractor와 embedding model revision, chunk recipe도 derived artifact이므로 source hash에서 index generation까지 manifest로 연결합니다.

RAG는 최신 사실에 특히 유용하지만 source system보다 더 최신일 수는 없습니다. 문서가 승인된 시각, connector가 읽은 시각, index가 publish된 시각과 query가 실행된 시각을 구분하고 freshness service-level objective를 둡니다. “매시간 동기화”라는 계획 대신 승인 후 30분 안에 새 revision이 검색되고, 철회 후 10분 안에 old chunk가 어떤 query에도 나오지 않는다는 검증 가능한 목표를 둡니다.

반대로 안정된 문체·출력 행동이나 원문 없이 반복해야 하는 분류 규칙은 fine-tuning 또는 deterministic code가 더 적합할 수 있습니다. RAG는 검색 latency·index 운영·권한·인용 검증 비용을 추가합니다. 질문이 외부 지식을 필요로 하는지, source를 인용해야 하는지, 변경 빈도와 허용 지연이 무엇인지를 비교해 RAG를 선택하며 단순한 FAQ 열 건을 위해 복잡한 vector infrastructure를 먼저 만들지 않습니다.

Ingestion은 file upload 성공으로 끝나지 않습니다. PDF의 text layer, scan image의 OCR, HTML의 navigation·cookie banner, spreadsheet의 merged cell과 slide의 reading order는 서로 다른 parser가 필요합니다. Header와 footer가 모든 page에 반복되면 embedding similarity를 오염시키고, OCR이 숫자 0과 영문 O를 바꾸면 정확한 제품 code를 잃습니다. 원문별 representative fixture를 만들어 page·표·각주·링크·제목 순서가 보존되는지 parser revision마다 회귀 시험합니다.

Chunk 크기에 보편적인 정답은 없습니다. 너무 짧으면 “누가 해당하는가”와 “무엇을 해야 하는가”가 갈라지고, 너무 길면 여러 정책이 한 vector에 섞여 관련 없는 문장까지 context를 차지합니다. 먼저 문서의 제목 계층, 문단, 목록과 표 경계를 후보로 사용하고 목표 tokenizer의 실제 token 수로 상한을 확인합니다. Fixed 500자와 20% overlap 같은 숫자를 관습으로 고정하지 않고 작은·중간·큰 recipe를 동일 question set의 recall·precision·citation span과 latency로 비교합니다.

Overlap은 경계 문장을 두 후보에 남기지만 index 크기와 중복 검색을 늘립니다. 같은 문장이 여러 chunk에서 상위에 올라오면 context 다양성이 줄고 서로 다른 문서처럼 중복 인용될 수 있습니다. Parent section ID와 character·page span을 두고 near-duplicate를 합치거나 같은 parent의 후보 수를 제한합니다. 반대로 표 header를 매 row에 복제하는 것은 의미를 보존하기 위한 의도적 중복일 수 있으므로 단순 hash dedup으로 제거하지 않습니다.

각 chunk에는 chunk ID, source ID·revision·hash, parent section, 원문 위치, title path, created/valid/expired time, language, tenant와 ACL, parser·chunk recipe, embedding revision을 붙입니다. 표시용 citation label과 권한 판정 field를 모델이 자유롭게 생성하게 하지 않습니다. Application은 검색 결과의 trusted metadata로 citation object를 만들고 답변 문장의 claim이 실제 chunk span에 의해 지지되는지를 별도 판정합니다.

갱신은 upsert만이 아니라 old revision 철회를 포함합니다. 새 index generation을 별도 namespace에 완성하고 count·hash·정답 질문·권한 fixture를 통과한 뒤 alias를 atomic하게 이동합니다. 삭제 요청은 source store, parsed text, chunk·dense/sparse index, reranker cache, prompt/output log와 backup retention에 어떻게 전파되는지 목록화합니다. Tombstone과 generation manifest로 빠진 old ID가 0인지 질의하고, failed publish에서는 previous index alias로 되돌아갈 수 있어야 합니다.

Dense Passage Retrieval(DPR) 원 논문은 질문과 passage를 dual encoder로 표현해 dense retrieval을 구현하고 특정 open-domain QA 평가에서 강한 결과를 보였습니다. 하지만 이 결과를 “vector 검색이 항상 BM25보다 낫다”로 일반화하면 안 됩니다. BEIR는 다양한 도메인에서 BM25가 견고한 baseline이고 reranking이 평균적으로 강하지만 계산 비용이 크며 dense·sparse 방식의 out-of-domain 성능이 다양함을 보여 줍니다. 따라서 내 한국어 약어·제품 code·문서 분포에서 직접 비교합니다.

Lexical 검색은 query token과 문서 token의 exact·통계적 일치를 활용해 버전 번호, 사람 이름과 오류 code에 강할 수 있습니다. Dense 검색은 표현이 달라도 의미가 가까운 질문을 찾는 데 도움을 줍니다. Hybrid 검색은 두 결과를 결합하며 Elastic 공식 문서는 full-text와 vector 결과를 Reciprocal Rank Fusion(RRF)으로 합치는 흐름을 제공합니다. RRF는 서로 다른 score scale을 직접 더하지 않고 각 결과의 rank를 사용하지만, window·k와 child retriever 구성은 여전히 평가해야 합니다.

Embedding model을 선택할 때 공개 leaderboard 한 숫자만 보지 않습니다. Korean·English 혼합, 문서와 query의 최대 token, pooling·normalization, query/document prefix, vector dimension, license와 runtime을 manifest에 고정합니다. Model이나 normalization을 바꾸면 old vector와 new query vector를 섞지 않고 새 index generation을 만듭니다. 동일 문장의 vector가 생성됐다는 이유만으로 의미·권한·민감도가 암호화되거나 익명화된 것도 아닙니다.

권한은 검색 후 answer에서 숨기는 장식이 아닙니다. User identity를 server가 검증해 tenant·group·document policy로 변환하고, 이 filter가 lexical, dense, hybrid의 모든 child retrieval과 reranking candidate에 적용되도록 합니다. Qdrant 공식 문서는 payload와 ID 조건을 query에 결합하고 자주 쓰는 field에 payload index를 만들 수 있음을 설명합니다. 특정 제품의 기능이 보안 정책 그 자체를 대신하는 것은 아니므로 fail-open, missing ACL, type mismatch와 filter propagation을 통합 시험합니다.

Approximate nearest-neighbor search는 속도를 위해 정확한 전수 비교와 다른 후보를 반환할 수 있습니다. Filter가 매우 제한적일 때 허용 문서가 충분히 탐색되는지, shard와 replica·index parameter가 recall과 p95에 미치는지를 권한 group별로 측정합니다. Unauthorized document를 먼저 넓게 검색한 뒤 application에서 지우면 timing·trace·cache·reranker로 내용이 흘러갈 수 있으므로, 허용 집합 밖의 text·vector·metadata가 downstream에 도달하지 않는 경계를 관측합니다.

First-stage retrieval은 빠르게 후보를 넓게 찾고 reranker는 query와 candidate를 함께 읽어 더 비싼 관련도 판단을 합니다. Candidate 100개를 무조건 rerank하면 latency와 비용이 커지고, 3개만 넘기면 필요한 문서를 놓칠 수 있습니다. Recall 목표를 만족하는 retrieval window를 먼저 찾고 rerank의 nDCG·MRR 또는 critical question의 top rank 개선과 p95를 비교합니다. Reranker revision·입력 truncation도 index와 별도로 고정합니다.

Context packing은 점수 순서로 text를 붙이는 단순 작업이 아닙니다. 같은 parent의 중복 chunk를 합치고 질문을 답하는 최소 span, 제목·표 header와 적용 조건을 함께 보존합니다. 서로 다른 revision이 충돌하면 최신 날짜만 보고 고르지 말고 유효 기간·승인 상태·업무 관할을 판정합니다. Token 예산에는 system instruction, user question, citation schema와 output reserve를 먼저 확보하고 남은 범위에 evidence를 넣습니다.

검색 문서는 외부 입력입니다. OWASP LLM01은 external file·web content에 숨은 indirect prompt injection이 모델 행동을 바꿀 수 있고 RAG가 이를 완전히 막지 못한다고 설명합니다. NIST adversarial ML taxonomy도 RAG에서 data와 instruction channel이 섞이는 공격 표면을 다룹니다. Retrieved text를 명확한 data delimiter와 source identity로 구분하고, document 안의 명령을 따르지 않도록 하되 prompt 문구 하나를 완전한 방어로 간주하지 않습니다.

모델에는 downstream write·email·payment 권한을 주지 않거나 최소 권한 tool만 제공하고, 근거 답변과 행동 실행을 분리합니다. Retrieved text가 tool argument·URL·code로 이어지면 deterministic allowlist, schema와 policy engine이 다시 검증하고 중요한 행동은 사람이 승인합니다. Poisoned document, 숨은 text, conflicting source와 citation-looking string을 red-team fixture로 넣어 data가 instruction으로 승격되는 경로와 비밀 유출을 시험합니다.

Citation은 `[1]`을 출력했다고 완성되지 않습니다. Application이 검색 결과의 immutable source ID·revision·span으로 citation ID를 만들고, 답변의 각 검증 가능한 claim을 어느 span이 지지·반박·무관한지 확인합니다. 답할 근거가 없거나 서로 충돌하면 “현재 승인된 문서에서 확인하지 못했다”와 필요한 추가 source를 반환합니다. Model confidence 숫자는 calibration 없이 근거 충분성을 대신하지 못하므로 retrieval evidence와 policy로 abstain을 판정합니다.

평가의 첫 층은 ingestion입니다. 예상 문서·page·table 수, parse error, empty text, OCR confidence와 source-to-chunk coverage를 확인합니다. 삭제 fixture의 old source ID가 모든 active index와 cache에서 0건인지, 새 revision의 content hash와 chunk count가 manifest에 맞는지도 검증합니다. Parser가 표 한 줄을 잃었는데 answer score가 우연히 높으면 다음 질문에서 원인을 놓치므로 source coverage를 독립 gate로 둡니다.

Retrieval 평가는 질문마다 relevant document·span judgement를 만들고 recall@k, precision@k, MRR 또는 nDCG처럼 목적에 맞는 지표를 사용합니다. Elastic rank evaluation API도 MRR·DCG 계열을 포함한 ranked result 평가 기능을 제공합니다. 숫자 이름보다 중요한 것은 judgement 작성 규칙입니다. 답에 필요한 두 문서 중 하나만 찾은 partial relevance, 여러 revision, 무근거 question과 권한별 relevant set을 명시합니다.

Generation 평가는 answer correctness만이 아니라 claim-level citation support, source contradiction, 필수 조건 누락, citation identity와 근거 없을 때 abstain을 봅니다. RAGAS 같은 연구는 context relevance·faithfulness 등 여러 차원의 자동 평가를 제안하지만 judge model 점수를 사람 정답으로 간주하지 않습니다. 자동 score는 반복 회귀를 빠르게 찾는 보조 수단이고 critical sample은 원문을 읽는 사람 평가와 deterministic citation span 검사로 확인합니다.

Security gate는 unauthorized document·chunk·citation·answer disclosure가 0이어야 하며 평균 품질로 상쇄하지 않습니다. Tenant·role·revoked user, missing identity와 malformed ACL을 같은 query로 실행하고 retrieval trace 자체에 금지 text가 없는지 봅니다. Poisoned source·indirect injection, membership 변경 중 cache, deleted document와 stale replica를 넣어 fail-closed와 invalidation 시간을 측정합니다. Query와 answer log에는 원문·개인정보를 최소화하고 reviewer도 필요한 scope만 읽게 합니다.

운영 gate에는 retrieval·rerank·generation의 각각 p50/p95, timeout·empty result, context token, cost·CPU/GPU, index freshness lag를 둡니다. Candidate index를 shadow로 실행해 기존 답과 비교한 뒤 제한된 tenant canary로 확대합니다. 모든 request에는 source generation, embedding·retriever·reranker, prompt·model revision과 policy version을 남겨 incident를 재현합니다. Rollback은 prompt만 되돌리는 것이 아니라 previous compatible source snapshot·index generation·model과 policy alias, cache invalidation을 함께 복구해 정상·실패·권한 set을 다시 통과하는 실제 훈련입니다.

좋은 평가는 “어느 모델이 제일 좋은가”가 아니라 “이 변경을 이 사용자와 부하에 배포해도 되는가”로 시작합니다. Decision owner, 실제 업무, 사용 언어·입력 길이·출력 형태, 실패했을 때의 손실과 사람에게 넘기는 경로를 적습니다. Public leaderboard는 넓은 능력을 보는 참고 자료이지만 회사의 한국어 분류 label, 문서 revision, tool permission과 serving 부하를 대표하지 않습니다. HELM 연구가 scenario와 metric의 넓은 공간을 분류한 이유도 한 평가 축이 모델의 모든 능력·위험을 설명하지 못하기 때문입니다.

평가 contract에는 baseline과 candidate의 immutable identity를 적습니다. Model·adapter·quant digest, tokenizer·chat template, system/user prompt, retrieval index, tool schema, runtime·driver, hardware와 generation parameter가 포함됩니다. “Q4와 Q5 비교”라고만 쓰면 Q5에서 prompt까지 바뀌었는지 해석할 수 없습니다. 한 실험에서는 원인으로 알고 싶은 변경 하나만 바꾸고, 꼭 함께 바뀌어야 하는 묶음은 하나의 candidate artifact로 선언합니다.

질문 집합은 사용량이 많은 정상 사례, 경계, 드물지만 손실이 큰 critical, 예상 밖 입력과 안전·권한 실패로 나눕니다. 평균 95%가 critical slice 60%를 숨길 수 있으므로 slice별 sample 수, metric과 minimum gate를 결과 전에 정합니다. 전체 평균은 운영 규모를 예상하는 데 쓰고 critical minimum은 배포 가능성을 판정합니다. 한 지표의 초과 달성으로 다른 독립 gate 실패를 상쇄하지 않는 정책도 명시합니다.

Model quality와 system quality도 구분합니다. Base model에 정답 context를 직접 주는 oracle test, 실제 retrieval·tool을 연결한 end-to-end test와 serving load test를 나누면 잘못된 답의 원인이 model, retrieval, prompt, tool, timeout 중 어디인지 좁힐 수 있습니다. 제품은 end-to-end로 승인하지만 component test를 함께 남겨 어느 layer를 고쳐야 하는지를 설명합니다.

평가 예산에는 계산 비용뿐 아니라 label 작성자·domain reviewer·privacy review와 재시험 책임을 포함합니다. 처음부터 수천 개를 자동 채점하기보다 critical rubric의 모호함을 작은 calibration set에서 고친 뒤 representative frozen set을 늘립니다. 모델이 바뀌거나 데이터 분포·업무 정책이 바뀌면 어떤 trigger로 contract를 다시 검토할지도 정합니다.

평가 row에는 stable ID, input과 trusted reference, task·slice·risk tag, source revision, 작성자·검토자, 개인정보 처리와 license를 둡니다. 자유 생성은 하나의 정답 문자열보다 must-include·must-not-include·사실 source와 rubric이 필요합니다. 분류 label은 정의·우선순위·애매한 경계 예시를 함께 제공하고, code·tool task는 expected final state·side effect와 sandbox cleanup을 기술합니다.

Label 작성 전 calibration round에서 여러 reviewer가 같은 작은 묶음을 독립 판정합니다. 불일치 sample을 합의로 지우기 전에 rubric의 모호한 용어, 빠진 예외와 domain knowledge를 찾아 수정합니다. Agreement 숫자가 높아도 모두 같은 잘못된 reference를 사용했을 수 있으므로 authoritative source와 adjudicator를 둡니다. Final set에는 raw label history와 rubric revision을 연결하되 평가자에게 candidate 이름은 가립니다.

Data leakage는 exact duplicate만의 문제가 아닙니다. Training row의 paraphrase, 같은 source paragraph에서 만든 query, public benchmark의 answer pattern과 few-shot example이 test에 들어갈 수 있습니다. Source·customer·conversation·document와 template family를 group key로 묶고 split합니다. Model pretraining 포함 여부를 완전히 알 수 없는 public benchmark는 contamination 가능성을 limitation으로 쓰고 private time-split·newly authored transfer set으로 보완합니다.

Frozen set은 절대 바뀌지 않는 비밀 파일이 아닙니다. Hash와 version으로 평가 당시 내용을 고정하고 label defect가 발견되면 old result를 조용히 덮지 않고 새 revision·변경 이유·영향받은 run을 기록합니다. Model이 test에 반복 최적화되어 benchmark overfitting이 생기지 않도록 개발용 regression, holdout 승인, 사후 monitoring sample의 용도를 분리합니다. 승인 책임자가 holdout 정답에 접근하는 주체도 제한합니다.

개인정보·기밀을 실제 평가에 사용하면 최소화·가명화와 보존·삭제 정책을 적용합니다. Raw prompt/output log는 모델 품질 분석에 유용하지만 주민번호·계약 내용과 secret이 남을 수 있습니다. 평가 runner는 필요한 dataset scope만 읽고 output에는 row ID와 structured finding을 우선 저장합니다. 사람이 검토할 때도 업무상 필요한 slice만 열며 외부 judge API를 사용한다면 data transfer와 retention을 별도 승인합니다.

정확한 label이 있는 분류는 accuracy, precision·recall·F1과 confusion matrix를 쓸 수 있지만 class imbalance와 실패 비용을 함께 봅니다. 구조화 출력은 JSON parse 성공만으로 끝내지 않고 pinned JSON Schema validation, enum·required·additional property와 semantic constraint를 검사합니다. Tool task는 모델이 “성공했다”고 말했는지가 아니라 sandbox의 final state, 허용되지 않은 side effect와 rollback을 code로 확인합니다.

요약·상담·설명처럼 여러 좋은 답이 있는 task는 relevance, factual support, completeness, prohibited claim, tone을 분리한 rubric이 필요합니다. 각 점수 level에 positive·negative anchor를 만들고 reviewer가 전체 인상을 한 숫자로 찍지 않게 합니다. Candidate 이름·가격과 예상 우승자를 숨기고 답 순서를 무작위화하며 reviewer가 근거 문장과 failure code를 남기게 합니다. 사람 간 불일치는 숨길 noise가 아니라 rubric defect나 실제 preference 분산의 evidence입니다.

LLM-as-a-judge는 대량 회귀를 빠르게 찾고 설명을 만들 수 있지만 judge model·prompt·template도 versioned component입니다. MT-Bench 연구는 특정 setup에서 사람과 높은 agreement를 보고하면서도 position bias, verbosity bias와 self-enhancement·reasoning failure를 분석합니다. 그 결과를 모든 judge·언어·업무에 대한 보장으로 쓰지 않습니다. A/B 순서를 바꾼 consistency, 동일 답 tie, 길이만 늘린 답, known wrong reference와 사람 calibration set을 먼저 통과시킵니다.

Judge가 candidate와 같은 model family이거나 답에 적힌 잘못된 reasoning에 끌릴 수 있으므로 deterministic check와 authoritative reference를 우선합니다. Pairwise comparison은 작은 차이를 보기 좋지만 조합 수가 늘고 position 영향을 받습니다. Single score는 확장하기 쉽지만 scale drift가 큽니다. Judge가 실패하거나 schema 밖 출력을 내면 임의 기본 점수를 주지 않고 unscored로 표시해 사람이 검토합니다.

Hugging Face Evaluate가 metric·comparison·measurement를 구분하듯 model prediction뿐 아니라 dataset 속성과 두 candidate의 agreement도 평가 대상입니다. 한 BLEU·ROUGE·judge 평균을 “품질”이라고 부르지 않고 각 metric이 답하는 질문, 단위, aggregation, missing·timeout 처리와 limitation을 report에 씁니다. Raw input/output·per-row result를 보존해야 평균이 변했을 때 어떤 slice와 failure가 움직였는지 다시 분석할 수 있습니다.

Time To First Token(TTFT)은 request 전송부터 첫 content token까지 기다린 시간으로 queue·network와 prefill을 포함할 수 있습니다. Inter-Token Latency(ITL) 또는 Time Per Output Token(TPOT)은 첫 token 이후 token 사이의 생성 속도를 나타냅니다. End-to-end는 마지막 token까지이며 system throughput은 모든 동시 request의 output token 또는 request 처리량입니다. NVIDIA 공식 문서는 도구마다 metric 정의가 다를 수 있으므로 정의가 맞을 때만 비교하라고 명시합니다.

입력·출력 token 길이와 streaming 방식이 다르면 latency 숫자는 비교할 수 없습니다. 실제 traffic에서 short classification, medium chat, long document를 bucket으로 추출하고 sensitive text 대신 길이·구조를 보존한 fixture를 만듭니다. Candidate 모두 같은 tokenizer·template·max output·stop·sampling을 사용하며 timeout·cancelled·empty output을 빠른 성공처럼 평균에서 제외하지 않습니다. Error rate와 completed goodput에 포함해 보고합니다.

Concurrency 1의 token/s는 여러 사용자의 service capacity가 아닙니다. Open-loop request rate와 closed-loop concurrency가 만드는 queue behavior가 다르므로 실제 arrival pattern·burst를 재현합니다. Rate를 올리며 p95 TTFT·ITL·end-to-end와 error SLO를 지키는 최대 goodput을 찾고 saturation 뒤 throughput만 높은 지점을 채택하지 않습니다. vLLM bench serve가 request rate, prompt 수, percentile metric, warmup과 detailed result를 제공하는 것은 구현 예이며 다른 backend와 exact 조건을 맞춰야 합니다.

Cold model load·first request와 warmed steady state를 분리합니다. 반복마다 driver·runtime·model digest, GPU·CPU·memory, tensor parallel, batch·cache 설정과 background load를 기록합니다. Peak VRAM·RAM, KV cache hit·eviction, power·energy를 목적에 따라 수집하고 monitoring overhead도 고정합니다. 한 번의 최고 결과 대신 여러 clean repeat의 분포와 raw per-request timestamp를 남깁니다.

Quality와 performance는 별개 표이지만 release에서는 함께 통과해야 합니다. Quantization이나 speculative decoding이 throughput을 높여도 critical accuracy·schema가 떨어지면 승인하지 않습니다. MLPerf Inference처럼 scenario·quality target·performance rule을 함께 고정하는 원칙을 참고하되 공개 hardware submission을 내 서비스 latency 보장으로 복사하지 않습니다. 네트워크·gateway·retrieval·tool을 포함한 end-to-end test와 model server component test를 둘 다 남겨 병목을 귀속합니다.

비용 비교의 분모도 고정합니다. 시간당 GPU 비용이나 소비 전력을 단순 TPS로 나누면 timeout·invalid output과 quality gate를 실패한 request도 성과처럼 포함될 수 있습니다. 사전 quality·latency SLO를 통과한 completed request 또는 유효 output token당 비용·energy를 계산하고 재시도·queue 폐기와 idle reserve를 포함합니다. 같은 장비라도 낮은 request rate에서 전력 효율과 saturation 지점의 효율이 다르므로 목표 traffic mix에서 측정합니다. 비용이 낮아도 사람 교정과 incident가 늘면 전체 업무 비용은 커질 수 있어 correction rate와 reviewer 시간을 release report에 함께 둡니다.

Baseline과 candidate는 같은 row·순서·environment에서 실행해 per-row difference를 만듭니다. Stochastic generation은 seed를 고정해도 hardware·implementation에 따라 완전 재현되지 않을 수 있으므로 여러 repeat와 output variation을 봅니다. PyTorch 공식 재현성 문서도 release·platform 사이의 완전한 reproducibility가 보장되지 않고 deterministic operation이 느릴 수 있음을 설명합니다. Seed는 manifest의 한 요소이지 동일 결과의 증명서가 아닙니다.

평균 차이에는 표본 불확실성이 있습니다. 같은 질문에 대한 baseline·candidate 결과는 paired data이므로 row index를 함께 resample하는 bootstrap difference 같은 방법으로 confidence interval을 계산할 수 있습니다. SciPy 공식 bootstrap API도 paired option과 confidence interval을 제공합니다. 특정 interval 방식이 작은 sample·강한 dependence에 항상 적합한 것은 아니므로 sample unit, resampling method·count, interval과 practical minimum effect를 report에 명시합니다.

통계적 차이와 업무상 유의한 차이는 다릅니다. 큰 sample에서는 작은 +0.1%p도 좁은 구간을 가질 수 있지만 비용·latency·운영 복잡도를 정당화하지 못할 수 있습니다. 반대로 rare critical failure는 평균 통계 검정에 충분한 수가 없어도 한 건이 release blocker일 수 있습니다. Overall improvement, confidence interval, slice minimum과 non-inferiority·critical zero tolerance를 함께 판정합니다.

Offline gate 뒤 shadow에서 production request를 candidate에도 복제하되 외부 action과 user answer를 내보내지 않습니다. Privacy-safe per-row comparison과 actual model/prompt/runtime identity, latency·error를 보고 limited canary로 확대합니다. Canary traffic selection이 쉬운 사용자만 포함하지 않게 slice를 확인하고 correction·abstain·incident와 drift를 관측합니다. Report에는 승인자, known limitation, expiry와 재평가 trigger를 남깁니다.

Rollback은 model alias만 바꾸는 일이 아닙니다. Previous model·adapter·quant, tokenizer/template·prompt, retrieval/tool schema, runtime config와 cache를 compatible bundle로 복구하고 실제 failure·normal·performance set이 회복되는지 시험합니다. Candidate에서 발견한 failure는 stable row ID와 source·expected behavior를 가진 regression test로 보존합니다. 시간이 지나 user query·label·latency 분포가 drift하면 production correction과 incident에서 새 sample을 privacy review 후 추가하고 새로운 evaluation revision으로 재승인합니다.