요약 답변: 검색 파이프라인(retrieval pipeline)을 한 단계씩 격리하여 벡터 검색을 트러블슈팅하세요. 문서와 쿼리 임베딩(embeddings)이 동일한 모델을 사용하는지, 차원(dimensions)이 벡터 컬럼 및 인덱스와 일치하는지, 청크(chunks)가 유용한 컨텍스트를 보존하고 있는지, 필터(filters)가 관련 행을 숨기고 있지는 않은지, top-k 결과에 예상되는 증거가 포함되어 있는지, 그리고 정확한 용어가 중요할 때 하이브리드 검색(hybrid search)이 테스트되었는지 확인하십시오.

AI 애플리케이션이 잘못된 답변을 제공할 때, 모델이 문제의 원인이 아닐 수도 있습니다. 종종 답변이 검색된 컨텍스트(context)에 존재하지 않는 경우가 많습니다. 벡터 검색 트러블슈팅은 생성(generation) 단계 이전에 시작되어야 합니다. 임베딩(embeddings), 텍스트 청킹(chunk text), 메타데이터 필터(metadata filters), 유사도 점수(similarity scores), 인덱스 상태(index state), 그리고 검색 결과(retrieval results)를 직접 조사하십시오.

Oracle AI Database의 경우, 유용한 접근 방식은 간단합니다. 벡터, 소스 메타데이터, SQL 필터, 그리고 평가 체크(evaluation checks)를 충분히 가까이 두어, 검색 과정을 블랙박스(black box)가 아닌 애플리케이션 데이터 경로처럼 디버깅할 수 있도록 하십시오.

핵심 요약:

• 프롬프트(prompts)를 변경하기 전에 검색(retrieval)을 디버깅하십시오.
• 임베딩 일관성(embedding consistency)과 벡터 차원(vector dimensions)을 가장 먼저 확인하십시오.
• 변화를 측정하기 위해 알려진 쿼리 테스트(known-query tests)와 RAG 평가 노트북(RAG evaluation notebook)을 사용하십시오.

벡터 검색이 문제인지 어떻게 알 수 있나요?

요약 답변: 사용자 쿼리를 실행하고, top-k 청크(chunks) 또는 행(rows)을 조사한 뒤, 답변이 실제로 존재하는지 질문하십시오. 만약 예상되는 증거가 누락되었거나, 너무 낮거나, 오래되었거나, 필터링되었거나, 중복되었다면 실패의 원인은 검색(retrieval) 측에 있습니다. 만약 증거는 정확하지만 답변이 틀렸다면, 생성(generation), 프롬프팅(prompting), 인용(citations), 또는 답변 평가(answer evaluation)를 조사하십시오.

다음의 2단계 진단법을 사용하십시오:

1. 검색(retrieval)만 실행합니다.
2. LLM 없이 반환된 청크(chunks)를 조사합니다.

다음 사항을 질문하십시오:

• 예상되는 소스 문서가 top-k에 포함되어 있는가?
• 올바른 청크(chunk)가 충분히 높은 순위로 매겨져 있는가?
• 유사도 점수(similarity scores)가 군집화되어 있는가, 아니면 명확하게 분리되어 있는가?
• 무관한 청크(chunks)가 유용한 증거를 밀어내고 있는가?
• 메타데이터, 테넌트(tenant), 버전, 또는 권한 필터가 정답을 제거했는가?

핵심 요약:

• 검색 검사 (Retrieval inspection)가 프롬프트 튜닝 (prompt tuning)보다 빠릅니다.
• Top-k 증거는 읽을 수 있어야 하며 출처를 추적할 수 있어야 합니다.
• 만약 정답이 검색된 컨텍스트 (retrieved context) 내에 없다면, 생성 (generation) 단계에서 이를 신뢰성 있게 해결할 수 없습니다.

임베딩 (embeddings)이 일관적인가?

짧은 답변: 성능이 낮은 벡터 검색 (vector search)은 종종 일관되지 않은 임베딩에서 시작됩니다. 문서와 쿼리 (query) 모두에 동일한 임베딩 모델 (embedding model)과 전처리 (preprocessing) 경로를 사용하십시오. 혼합 모델(mixed-model) 또는 오래된 벡터(stale-vector) 문제를 식별할 수 있도록 임베딩 모델 ID, 벡터 차원 (vector dimension), 청킹 (chunking) 버전, 파서 (parser) 버전, 그리고 임베딩 타임스탬프 (embedding timestamp)를 기록하십시오.

