짧은 답변: 프로덕션 RAG 평가는 시스템이 올바른 근거를 검색하는지, 해당 근거로부터 답변을 생성하는지, 권한을 준수하는지, 최신 데이터를 처리하는지, 그리고 지원되지 않는 질문을 거절하는지를 측정해야 합니다. 동일한 질문 세트에 대해 키워드(keyword), 벡터(vector), SQL, 그리고 하이브리드(hybrid) 검색을 비교하십시오. 애플리케이션에 어떤 방식이 적합한지 결정하기 전에 검색 지표(retrieval metrics), 답변 품질 체크(answer-quality checks), 그리고 프로덕션 실패 테스트(production failure tests)를 사용하십시오.

RAG, 즉 검색 증강 생성 (Retrieval-Augmented Generation)은 권위 있는 소스에서 근거를 검색하여 언어 모델(language model)이 답변하기 전에 해당 근거를 제공합니다. 프로덕션 RAG 평가는 이 프로세스의 두 가지 측면을 모두 테스트합니다: 검색이 올바른 근거를 찾았는지, 그리고 생성된 답변이 이를 올바르게 사용했는지 여부입니다.

RAG 데모는 몇 개의 깨끗한 문서와 하나의 친절한 질문만 있으면 통과할 수 있습니다.

프로덕션은 시스템이 실제 사용자를 만나기 시작하는 곳입니다.

사용자들은 정확한 ID를 요구합니다. 모호한 질문을 던집니다. 5분 전에 변경된 데이터에 대해 묻습니다. 테넌트(tenants), 버전, 테이블, PDF, 상태 필드, 그리고 긴 대화에 걸쳐 질문합니다. 때로는 정답이 코퍼스(corpus)에 아예 존재하지 않을 수도 있습니다.

그렇기 때문에 유용한 질문은 "벡터 검색을 사용해야 할까요, 아니면 하이브리드 검색을 사용해야 할까요?"가 아닙니다. 유용한 질문은 "이 시스템이 실제로 가진 제약 조건 하에서, 어떤 검색 경로가 애플리케이션에 올바른 근거를 제공하는가?"입니다.

이 기사는 Oracle AI Database로 RAG를 구축하는 개발자들을 위해 해당 질문을 실질적인 평가 계획으로 전환합니다. 함께 제공되는 노트북은 세 가지 검색 방법을 벤치마킹합니다:

• 정확한 용어, 식별자 및 어휘적 일치(lexical matches)를 위한 키워드 검색 (keyword retrieval)
• 의미적 유사성(semantic similarity) 및 어휘 불일치(vocabulary mismatch)를 위한 벡터 검색 (vector retrieval)
• 키워드와 벡터 후보 모두 가치가 있을 때 사용하는 RRF 하이브리드 검색 (RRF hybrid retrieval)

SQL 또는 자연어-to-SQL (natural-language-to-SQL)은 현재의 구조화된 데이터(structured data)를 위한 별도의 경로로 취급됩니다. 이를 문서 검색 지표(document-retrieval metrics)에 억지로 맞추기보다는 쿼리 정확성(query-correctness), 권한(permission), 최신성(freshness), 그리고 결과 제한(result-limit) 테스트로 평가하십시오.

목표는 보편적인 승자를 선언하는 것이 아닙니다. 목표는 프로덕션 RAG (Retrieval-Augmented Generation) 시스템을 위한 올바른 검색 전략 (retrieval strategy)을 선택하는 데 필요한 근거를 구축하는 것입니다.

핵심 요약 (Key takeaways)

