RAG 검색이 엉뚱할 때: 프롬프트보다 먼저 볼 6단계

RAG(검색 증강 생성)가 엉뚱한 답을 낼 때는 프롬프트를 고치기 전에 검색된 문서가 맞는지, 필요한 근거가 잘리지 않았는지부터 확인해야 합니다. 질문을 고정하고 검색 결과→문맥 구성→생성 순서로 나누면 원인을 좁힐 수 있습니다. 비슷한 출처 검증 과정은 ChatGPT 검색 출처 검증 8단계도 참고하세요.

  • 검색 결과가 틀리면 인덱스·청킹·검색어 확장부터 점검
  • 문서는 맞지만 답이 틀리면 컨텍스트 조립·지시문·출력검증 점검
  • 질문과 기대 근거를 고정한 작은 테스트 세트를 먼저 만듭니다

1. 증상으로 구간 나누기

RAG는 보통 문서 수집, 청킹, 임베딩·색인, 검색, 재정렬, 프롬프트에 문맥 삽입, 답변 생성으로 이어집니다. 각 단계의 입력과 출력을 로그로 남기지 않으면 “모델이 틀렸다”만 반복하게 됩니다. 답변에서 근거 문서의 ID와 인용 위치를 함께 보이게 한 뒤, 실제 검색 상위 결과와 대조하세요.

검색 결과 상위에 정답 문서가 없다면 생성 모델은 답을 지어내거나 무관한 자료를 섞을 수 있습니다. 정답 문서는 상위에 있지만 답변에서 빠지면 문맥 길이 제한, 문서 순서, 지시문 충돌 또는 답변 형식 검증 쪽에 무게를 둡니다.

문서와 검색 노드를 연결해 RAG 검색 흐름을 살펴보는 AI 연구팀
문서 검색과 답변 생성 사이의 단계를 분리해 확인하는 RAG 흐름

2. 재현 가능한 테스트 만들기

먼저 20~50개 정도의 대표 질문을 준비하고, 각 질문마다 반드시 찾아야 할 문서 ID 또는 핵심 문장을 기대값으로 기록합니다. 이 숫자는 시작용 예시이며 정답 기준은 서비스의 문서 종류와 위험도에 맞춰야 합니다. 테스트 질문에는 흔한 표현, 약어, 띄어쓰기 변형, 답이 문서에 없는 질문을 섞습니다. “문서에 없음” 사례를 빼면 근거가 없는 질문에도 답하는 결함을 발견하기 어렵습니다.

각 실행에서 질문, 검색된 문서 ID·순위·점수, 재정렬 후 순위, 최종 프롬프트에 들어간 발췌문, 답변을 함께 저장합니다. 개인정보나 비밀 문서는 보관 정책과 접근 통제를 먼저 정하고, 테스트에는 가급적 비식별 샘플을 씁니다.

3. 검색과 청킹 조정 순서

첫 검색 결과에 관련 문서가 전혀 없다면 임베딩 모델부터 바꾸지 말고 색인 누락, 문서 파싱 실패, 권한 필터, 언어별 토큰화 문제를 먼저 확인하세요. 특히 PDF 표·제목·각주가 텍스트로 어떻게 추출됐는지 원문과 대조해야 합니다.

문서가 잘렸다면 청크를 무조건 크게 만들기보다 제목·섹션 경계를 보존하고, 청크에 문서 제목과 경로 같은 맥락 메타데이터를 붙입니다. 질문이 여러 개념을 포함하면 키워드 검색과 의미 검색을 함께 쓰거나 재작성한 질의들을 비교할 수 있습니다. OpenAI의 Retrieval 가이드는 벡터 저장소와 검색 결과 조정의 공식 기준을 설명합니다. 관련 자료를 프로젝트별로 다루는 방법은 ChatGPT 프로젝트의 자료·지침 분리 방법과도 연결됩니다.

검색된 문서 조각을 나란히 검토하며 관련 근거를 찾는 작업자
정답 문서가 검색 상위에 포함되는지 질문별로 확인합니다

4. 문맥과 생성 단계 점검

정답 문서가 검색되지만 답이 빗나가면 최종 프롬프트에 그 문서가 실제로 들어갔는지 확인합니다. 토큰 한도에 맞추는 과정에서 중요한 문단이 잘리거나, 중복 청크가 공간을 차지할 수 있습니다. 상위 결과 개수를 늘리는 실험도 무조건 정답률을 높이지 않습니다. 관련 없는 문서가 더 많이 섞이면 모델이 근거를 혼동할 수 있으므로 top-k와 재정렬 기준을 작은 테스트 세트에서 함께 비교해야 합니다.