다음 사항을 확인하십시오:

• 한 모델로 생성된 문서 임베딩과 다른 모델로 생성된 쿼리 임베딩
• 테이블 또는 인덱스 (index) 설정과 일치하지 않는 차원의 벡터
• 부분적인 임베딩 모델 마이그레이션 (migration)
• 데이터 수집 (ingestion) 시점과 쿼리 시점 사이의 전처리 차이
• HTML, 불필요한 문구 (boilerplate), 또는 테이블 형식이 일관되지 않게 임베딩된 경우

프로덕션 (production) 시스템의 경우, 모든 벡터 행 (vector row)에 임베딩 모델 이름과 버전을 함께 저장하십시오. 그렇게 하면 모델이나 전처리 변경 후 품질이 저하되었을 때 트러블슈팅 (troubleshooting)이 가능해집니다.

핵심 요약:

• 임베딩 모델 드리프트 (Embedding model drift)는 검색 품질 저하처럼 보일 수 있습니다.
• 벡터 차원은 검색 테스트 전에 검증되어야 합니다.
• 벡터 행과 함께 임베딩 메타데이터 (metadata)를 저장하십시오.

청킹 (chunking)과 파싱 (parsing)이 검색을 방해하고 있는가?

짧은 답변: 임베딩과 인덱스가 올바르더라도 청킹 때문에 벡터 검색이 실패할 수 있습니다. 너무 큰 청크는 관련 없는 주제들을 섞어버립니다. 너무 작은 청크는 컨텍스트 (context)를 잃어버립니다. 테이블, PDF, 코드, 전사 데이터 (transcripts), 그리고 중첩된 섹션들은 유용한 검색 증거가 되기 전에 구조를 인식하는 파싱 (structure-aware parsing) 과정을 거쳐야 합니다.

실패한 검색 청크를 수동으로 검사하십시오. 다음 사항을 확인하십시오:

• 청크에서 누락된 제목 (headings)
• 헤더 (headers)와 분리된 테이블
• 중간에 잘린 문장
• 임베딩을 지배하는 반복적인 불필요한 문구 (boilerplate)
• 누락된 소스 ID 또는 페이지 참조
• 화자(speaker)나 타임스탬프가 없는 전사 데이터 (transcript) 청크

DBMS_VECTOR_CHAIN은 텍스트 처리 및 청킹 (chunking) 워크플로우를 구축하는 데 도움을 줄 수 있지만, 운영 환경에서의 결정은 여전히 경험적입니다. 즉, 청킹 (chunking) 변경 전후에 동일한 기지 쿼리 (known-query) 세트를 실행해 보아야 합니다.

핵심 요약:

• 잘 생성된 청크 텍스트는 원본 문서 외부에서도 의미가 통해야 합니다.
• 잘못된 파싱 (parsing)은 모든 벡터 인덱스 (vector index)를 취약해 보이게 만들 수 있습니다.
• 청킹 (chunking) 변경 시에는 검색 회귀 테스트 (retrieval regression tests)가 필요합니다.

필터, ACL 또는 메타데이터가 좋은 결과를 숨기고 있지는 않나요?

짧은 답변: 적절한 증거가 존재함에도 불구하고 필수 필터가 이를 제외할 때 벡터 검색 (vector search)은 저조한 결과를 반환할 수 있습니다. 유사도 검색 (similarity search)이 실패했다고 가정하기 전에 테넌트 ID (tenant ID), ACL, 문서 상태, 소스 버전, 언어, 날짜 범위, 삭제 플래그 및 현재 버전 마커를 확인하십시오.

이는 엔터프라이즈 RAG에서 흔히 발생하는 문제입니다. 쿼리 (query)가 실패하는 이유는 다음과 같을 수 있습니다:

핵심 요약:

• 메타데이터 필터는 사후 처리 (post-processing) 세부 사항이 아니라 검색 (retrieval)의 일부입니다.
• 결과가 비어 있거나 미약한 것은 필터 문제일 수 있습니다.
• 트러블슈팅 시 벡터 쿼리 (vector query)와 적용된 필터를 모두 로그 (log)에 남겨야 합니다.

벡터 인덱스가 올바르게 구성되고 쿼리되고 있습니까?

