TestForge Blog
← 전체 포스트
#ai #rag #prompt #llm #service

RAG 개발 4편 - 답변 생성, 프롬프트 설계, 출처 표시를 어떻게 만들까

검색이 끝났다고 RAG가 끝난 것은 아닙니다. 어떤 문서를 어떤 형식으로 LLM에 넣을지, 출처를 어떻게 표시할지, 모를 때는 어떻게 답하게 할지, 답변 생성 단계의 핵심 설계 포인트를 설명합니다.

TestForge Team ·

검색 이후가 더 중요할 때가 많다

RAG에서 검색 결과를 잘 가져와도, 답변 생성 단계가 약하면 사용자는 여전히 “그럴듯하지만 불안한 답”을 받게 됩니다.

실무에서 자주 나오는 문제:

  • 검색 문서는 맞는데 답변이 과장됨
  • 출처 링크가 없어서 검증이 어려움
  • 문서를 근거로 답하지 않고 일반 상식으로 답함
  • 근거가 부족한데도 단정적으로 말함

즉, retrieval과 generation은 분리해서 설계해야 합니다.

기본 구조

User Query
 -> Retrieved Context
 -> Context Selection / Compression
 -> Prompt Assembly
 -> LLM Generation
 -> Citation Formatting
 -> Final Answer

이 단계에서 중요한 것은 “LLM에게 문서를 주는 것”이 아니라 “LLM이 어떤 규칙으로 문서를 사용해야 하는지 명시하는 것”입니다.

프롬프트에 꼭 들어가야 할 요소

1. 역할

예:

너는 제품 문서를 기반으로 답변하는 기술 지원 어시스턴트다.

2. 근거 사용 규칙

반드시 제공된 문서를 근거로 답하라.
근거가 부족하면 추측하지 말고 부족하다고 말하라.

3. 답변 형식

답변은 요약 -> 상세 설명 -> 참고 문서 순으로 작성하라.

4. 불확실성 처리

검색 결과가 부족하거나 상충하면 단정하지 말고 확인이 필요하다고 안내하라.

이 규칙이 없으면 모델은 보통 친절하려고 빈칸을 상식으로 메웁니다.

context를 어떻게 넣을까

검색된 chunk를 그대로 전부 넣는 방식은 금방 한계가 옵니다.

고려할 점:

  • 너무 많은 chunk는 노이즈 증가
  • 중복 내용이 많으면 답변 편향
  • 긴 문서는 token 낭비

그래서 보통 아래처럼 정리합니다.

  • 상위 3~5개 chunk 선별
  • 같은 문서의 인접 chunk 병합
  • 문서 제목과 섹션명 포함
  • 필요 시 짧은 요약 압축

예:

[문서 1]
제목: 인증 API 가이드
섹션: 토큰 재발급
본문: refresh token이 유효하면 ...

[문서 2]
제목: 인증 오류 코드
섹션: 401 Unauthorized
본문: access token 만료 시 ...

이 구조가 있어야 모델이 각 문맥의 출처를 구분하기 쉽습니다.

citation은 처음부터 구조화하자

출처는 후처리로 대충 붙이면 일관성이 무너집니다.

권장 방식:

  • 각 chunk에 source_url, title, section, chunk_id 저장
  • 프롬프트 안에서 출처 번호 사용
  • 응답 후 번호를 링크로 변환

예:

[1] 인증 API 가이드 - 토큰 재발급
[2] 인증 오류 코드 - 401 Unauthorized

사용자가 직접 확인할 수 있는 출처가 있어야 RAG 시스템에 대한 신뢰가 생깁니다.

”모를 때 모른다고 말하기”는 어떻게 구현할까

이건 프롬프트 한 줄로 끝나지 않는 경우가 많습니다.

보통 아래를 같이 봅니다.

  • retrieval score threshold
  • 검색 결과 수
  • 문서 간 상충 여부
  • 답변 생성 전 confidence heuristic

예:

if not hits or hits[0].score < 0.45:
    return {
        "answer": "현재 제공된 문서만으로는 정확한 답변을 확인하기 어렵습니다.",
        "citations": []
    }

모델에게만 맡기지 말고, 애플리케이션 레벨에서도 fallback을 두는 편이 안전합니다.

답변 포맷은 용도에 맞게 다르게 설계하자

RAG 시스템은 모든 질문에 같은 스타일로 답할 필요가 없습니다.

고객지원형

  • 짧은 결론
  • 단계별 해결 방법
  • 관련 문서 링크

운영 가이드형

  • 증상
  • 원인
  • 진단 절차
  • 복구 절차

제품 문서형

  • 개념 설명
  • 예시
  • 제한사항
  • 참고 링크

서비스 용도에 따라 템플릿을 나누면 훨씬 일관된 응답을 만들 수 있습니다.

hallucination을 줄이는 실전 방법

문서 근거를 먼저 요약하게 하기

바로 최종 답변을 쓰게 하기보다, 먼저 근거를 정리하게 하면 도움이 됩니다.

직접 인용보다 근거 기반 설명을 유도하기

모델이 문서를 재구성하되 근거 범위를 넘지 않게 해야 합니다.

질문 범위를 벗어나지 않게 제한하기

관련 없는 일반 지식 확장을 막아야 합니다.

예:

질문과 직접 관련된 내용만 설명하라.
검색 문서에 없는 제품 기능은 언급하지 마라.

multi-turn 대화에서는 더 주의가 필요하다

이전 대화 문맥과 현재 검색 문서를 함께 넣을 때 충돌이 생길 수 있습니다.

예:

  • 이전 질문은 dev 환경
  • 현재 검색 문서는 prod 운영 가이드

이런 경우 컨텍스트를 섞으면 위험합니다.

따라서 대화형 RAG에서는 아래를 분리해서 다루는 편이 좋습니다.

  • 대화 요약 메모리
  • 현재 검색 문서
  • 사용자 현재 질문

응답 후처리도 중요하다

최종 응답 전에 점검할 것:

  • 출처가 실제로 존재하는가
  • 금지된 문구가 없는가
  • 민감정보가 포함되지 않았는가
  • 응답 길이가 너무 길지 않은가
  • 링크 형식이 정상인가

생성형 시스템은 출력 단계까지 품질 관리가 필요합니다.

마무리

RAG의 generation 단계는 단순한 프롬프트 작성이 아닙니다.

  • 어떤 문서를 넣을지 고르고
  • 어떤 규칙으로 답하게 할지 정하고
  • 출처를 구조화하고
  • 불확실할 때 안전하게 멈추게 만들어야 합니다

다음 글에서는 이 전체 시스템을 어떻게 평가하고, 무엇을 측정하며, 운영 중 어떤 로그와 지표를 봐야 하는지 정리하겠습니다.