• 검색 (retrieval)과 생성된 답변을 분리하여 평가하십시오. 모델은 관련 있는 근거를 검색하고도 지원되지 않거나 부정확한 답변을 생성할 수 있습니다.
• 최신 구조화된 사실 (structured facts)에는 SQL 또는 NL2SQL을 사용하고, 비구조화된 콘텐츠에는 키워드 (keyword), 벡터 (vector), 또는 하이브리드 검색 (hybrid retrieval)을 사용하십시오. 혼합된 질문은 두 방식 모두로 라우팅 (route)하십시오.
• 프로덕션 기본값 (production default)을 선택하기 전에, 동일한 정답 세트 (ground-truth question set)를 대상으로 키워드, 벡터, 그리고 RRF 하이브리드 검색을 비교하십시오.
• 평균 검색 지표 (average retrieval metrics)와 함께 최신성 (freshness), 테넌트 격리 (tenant isolation), 메타데이터 필터 (metadata filters), 정확한 식별자 (exact identifiers), 인용 (citations), 그리고 기권 (abstention)을 테스트하십시오.
• 하이브리드 검색을 자동적인 승자가 아닌, 측정된 옵션으로 취급하십시오. 수치적 주장은 노트북 내보내기 (notebook exports)로 추적할 수 있을 때까지 공개하지 마십시오.

프로덕션 RAG는 어떤 모습인가?

짧은 답변: 프로덕션 RAG는 측정된 검색 및 답변 시스템입니다. 반복 가능한 인제스션 (ingestion), 버전 관리되는 청크 (versioned chunks), 액세스 제어 (access controls), 최신성 규칙 (freshness rules), 인용 (citations), 기권 (abstention), 관찰 가능성 (observability), 그리고 회귀 테스트 (regression tests)가 필요합니다. BM25, 벡터 검색 (vector search), RRF, 재순위화 (reranking), HyDE, 그리고 증분 인덱싱 (incremental indexing)과 같은 기능들은 사용자가 실제로 필요로 하는 답변을 개선한다는 것을 증명할 수 있을 때에만 의미가 있습니다.

개발자들이 흔히 하는 질문은 다음과 같습니다: "이미 하이브리드 검색, 재순위화, 인용, 그리고 환각 방지 정책 (no-hallucination policy)을 갖추고 있습니다. 그 외에 무엇이 RAG를 프로덕션 수준으로 만드나요?"

누락된 조각은 대개 평가 하네스 (evaluation harness)입니다. 검색 기능은 추가하기 쉽습니다. 청킹 (chunking) 변경, 임베딩 모델 (embedding model) 교체, 스키마 (schema) 변경, 또는 재순위화기 (reranker) 업데이트 이후에도 기능이 여전히 작동함을 증명하는 것이 더 어려운 프로덕션 문제입니다.

프로덕션 RAG 시스템은 다음과 같은 요소를 갖추어야 합니다:

1. 필수 증거와 예상 답변 동작이 포함된 정답(ground-truth) 질문 세트.
2. 키워드(keyword), 벡터(vector), SQL 및 하이브리드(hybrid) 경로에 대한 검색 지표(retrieval metrics).
3. 근거성(groundedness), 정확성(correctness), 인용 유효성(citation validity) 및 기권(abstention)에 대한 답변 평가.
4. 버전 관리되는 데이터 수집(ingestion), 파싱(parsing), 청킹(chunking), 임베딩(embeddings), 프롬프트(prompts) 및 검색 설정(retrieval configuration).
5. 테넌트(tenant), 권한(permission), 출처(source), 상태(status), 최신성(freshness) 및 문서 버전(document version)을 위한 메타데이터 필터.
6. 빈 결과(empty results), 검색 누락(retrieval misses), 지연 시간(latency), 인용 실패(citation failures) 및 오래된 증거(stale evidence)에 대한 관찰 가능성(observability).
7. 새로운 검색 변경 사항이 평균 성능은 향상시키지만 중요한 쿼리 클래스(query class)를 망가뜨릴 경우를 대비한 롤백(rollback) 경로.

청킹(Chunking)은 자체적인 테스트가 필요합니다. 짧은 지원 노트, 긴 PDF, 정책 문서, 표, 코드 및 제품 문서는 하나의 이상적인 청크 크기를 공유하지 않습니다. 청크 크기(chunk size), 중첩(overlap), 파싱(parsing), 부모 문서 링크(parent document links) 및 표 처리(table handling)를 버전 관리되는 설정으로 취급하세요. 그런 다음 변경 사항을 배포하기 전에 동일한 질문 세트를 사용하여 이러한 선택 사항들을 테스트하십시오.