문서 안의 지시문을 사용자 지시처럼 따르는 문제도 별도 위험입니다. 검색 문서는 신뢰할 수 없는 자료로 취급하고, 답변은 근거가 부족할 때 “자료에서 확인되지 않음”으로 종료하도록 설계하세요. 답변이 문서에 의해 뒷받침되는지 평가할 때는 정답률뿐 아니라 인용 정확성과 무응답의 적절성도 기록합니다.

5. 배포 전 체크리스트

관찰 증상먼저 볼 곳다음 실험
관련 문서가 없음수집·파싱·필터·색인원문과 색인 레코드 대조
관련 문서는 있으나 순위가 낮음질의·청킹·검색 방식키워드/의미 검색과 재정렬 비교
근거가 프롬프트에 없음문맥 조립·토큰 제한잘림 위치와 중복 제거 확인
근거가 있는데 답변이 빗나감지시문·인용·검증답변 기준과 무응답 테스트

평가 기준은 평균 점수 하나로 끝내지 마세요. 관련 문서가 상위에 잡히는 비율, 답변의 근거 일치, 인용 정확성, 문서에 답이 없을 때의 거절을 따로 추적하면 어떤 변경이 실제 개선인지 알 수 있습니다. OpenAI API로 분석 결과를 검증하는 흐름은 ChatGPT 데이터 분석 결과 검증 방법을 참고해 재현 가능한 표로 남길 수 있습니다.

공식 출처

원인을 찾을 때는 검색 결과, 문맥, 생성 순으로 한 구간씩 바꾸고 같은 테스트 질문으로 다시 비교하세요. 한 번에 여러 설정을 바꾸지 않아야 개선 원인을 알 수 있습니다.

 

댓글

댓글 쓰기

이 블로그의 인기 게시물

Copilot in Excel 데이터 분석: 표 정리부터 결과 검증까지

이미지
핵심: Copilot에 Excel 파일을 넣기 전에 범위가 표 형식인지, 각 열의 첫 행에 고유한 제목이 있는지, 빈 행과 병합 셀이 없는지 먼저 확인하세요. 분석을 요청한 뒤에는 결과 문장만 읽지 말고 근거가 된 열·행, 생성된 수식, 필터 조건을 원본과 대조해야 합니다. 기능과 이용 조건은 Microsoft 365 계정·라이선스·배포 상태에 따라 달라질 수 있습니다. 목차 분석 전 데이터 정리 Copilot에 분석 요청하기 결과를 확인하는 네 가지 방법 오류가 날 때 점검 순서 보안·기능 변경·공식 자료 Copilot이 제시한 분석 설명과 근거는 원본 셀·범위부터 대조하세요. 자료 기반 AI 답변의 출처 검증 흐름은 Gemini Notebook 출처 검증 가이드 에서, 조사 결과의 근거를 교차 확인하는 방법은 Gemini Deep Research 검증 가이드 에서 이어서 볼 수 있습니다. 분석 전 데이터 정리 Copilot의 답이 이상할 때는 프롬프트만 바꾸기 전에 워크북 구조부터 확인하세요. 첫 행은 열 이름으로 사용하고, 데이터는 한 행에 한 레코드가 오도록 맞춥니다. 날짜와 금액은 같은 열에서 형식을 통일하고, 중간 합계 행이나 빈 줄은 별도 표로 분리합니다. 병합 셀, 제목 위의 안내문, 여러 표가 한 범위에 섞인 상태는 분석 대상을 모호하게 만들 수 있습니다. 열 이름은 “매출”, “주문일”, “지역”처럼 의미를 분명히 적고 중복을 피합니다. 숫자 데이터 열에는 문자 메모를 섞지 말고, 결측값은 임의로 0으로 바꾸지 않습니다. 정의가 필요한 지표(순매출, 환불 제외 매출 등)는 표 옆에 기준을 기록합니다. 개인정보·고객 식별자·기밀 정보는 분석에 꼭 필요하지 않다면 삭제하거나 비식별화합니다. 정돈된 표는 질문 대상과 계산 범위를 명확하게 만듭니다. Copilot에 분석 요청하기 Copilot in Excel은 표를 요약하거나, 값의 패턴을 설명하거나, 새 계산 열과 시각화를 제안하는 데 활용할 수 있습니다. 화면에서 Copilot을 열고 분석할 ...
자세한 내용 보기

Claude Artifacts 사용법: 결과물 만들기·검수·공유 설정