짧은 답변: 벡터가 예상된 컬럼 (column)에 저장되어 있는지, 쿼리가 동일한 벡터 필드를 사용하는지, 인덱스 (index)가 구축되어 사용 가능한지, 거리 측정 방식 (distance metric)이 임베딩 모델 (embedding model)과 일치하는지, 그리고 top-k 또는 임계값 (threshold) 설정이 애플리케이션에 적절한지 확인하십시오.

최소한 다음 사항들을 점검하십시오:

• 벡터 컬럼에 데이터가 채워져 있는지
• 쿼리 임베딩 (query embedding)이 예상된 차원 (dimension)을 갖는지
• 인덱스 (index)가 존재하고 사용 가능한지
• 쿼리가 의도한 벡터 컬럼을 사용하는지
• 유사도 측정 방식 (similarity metric)이 적절한지
• top-k가 관련 후보를 노출할 만큼 충분히 큰지
• 임계값 (thresholds)이 허용 가능한 결과를 잘라내고 있지는 않은지

근사 최근접 이웃 (Approximate Nearest Neighbor, ANN) 설정을 사용하는 경우, 가능한 경우 더 작은 크기의 정확한 검색 (exact search) 또는 높은 재현율 (high-recall) 기준점 (baseline)과 비교하여 재현율 (recall)을 테스트하십시오. ANN 튜닝은 지연 시간 (latency)과 재현율 (recall) 사이의 트레이드오프 (tradeoff)입니다. 알려진 쿼리 세트 (known-query set) 없이 튜닝하지 마십시오.

핵심 요약 (Key takeaways):

• 인덱스 상태 (Index state) 및 쿼리 필드 (query field) 실수는 흔하며 놓치기 쉽습니다.
• Top-k 및 임계값 (threshold) 설정은 추측이 아닌 측정되어야 합니다.
• ANN 튜닝은 검색 품질 (retrieval quality)을 바탕으로 검증되어야 합니다.

벡터 전용 검색과 하이브리드 검색을 언제 비교해야 하나요?

짧은 답변: 사용자가 정확한 식별자 (identifiers), 에러 코드 (error codes), 제품명 (product names), 파일명 (file names), 명령어 (commands), 버전 (versions) 또는 절 (clauses)을 요청할 때 벡터 전용 검색과 하이브리드 검색을 비교하십시오. 벡터 검색은 의미적 유사성 (semantic similarity)을 처리합니다. 키워드 검색 (Keyword search)은 정확한 어휘적 증거 (lexical evidence)를 처리합니다. 하이브리드 검색은 기본값 (default)이 되기 전에 해당 워크로드 (workload)를 개선한다는 것을 증명해야 합니다.

다음 의사 결정 테이블 (decision table)을 사용하십시오:

Oracle AI Database는 전문 검색 (full-text)과 벡터 유사도 검색 (vector similarity search)을 결합하는 하이브리드 검색 패턴을 지원합니다. 핵심은 개별적인 일화가 아니라 동일한 질문에 대해 경로 (routes)를 비교하는 것입니다.

핵심 요약 (Key takeaways):

• 하이브리드 검색은 측정된 옵션이지, 그 자체로 훈장이 아닙니다.
• 정확한 식별자 (Exact identifiers)에는 어휘적 신호 (lexical signals)가 필요합니다.
• RAG 평가 노트북 (evaluation notebook)은 비교를 위한 올바른 증명 경로입니다.

트러블슈팅을 통해 검색이 개선되었는지 어떻게 측정하나요?

짧은 답변: 알려진 질문, 예상 문서, 금지된 문서, 예상 순위 (expected rank), 그리고 실패 모드 (failure mode)에 대한 메모를 포함하는 작은 평가 세트 (evaluation set)를 만드십시오. 각 변경 사항 전후의 recall@k, precision@k, MRR, NDCG 및 실패한 쿼리의 사례를 추적하십시오.

다음과 같은 테이블로 시작하십시오:

RAG 평가 노트북 (RAG evaluation notebook)은 이미 유용한 패턴을 제공합니다: 검색 방법(retrieval methods)을 분리하고, 챌린지 세트(challenge set)를 실행하며, 지표(metrics)를 내보내고, 결과가 재현 가능하도록 매니페스트(manifest)를 유지하십시오.

핵심 요약 (Key takeaways):

• 트러블슈팅(Troubleshooting)에는 전후 지표(before-and-after metrics)가 필요합니다.
• 실패한 쿼리를 회귀 테스트(regression tests)로 유지하십시오.
• 알려진 쿼리 세트(known-query set)의 성능이 개선될 때까지 수정 사항을 배포하지 마십시오.