이것이 실무적인 기준입니다: 만약 검색 변경으로 인한 오류를 감지할 수 없다면, 그 시스템은 아직 프로덕션 준비가 되지 않은 것입니다.

희소 SQL 데이터베이스(sparse SQL database) 환경에서 RAG 파이프라인을 어떻게 개선하나요?

짧은 답변: 희소 SQL 데이터베이스의 모든 행을 임베딩하지 마세요. 구조화된 질문은 SQL로 라우팅하고, 검색 가능한 텍스트를 만들기 전에 null 및 빈 필드를 필터링하며, 유용한 언어가 포함된 필드만 임베딩하세요. 정확한 ID 및 상태 값에는 키워드 검색(keyword retrieval)을, 설명 텍스트에는 벡터 검색(vector retrieval)을, 유효한 행에는 메타데이터 필터(metadata filters)를 사용하세요.

개발자들이 자주 하는 질문은 다음과 같습니다: "제 데이터베이스에는 빈 테이블과 null 컬럼이 많습니다. 행을 임베딩했지만 모델이 부실한 컨텍스트를 검색합니다. RAG 파이프라인을 어떻게 효율적으로 만들 수 있을까요?"

문제는 대개 모델이 아닙니다. 문제는 검색 코퍼스(retrieval corpus)에 정보량이 적은 청크(low-information chunks)가 포함되어 있다는 점입니다. 만약 한 행에 빈 컬럼이 많다면, 행 전체를 텍스트로 변환하는 것은 검색기(retriever)에게 컨텍스트 창(context-window) 공간을 차지하며 경쟁하는 노이즈를 제공하게 됩니다.

더 많은 검색 트릭을 추가하기 전에 작업을 분리하세요:

모든 물리적 행(physical row)을 임베딩(embedding)하기보다는 검색 뷰(retrieval view)를 생성하세요. 이 뷰에는 안정적인 ID, 필수 비즈니스 메타데이터(metadata), 그리고 비어 있지 않은 설명적 컬럼(descriptive columns)들로 구성된 의도적인 search_text 필드가 포함되어야 합니다.

예를 들어, 유용한 검색 레코드(retrieval record)에는 다음과 같은 내용이 포함될 수 있습니다:

risk_id: RSK-1042
tenant_id: acme
status: OPEN
...

이는 필드의 절반이 비어 있는 20개의 컬럼을 직렬화(serialising)하는 것과는 다릅니다. SQL 추론(reasoning)을 위해 null 값은 데이터베이스 상태 그대로 유지하세요. 부재(absence) 자체가 검색 대상인 경우가 아니라면, "null"이라는 단어를 의미론적 콘텐츠(semantic content)로 변환하지 마세요.

희소 관계형 데이터(sparse relational data)의 경우, 경로들을 결합하기 전에 각각을 별도로 평가하세요:

• SQL 품질: 생성되거나 선택된 SQL이 올바른 행을 반환하는가?
• 키워드(keyword) 품질: 정확한 ID, 코드, 상태(status), 제어 용어(controlled terms)가 신뢰성 있게 일치하는가?
• 벡터(vector) 품질: 설명적 필드가 의미론적으로 관련된 인시던트(incidents)나 리스크(risks)를 검색하는가?
• 하이브리드(hybrid) 품질: RRF가 노이즈가 섞인 행을 추가하지 않으면서 혼합 쿼리(mixed queries)를 개선하는가?

RRF는 키워드와 벡터 결과 목록 모두에 유용한 증거가 포함되어 있을 때 유용합니다. RRF는 품질이 낮은 코퍼스(corpus)를 정화하기 위한 단계가 아닙니다.

RAG는 실시간 동적 데이터를 어떻게 처리해야 하는가?

짧은 답변: 빈번하게 변경되는 구조화된 데이터(structured data)는 일반적으로 매 업데이트마다 다시 임베딩(re-embedded)하는 대신 실시간으로 쿼리(query)해야 합니다. 현재 행(rows)에는 SQL 또는 NL2SQL을 사용하고, 의미론적 검색(semantic retrieval)의 이점을 얻을 수 있는 비구조화된 텍스트(unstructured text)를 위해 RAG를 남겨두세요. 변경되는 문서의 경우, 영향을 받는 임베딩(embeddings)을 업데이트하고, 최신성 메타데이터(freshness metadata)를 추적하며, 오래된 답변 대 현재 답변의 동작(stale-versus-current answer behaviour)을 테스트하세요.