이미지
먼저 답하면: Claude Artifacts는 긴 문서, 코드, 시각화처럼 대화창과 분리해 보고 수정할 결과물을 만드는 작업 공간입니다. 첫 결과를 바로 공유하기보다 요구사항·기능·모바일 표시·공개 범위를 점검하고, 공유 링크가 누구에게 열리는지 확인하세요. 실행형 결과물은 실제 운영 서비스나 보안 검토를 대체하지 않습니다. 목차 Artifact가 적합한 작업 프롬프트부터 수정까지 프로토타입 검수표 공유와 공개 범위 제한·보안과 공식 자료 대화와 별도 작업 공간에서 문서·코드를 반복 수정하는 흐름은 ChatGPT Canvas 문서·코드 편집 가이드 와 비교해 볼 수 있습니다. 반복 작업에 사용할 고정 지침을 정리하려면 Gemini Gems 지침 설계 방법 도 함께 참고하세요. Artifact가 적합한 작업 Artifact는 Claude가 대화 안에서 만든 긴 결과물을 별도 패널에 보여 주는 기능입니다. 문서 초안, 코드, 차트, 간단한 인터랙티브 화면처럼 대화 내용과 결과물 자체를 함께 검토해야 할 때 편리합니다. 다만 기능이 노출되는지와 실행·공유 옵션은 계정·요금제·조직 설정 및 제품 변경에 따라 다를 수 있습니다. 적합한 예는 사내에서 검토할 수 있는 업무 체크리스트, 정적 안내 페이지의 초기 시안, 작은 데이터 시각화입니다. 결제·로그인·고객 데이터 저장, 외부 API를 이용한 실제 서비스처럼 안전성·권한·유지보수가 필요한 기능은 Artifact 시안만으로 출시하지 마세요. 이런 경우 요구사항 정의나 화면 흐름을 검토하는 프로토타입으로 범위를 제한하고, 실제 구현은 별도로 설계해야 합니다. Artifact는 결과물과 대화를 오가며 설계 의도를 확인할 때 유용합니다. 프롬프트부터 수정까지 사용자와 작업 정의: “누구의 어떤 문제를 해결하는가”를 한 문장으로 씁니다. 예: “신입 직원이 출장비 정산 규정을 빠르게 확인하는 내부 검토용 안내 화면.” 필수·제외 기능 나누기: 반드시 필요한 입력·출력과 이번 시안에 포함하지 않을 기능(로그인, 실제 저장,...
자세한 내용 보기

AI 답변 품질 평가표: 정확성·근거·재현성 점검법

이미지
생성형 AI의 답변을 평가할 때 “그럴듯하다”는 느낌만으로는 부족합니다. 같은 질문을 다시 했을 때 결과가 얼마나 안정적인지, 핵심 주장을 근거로 확인할 수 있는지, 중요한 조건을 빠뜨리지 않았는지를 나눠 기록해야 개선 방향이 보입니다. 이 글의 점수표는 NIST AI Risk Management Framework의 측정·평가 관점을 참고해 만든 실무용 자체 도구이며, NIST 공식 점수나 인증 기준은 아닙니다. 정확성, 근거, 완전성, 명료성, 안전성을 따로 채점하면 막연한 인상을 줄일 수 있습니다. 먼저 기억할 점 한 번의 답변은 모델의 전반적 품질을 대표하지 않습니다. 질문 묶음, 기대 답안, 근거 자료, 반복 횟수를 고정하고 버전이나 설정이 달라질 때 같은 조건으로 비교하세요. 목차 무엇을 측정할까 비교 가능한 테스트 만들기 5개 항목 평가표 점수 수집과 해석 오류와 한계 다루기 자주 묻는 질문 1. 품질을 하나의 점수로 뭉치지 않기 정답을 맞혔더라도 출처를 꾸며냈거나 요청 형식을 무시했을 수 있습니다. 반대로 표현이 매끄럽지 않아도 사실관계는 정확할 수 있습니다. 따라서 정확성, 근거, 완전성, 명료성, 안전성을 독립된 항목으로 기록하고 총점과 함께 낮은 항목도 확인합니다. NIST AI RMF는 조직이 AI 위험을 맥락에 맞게 식별하고 측정하며 관리하도록 돕는 자발적 프레임워크입니다. 평가 결과는 사용 목적과 실패 비용에 따라 해석해야 하며, 단일 점수만으로 시스템이 안전하거나 적합하다고 결론 내리면 안 됩니다. 2. 재현 가능한 테스트 세트 만들기 사용 목적을 한 문장으로 고정: 예를 들어 “제품 매뉴얼에서 근거 문단을 찾아 고객 질문에 답한다”처럼 범위를 적습니다. 대표 질문을 구성: 흔한 질문, 모호한 질문, 근거가 없는 질문, 최신 정보 질문, 경계·안전 질문을 포함합니다. 시작은 20~30개로 하되 사용 로그에서 실패 유형을 보태세요. 기대 답안과 허용 범위를 작성: 정답 문자열 하나를 강요하기보다 반드시 포함할 사실, 허용 가능한 표...
자세한 내용 보기