Oracle AI Database로 벡터 검색(vector search)을 트러블슈팅하는 방법은 무엇인가요?

짧은 답변: Oracle AI Database를 사용하여 벡터(vectors), 청크(chunks), 메타데이터(metadata), 필터(filters), 소스 상태(source state) 및 검색 경로(retrieval routes)를 함께 검사하십시오. 의미론적 검색(semantic retrieval)을 위해 Oracle AI Vector Search로 시작하고, 정확한 용어가 중요한 경우에는 하이브리드 검색(hybrid search)을 추가하며, 반복 가능한 청킹(chunking) 및 텍스트 처리 워크플로를 위해 DBMS_VECTOR_CHAIN을 사용하십시오.

유용한 문서 및 실행 가능한 자산:

• Oracle AI Vector Search 사용자 가이드 (Oracle AI Vector Search User's Guide)
• 하이브리드 검색 이해하기 (Understand Hybrid Search)
• DBMS_VECTOR_CHAIN
• RAG 평가 노트북: oracle_rag_with_evals.ipynb (RAG evaluation notebook: oracle_rag_with_evals.ipynb)

실용적인 Oracle 트러블슈팅 워크플로:

1. 벡터가 존재하는지 확인하고 차원(dimensions)이 일치하는지 확인합니다.
2. top-k에 의해 반환된 정확한 청크(chunk) 텍스트를 검사합니다.
3. 메타데이터 필터(metadata filters)를 적용했을 때와 적용하지 않았을 때 모두 쿼리를 실행합니다.
4. 벡터 전용(vector-only), 키워드(keyword), 그리고 하이브리드(hybrid) 검색을 비교합니다.
5. 소스 타임스탬프(source timestamps), 삭제 플래그(delete flags), 그리고 임베딩 모델 버전(embedding model versions)을 확인합니다.
6. 알려진 쿼리 평가 세트(known-query evaluation set)를 실행하고 결과를 내보냅니다.

핵심 요약 (Key takeaways):

• 검색 결과물(retrieval artifacts)과 메타데이터를 쿼리 가능한 상태로 유지하세요.
• 어휘적(lexical) 증거와 의미적(semantic) 증거가 모두 중요할 때는 하이브리드 검색(hybrid search)을 사용하세요.
• 평가 출력값(evaluation output)을 트러블슈팅이 성공했다는 증거로 취급하세요.

벡터 검색 트러블슈팅 체크리스트 (Vector search troubleshooting checklist)

요약 답변: 건강한 벡터 검색 경로는 일관된 임베딩(embeddings), 유효한 차원(dimensions), 유용한 청크(chunks), 올바른 인덱스 설정(index configuration), 적절한 필터(filters), 검사된 top-k 결과, 알려진 쿼리 테스트, 그리고 품질이 개선되거나 저하되었을 때 무엇이 변했는지 보여주는 검색 로그(retrieval logs)를 갖추고 있습니다.

다음 체크리스트를 사용하세요:

• 인덱싱(indexing)과 쿼리(querying)에 동일한 임베딩 모델(embedding model)을 사용함.
• 벡터 차원(vector dimensions)이 일치함.
• 쿼리된 벡터 컬럼(vector column)이 정확함.
• 인덱스(index)가 존재하며 사용 가능함.
• 청크 텍스트(chunk text)가 읽기 쉽고 문맥이 풍부함.
• 메타데이터 필터(metadata filters)가 가시적이며 테스트 가능함.
• top-k 결과에 예상되는 증거가 포함됨.
• 유사도 임계값(similarity thresholds)이 좋은 후보를 제거하지 않음.
• 정확한 식별자(exact identifiers)에 대해 하이브리드 검색(hybrid search)을 테스트함.
• 오래된(stale) 임베딩과 중복된 임베딩을 모니터링함.
• 검색 지표(retrieval metrics)를 시간에 따라 기록함.

핵심 요약 (Key takeaways):

• 벡터 검색 트러블슈팅은 파이프라인 디버깅(pipeline debugging)입니다.
• 대부분의 수정 사항은 검색 지표(retrieval metrics)를 통해 측정 가능해야 합니다.
• 벡터, SQL 필터, 소스 메타데이터, 그리고 평가 증거(evaluation evidence)가 서로 밀접하게 유지될 때 Oracle AI Database는 가장 강력한 스토리를 제공합니다.