RAG 5분만에 설명해드림 - RAG가 뭔지 모르면 AI 답변은 전부 틀릴 수 있습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

RAG는 필요한 자료를 찾아 AI 답변의 근거로 붙이는 방식이며, 이를 썼다는 사실만으로 답을 믿지 말고 원문부터 최종 답변까지 확인해야 한다.

📌 핵심 요점

1. RAG는 질문에 필요한 문서를 검색해 그 본문을 질문과 함께 모델에 전달한다. 회사 문서를 모델에 새로 학습시키는 과정과는 다르다.
2. 문서를 청크로 나눌 때는 의미를 유지해야 한다. 예제의 결제 API V2·429 응답·재시도 3회처럼 버전, 적용 조건, 규칙을 함께 보존하고 출처를 메타데이터로 붙인다.
3. 벡터 검색은 필수가 아니다. 영상은 키워드 검색으로 구현하며, 벡터 검색과 두 방식을 함께 쓰는 방법도 소개한다. 검색 점수는 후보 비교 기준이고 정답일 확률이 아니다.
4. 검색 결과와 실제로 모델에 보내는 근거는 구분된다. 후보 중 질문에 맞는 본문을 선택하고 질문·답변 지시·근거를 묶어 요청을 구성한다. 근거가 부족하면 확인할 수 없다고 답하게 한다.
5. 검증 대상은 원본, 선택한 검색 근거, 실제 요청, 최종 답변의 네 곳이다. 버전 혼동, 색인 갱신 누락, 조건 누락을 점검하고 회사 문서의 접근 권한과 웹 문서의 프롬프트 인젝션도 처리해야 한다.

🧩 배경과 문제 정의

모델이 회사의 특정 문서와 최신 규칙을 알고 있다고 기대하는 대신, 질문에 필요한 자료를 찾아 입력에 함께 넣는 것이 영상이 설명하는 RAG의 출발점이다. 문제는 검색 결과가 존재한다고 해서 그 자료가 질문에 맞거나 최신이라는 보장이 없다는 데 있다.

영상은 결제 API의 버전별 재시도 규칙을 예제로 사용해 문서 준비, 검색, 근거 선택, 요청 구성, 답변 검증을 연결한다. 약 5분의 개념 설명 이후 코드와 문서를 살펴보는 실습으로 이어지며, 원본 문장의 조건이 각 단계에 유지되는지 추적하는 데 초점을 둔다.

🕒 시간순 섹션별 상세정리

1. RAG의 기본 개념과 음성 생성 시연

• RAG를 질문에 필요한 자료를 먼저 찾고 그 자료를 참고해 답을 만드는 방식으로 보여준다. 회사 문서를 청크로 나누고 관련 부분을 질문과 함께 모델에 보내는 흐름을 보여준다. [00:42]
• 검색한 문서가 틀리거나 오래되면 답도 틀릴 수 있으므로, 어떤 근거를 모델에 보냈는지 확인해야 한다고 강조한다. [00:56]
• 도입부 설명에 사용한 피시 오디오 드라마 3의 생성 음성을 소개하고 감정별 음성을 시연한 뒤 할인 내용을 안내한다. [01:38]

2. 문서 청킹과 검색 방식의 선택

• RAG는 회사 문서를 새로 학습시키는 과정이 아니며, 문서 준비와 질문 처리를 나누어 이해해야 한다. 청크는 필요한 부분만 보내 입력 길이와 비용을 고려하기 위한 단위다. [02:19]
• 청크를 너무 작게 나누면 의미를 잃는다. 결제 API V2라는 버전, 429 응답이라는 조건, 재시도 3회라는 규칙을 함께 남기고 출처와 버전을 붙여야 한다. [02:35]
• 단어와 청크를 연결하는 색인·포스팅 목록과 임베딩을 이용한 벡터 검색을 보여준다. 유사한 문서라도 버전별 규칙은 다를 수 있으며, 이번 실습은 키워드 검색으로 구현한다. [03:18]

3. 후보 검색부터 요청 구성과 검증까지

• 검색 점수와 버전 조건으로 후보를 고른다. Top K는 가져올 상위 후보 수를 정하는 값이며, 예제의 K가 3이라고 정답이 세 개라는 뜻은 아니다. 검색 점수도 정답 확률이 아니다. [03:51]
• 모델에는 점수만 보내는 것이 아니라 선택한 청크의 본문을 보낸다. 질문·답변 지시·근거를 묶고, 제공된 근거로 확인할 수 없으면 모른다고 답하도록 지시한다. [04:07]
• 인용 문장의 버전과 조건을 확인하고 원본·선택한 근거·실제 요청·최종 답변을 대조한다. 색인 갱신 누락과 회사 문서의 읽기 권한도 점검 대상으로 제시한다. [04:41]

4. 웹 RAG의 주의점과 실습 구조

• 웹 RAG는 검색한 페이지의 본문에서 관련 부분을 골라 근거로 사용한다. 출처 주소를 보관하고 공식 출처 여부, 문서 날짜, API 버전을 확인해야 한다. [05:22]
• 웹페이지에 모델의 행동을 바꾸려는 문장이 있어도 명령으로 따르지 않도록 처리해야 하며, 이를 프롬프트 인젝션 문제로 보여준다. [05:29]
• 실습은 마크다운 원본으로 진행하지만 PDF·워드·웹페이지·텍스트·데이터베이스도 원본이 될 수 있다고 보여준다. 핵심 처리 코드와 순차 실행 코드를 소개하고, 회사별 문서 특성에 맞춘 조정이 필요하다고 덧붙인다. [06:45]

5. 원본 규칙을 청크와 검색 결과에서 추적