개발자들이 자주 하는 질문은 다음과 같습니다: "제 백엔드 데이터는 5분마다 업데이트됩니다. RAG, SQL, 캐싱(caching), MCP, 도구 호출(tool calling), 또는 다른 무언가를 사용해야 할까요?"

어떤 종류의 데이터가 최신 상태를 유지해야 하는지 묻는 것부터 시작하세요.

만약 정답이 현재의 구조화된 행(structured rows)에 있다면, 요청 시점에 데이터베이스를 쿼리(query)하세요. 5분마다 전체 데이터셋을 다시 임베딩(Re-embedding)하는 것은 신뢰할 수 있는 원천 데이터(source of truth)와 끊임없는 경주를 벌이는 것과 같습니다. 인덱싱(indexing) 작업이 끝나기도 전에 벡터 복사본이 오래된 데이터(stale)가 될 수 있습니다.

만약 정답이 비구조화된 문서(unstructured documents)에 있다면, 검색(retrieval)을 사용하세요. 하지만 최신성(freshness)을 명시적으로 관리해야 합니다. 소스 타임스탬프(source timestamps), 버전 ID(version IDs), 현재 버전 플래그(current-version flags), 수집 시간(ingestion times), 그리고 삭제 상태(deletion state)를 저장하세요. 그런 다음 시스템이 오래된 청크(stale chunk) 대신 현재의 증거를 선택하는지 평가하십시오.

단순한 라우팅 모델(routing model)을 사용하세요:

캐싱(Caching), MCP, 그리고 도구 호출(tool calling)은 유용하지만, 서로 다른 문제를 해결합니다.

캐시는 반복되는 작업을 줄여주지만, 소스 데이터가 변경될 때 반드시 무효화(invalidated)되어야 합니다. MCP는 어시스턴트에게 데이터베이스 도구를 노출할 수 있지만, 오래된 데이터를 최신으로 만들어주지는 않습니다. 도구 호출(tool calling)은 플래너(planner)가 SQL, 검색(retrieval), 또는 다른 서비스를 선택할 수 있게 해주지만, 모든 도구는 여전히 권한(permissions), 타임아웃(timeouts), 결과 제한(result limits), 그리고 추적 가능한 출력(traceable outputs)이 필요합니다.

프로덕션 패턴은 "모든 것을 임베딩하는 것"이 아닙니다. 그것은 "각 질문을 가장 최신의 권위 있는 소스(authoritative source)로 라우팅한 다음, 답변이 해당 소스를 올바르게 사용했는지 평가하는 것"입니다.

언제 SQL, 벡터 검색(vector search), 키워드 검색(keyword search), 또는 하이브리드 검색(hybrid search)을 사용해야 하나요?

짧은 답변: 구조화된 사실에는 SQL을, 정확한 용어에는 키워드 검색을, 의미적 유사성(semantic similarity)에는 벡터 검색을 사용하세요. 그리고 동일한 워크로드에 어휘적(lexical) 쿼리와 의미적(semantic) 쿼리가 모두 포함되어 있다면 하이브리드 검색을 사용하세요. 올바른 선택은 쿼리 분포, 최신성 요구 사항, 권한 규칙, 지연 시간(latency), 그리고 측정된 검색 품질에 따라 달라집니다.

각 검색 경로에는 고유한 역할이 있습니다.

질문이 행(rows), 필터(filters), 조인(joins), 날짜(dates), 카운트(counts), 합계(totals), 상태(statuses), 권한(permissions) 또는 현재 비즈니스 상태에 관한 것이라면 SQL이 올바른 첫 번째 경로입니다. 데이터에 이미 구조가 있다면, 그 구조를 계속 사용하세요.

사용자가 오류 코드(error codes), 제품명(product names), SKU, 티켓 ID(ticket IDs), 리스크 ID(risk IDs), 함수명(function names), 정책 조항(policy clauses) 및 철자가 중요한 기타 토큰과 같이 정확한 용어를 제공할 때는 키워드 검색(Keyword search)이 강력합니다.

벡터 검색(Vector search)은 쿼리(query)와 문서(document)가 동일한 개념에 대해 서로 다른 언어를 사용할 때 유용합니다. 이는 의역(paraphrases), 모호한 의도(fuzzy intent), 자연어 설명(natural-language descriptions) 및 어휘 불일치(vocabulary mismatch) 문제를 해결하는 데 도움이 됩니다.

하이브리드 검색(Hybrid search)은 워크로드에 두 가지 패턴이 모두 존재하고 두 결과 목록이 모두 기여할 때 적합합니다. 일반적인 구현 방식은 상호 순위 결합(Reciprocal Rank Fusion, RRF)입니다. 이는 키워드 검색과 벡터 검색으로부터 독립적으로 후보를 검색한 다음 순위를 결합합니다:

RRF score(document) = sum(1 / (60 + rank_in_result_set))

RRF는 키워드 점수(keyword scores)와 벡터 거리(vector distances)가 동일한 수치 척도(numeric scale) 상에 있다고 가정하는 오류를 피합니다. 두 경로 모두에서 발견된 문서는 두 순위 모두로부터 기여를 받습니다. 한 가지 경로에서만 발견된 문서라도 순위가 충분히 높다면 살아남을 수 있습니다.

실수는 "하이브리드"를 진지함을 나타내는 기본 배지(default badge)처럼 사용하는 것입니다. 하이브리드 검색(Hybrid retrieval)은 쿼리 작업, 튜닝(tuning), 지연 시간(latency) 및 운영 복잡성(operational complexity)을 추가합니다. 평가를 통해 중요한 질문들에 대해 성능이 향상됨이 증명될 때만 이를 추가하십시오.

RAG 평가를 위해 어떤 지표를 사용해야 하나요?

짧은 답변: 시스템이 올바른 근거(evidence)를 찾는지 테스트하려면 검색 지표(retrieval metrics)를 사용하고, 모델이 그 근거를 올바르게 사용하는지 테스트하려면 답변 지표(answer metrics)를 사용하십시오. 검색 지표에는 NDCG, MAP, 재현율(recall) 및 정밀도(precision)가 포함됩니다. 답변 지표는 근거성(groundedness), 정확성(correctness), 인용 유효성(citation validity) 및 기권 품질(abstention quality)을 다루어야 합니다.

RAG 평가는 하나의 점수로 통합되어서는 안 되는 두 개의 계층을 가집니다.

첫째, 검색(retrieval)을 평가하십시오. 검색 지표는 모델 독립적(model-independent)이며 생성 API(generation API) 없이도 실행할 수 있습니다. 이는 빈번한 회귀 테스트(regression checks)에 유용하게 사용됩니다.

노트북은 키워드 (Keyword), 벡터 (Vector), 그리고 RRF 하이브리드 검색 (RRF hybrid retrieval)에 대한 검색 결과를 기록합니다:

이 플레이스홀더 (Placeholders)들은 노트북이 깨끗하게 실행되고 내보낸 지표들이 검토될 때까지 플레이스홀더 상태로 유지되어야 합니다. 수동으로 이를 주장(claims)으로 바꾸지 마십시오.

둘째, 생성된 답변을 평가합니다. 검색된 문서가 관련이 있더라도 생성된 답변은 여전히 틀렸거나, 근거가 없거나, 과도하게 확신하거나, 인용이 잘못되었을 수 있습니다.

다음 항목에 대해 답변 수준의 점검 (Answer-level checks)을 사용하십시오:

• 근거성 (Groundedness): 답변이 검색된 컨텍스트 (Context) 내에 머물러 있는가?
• 정확성 (Correctness): 참조 답변 (Reference answer)과 일치하는가?
• 인용 유효성 (Citation validity): 인용된 문서가 해당 문서에 연결된 주장 (Claims)을 뒷받침하는가?
• 기권 품질 (Abstention quality): 코퍼스 (Corpus)에 충분한 근거가 없을 때 시스템이 답변을 거부하는가?