• 근거를 주지 않은 모델이 정답을 맞힐 수도 있으므로, 정답 여부만으로 RAG 활용을 입증할 수는 없다. 원본의 V2·429 응답·재시도 3회가 청킹 후에도 함께 유지되는지 확인한다. [07:42]
• 청크로 색인을 만들고 저장한다. 원본을 수정해도 저장된 색인이 자동으로 바뀌는 것은 아니므로, 둘의 일치 여부를 확인하고 갱신 작업을 수행해야 한다. [08:21]
• 청크 식별자와 본문·출처·버전을 검색 결과에서도 대조한다. 필요한 청크가 없으면 청킹과 색인, 검색 조건을 확인하고, V2 필터로 다른 버전의 문서를 제외할 수 있다. [09:47]

6. 근거 선택과 버전 변경·색인 갱신 실험

• 검색 후보를 모두 보내는 대신 이번 질문에 필요한 재시도 규칙 본문을 선택한다. 선택한 본문과 출처·버전을 질문 및 답변 지시와 묶어 LLM 입력을 만든다. [10:30]
• 질문을 V2에서 V1으로 바꾸거나 같은 뜻을 다른 용어로 표현해 검색 결과를 점검한다. 질문에 맞지 않는 버전이 검색되는 경우를 실패로 보고 개선해야 한다. [11:06]
• 원문의 재시도 횟수만 3회에서 2회로 바꾸면 옛 색인은 여전히 3회를 전달할 수 있다. 색인과 갱신 시점을 함께 관리하고, 바뀐 규칙이 실제 요청과 최종 답변까지 전달되는지 대조한다. [11:59]

7. 답이 없는 질문의 처리와 오류 진단

• 환불 관련 청크가 검색되더라도 원본과 청크에 수수료 금액·비율이 없으면 수수료를 확인할 수 없다고 답하는 것이 정상이라고 보여준다. [12:31]
• 원본에 답이 없으면 자료를 보완하고, 원본의 답이 근거에서 빠졌으면 청킹·색인·필터·랭킹·선택 과정을 점검한다. 맞는 근거를 보냈는데 답이 다르면 요청 전달과 모델 성능을 확인한다. [13:12]
• 청킹부터 요청 구성과 디버깅까지의 내용을 정리하고 후속 설명 주제를 요청한다. 마지막으로 도입부 음성 생성 도구를 다시 안내하며 영상을 마친다. [13:44]

🧾 결론

• RAG의 핵심은 검색한 자료의 실제 본문을 모델 입력에 넣어 답변의 근거로 사용하는 데 있다.
• 출처가 붙었거나 모델이 정답을 말했다는 사실만으로 RAG가 제대로 작동했다고 판단할 수 없다. 올바른 근거가 요청과 답변까지 이어졌는지 확인해야 한다.
• 오류는 원본 자료 부족, 청킹·검색·근거 선택 실패, 요청 전달 또는 모델의 답변 생성 문제로 나누어 진단할 수 있다.
• 문서 변경에 맞춘 색인 갱신과 질문 변형을 통한 반복 점검이 운영 과정에 포함되어야 한다.

📈 투자·시사 포인트

• 기업의 RAG 도입을 평가할 때는 검색 기능의 존재와 함께 문서 버전 관리, 색인 갱신, 근거 추적이 구현되어 있는지 살펴볼 필요가 있다.
• 필요한 청크만 전달하는 설계는 모델의 입력 길이 제한과 불필요한 입력 비용을 고려한 선택이다. 청크를 지나치게 줄여 조건을 잃지 않도록 해야 한다.
• 범용 RAG도 회사별 문서 구조와 업무 특성에 맞춘 조정이 필요하다. 영상은 질문을 바꾸며 결과를 분석하는 과정을 개선 방법으로 제시한다.
• 회사 자료와 웹 자료를 활용하는 서비스에서는 문서 접근 권한, 출처의 적합성, 외부 문장에 의한 지시 변경 방지가 함께 검토되어야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목의 강한 경고를 모든 AI 답변이 틀린다는 뜻으로 일반화해서는 안 된다. 본문은 RAG를 사용해도 근거가 틀리거나 오래되면 답이 틀릴 수 있고, 근거 없이 모델이 정답을 맞힐 수도 있다고 설명한다.
• 결제 API V2의 429 응답과 재시도 3회, 이후 2회로 변경하는 내용은 실습 문서의 규칙이다. 실제 결제 API의 공통 정책으로 적용할 근거는 없다.
• 적절한 청크 크기, 검색 후보 수, 키워드·벡터 검색의 조합에 대한 정량 기준이나 성능 비교는 제공되지 않는다. 회사별 문서와 질문으로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 대표 질문의 원문에서 버전·조건·규칙을 확인하고, 청크에 세 요소와 출처 메타데이터가 함께 남아 있는지 대조한다.
• 검색 후보 목록과 실제 선택한 근거를 구분해 확인하고, 질문에 맞는 버전 필터가 적용되는지 점검한다.
• 원본 → 선택한 근거 → 실제 요청 → 최종 답변을 따라가며 규칙과 조건이 누락되거나 바뀌지 않았는지 확인한다.
• 원문 변경 후 색인을 갱신하고, 색인 생성·갱신 시점을 기록해 오래된 규칙이 전달되는지 검사한다.

❓ 열린 질문

• 우리 문서에서는 버전·적용 조건·규칙을 함께 보존하려면 어떤 단위로 청크를 나누어야 할까?
• 키워드 검색으로 놓치는 표현은 무엇이며, 벡터 검색이나 두 방식의 결합이 필요한 질문은 무엇일까?
• 문서 변경을 색인에 반영하는 주기와 갱신 시점 기록을 어떻게 운영할까?