RAG(검색 증강 생성) 시스템을 구축하고 처음 질문을 던지는 순간, 대부분은 꽤 높은 기대를 품습니다. 내 자료를 통째로 넣었으니 AI가 무엇이든 척척 찾아 답해줄 거라 생각하죠. 그런데 막상 써보면 현실은 좀 다릅니다. 분명 문서에 있는 내용인데 “관련 정보를 찾을 수 없습니다”라고 하거나, 아예 문서에 없는 내용을 그럴듯하게 지어내는 경우도 생깁니다. 이쯤 되면 RAG라는 기술 자체가 아직 미완성인 건 아닌지 의심이 들기도 합니다.
하지만 결론부터 말씀드리면, RAG는 설치만 하면 끝나는 기술이 아닙니다. 카메라를 샀다고 바로 멋진 사진이 찍히지 않듯, RAG도 상황에 맞게 세팅을 조정해야 제 성능을 발휘합니다. 실제로 같은 문서 세트, 같은 AI 모델을 쓰더라도 몇 가지 핵심 설정을 바꾸면 답변 정확도가 눈에 띄게 달라집니다. 이 글에서는 RAG 답변이 자꾸 빗나가서 답답했던 분들을 위해, 지금 당장 적용할 수 있는 다섯 가지 실전 튜닝법을 하나씩 살펴보겠습니다.
RAG 답변이 엉뚱해지는 세 가지 근본 원인
튜닝 방법을 알아보기 전에, 먼저 왜 RAG가 엉뚱한 답변을 내놓는지 원인을 정확히 이해해야 합니다. 원인을 모르면 아무리 이것저것 바꿔봐도 헛수고가 되기 쉽거든요. RAG 시스템에서 부정확한 답변이 나오는 경로는 크게 세 가지로 나뉩니다.
첫째, 검색 실패
사용자가 질문했을 때 벡터 데이터베이스에서 관련 문서 조각을 제대로 찾아오지 못하는 경우입니다. 예를 들어 “올해 마케팅 예산이 얼마야?”라고 물었는데, 시스템이 마케팅 전략에 대한 문서만 가져오고 정작 예산 수치가 담긴 표가 있는 문서는 놓치는 식입니다. 이렇게 되면 AI가 아무리 똑똑해도 정답을 만들어낼 수 없습니다. 없는 재료로 요리를 할 수는 없으니까요.
둘째, 컨텍스트 오염
검색 자체는 되었는데, 관련 없는 문서 조각이 함께 섞여 들어오는 경우입니다. 예를 들어 2024년 실적을 물었는데 2022년 데이터와 2024년 데이터가 뒤섞여서 AI에게 전달되면, AI는 어떤 숫자가 맞는 건지 혼란에 빠집니다. 결과적으로 두 해의 데이터를 뒤죽박죽 섞어서 답하거나, 엉뚱한 연도의 데이터를 정답으로 제시하게 됩니다.
셋째, 생성 환각
검색 결과는 적절하게 들어왔는데, AI가 그 내용을 잘못 해석하거나 없는 내용을 추론해서 지어내는 현상입니다. 특히 문서에 “A일 수도 있고 B일 수도 있다”처럼 모호한 표현이 있으면, AI가 이를 단정적으로 “A다”라고 변환해버리는 일이 흔합니다. 이게 바로 흔히 말하는 ‘할루시네이션(환각)’인데, RAG를 쓰면 완전히 사라질 거라 기대했다가 실망하시는 분들이 많습니다. RAG가 환각을 크게 줄여주는 건 맞지만, 완전히 제거하려면 추가적인 장치가 필요합니다.
이 세 가지 원인 중 어디에서 문제가 생기는지 파악하는 것이 튜닝의 출발점입니다. 검색 자체가 안 되는 건지, 잘못된 정보가 딸려오는 건지, 아니면 AI가 답변을 생성하는 과정에서 왜곡되는 건지를 먼저 진단하세요. 가장 쉬운 방법은 시스템이 어떤 문서 조각을 참조했는지 로그를 확인하는 것입니다. 대부분의 RAG 도구에는 참조 소스를 보여주는 기능이 있으니, 그걸 켜두고 답변마다 어떤 문서가 끌려왔는지 확인해보면 원인이 보이기 시작합니다.
튜닝 1: 문서 청킹 전략을 상황에 맞게 바꾸기
RAG의 정확도를 가장 극적으로 바꿀 수 있는 첫 번째 레버는 바로 문서 청킹(chunking) 전략입니다. 청킹이란 긴 문서를 작은 조각(chunk)으로 나누는 과정을 말합니다. 벡터 데이터베이스에 문서를 넣을 때 문서 전체를 하나의 덩어리로 넣는 게 아니라, 적절한 크기로 잘라서 넣어야 하거든요. 이 “적절한 크기”가 바로 RAG 성능의 핵심 변수입니다.
고정 길이 청킹의 한계
가장 기본적인 방법은 500자, 1000자처럼 고정된 글자 수로 자르는 겁니다. 구현이 간단해서 많은 도구가 기본값으로 사용하는데, 이 방식에는 치명적인 문제가 있습니다. 의미의 경계를 무시하고 기계적으로 자르기 때문에, 하나의 완결된 내용이 두 조각으로 찢어지는 일이 빈번하게 발생합니다.
예를 들어 “2025년 1분기 매출은 전년 대비 15% 증가하여 42억 원을 기록했습니다. 이는 신제품 A의 출시 효과가 주된 원인으로”라는 문장이 정확히 청크 경계에 걸리면, 앞 청크에는 “42억 원을 기록했습니다”까지만, 뒤 청크에는 “이는 신제품 A의 출시 효과가 주된 원인으로”부터 시작하는 식으로 잘립니다. 나중에 “1분기 매출 증가 원인이 뭐야?”라고 물으면, 시스템이 뒤 청크만 가져와서 맥락 없이 답하거나, 아예 관련 정보를 못 찾을 수도 있습니다.
의미 단위 청킹으로 바꾸기
이 문제를 해결하는 가장 효과적인 방법은 의미 단위로 청킹하는 것입니다. 문서의 구조를 활용해서 자연스러운 단위로 나누는 방식이죠. 구체적으로는 다음과 같은 전략을 쓸 수 있습니다.
- 문단 기반 청킹: 빈 줄이나 들여쓰기로 구분되는 문단을 하나의 청크로 삼습니다. 대부분의 글은 문단 하나가 하나의 의미 단위를 이루므로, 가장 자연스러운 분할 방법입니다.
- 제목 기반 청킹: 마크다운이나 HTML의 제목 태그(h1, h2, h3)를 경계로 삼아 섹션 단위로 나눕니다. 기술 문서나 매뉴얼처럼 계층 구조가 명확한 문서에 효과적입니다.
- 시맨틱 청킹: AI 임베딩을 활용해 문장 간 의미 유사도를 계산하고, 의미가 크게 전환되는 지점에서 자르는 고급 방법입니다. 구현이 복잡하지만 정확도가 가장 높습니다.
오버랩 설정의 중요성
어떤 청킹 전략을 쓰든 반드시 설정해야 하는 것이 오버랩(overlap)입니다. 청크와 청크 사이에 일부 내용을 겹치게 만드는 건데, 이것 하나만 제대로 설정해도 답변 품질이 눈에 띄게 좋아집니다. 오버랩이 없으면 청크 경계에서 맥락이 끊기지만, 앞뒤 50~100자 정도를 겹치게 설정하면 경계 근처의 정보도 양쪽 청크에서 접근할 수 있게 됩니다.
일반적으로 청크 크기의 10~20% 정도를 오버랩으로 설정하는 것이 좋습니다. 예를 들어 청크 크기가 500자라면 50~100자 정도의 오버랩을 주는 식이죠. 너무 많이 겹치면 같은 내용이 여러 번 검색되어 효율이 떨어지고, 너무 적으면 오버랩의 효과가 미미합니다.
문서 유형별 맞춤 전략
모든 문서에 같은 청킹 전략을 적용하는 것도 흔한 실수입니다. 문서의 성격에 따라 최적의 청킹 방법이 다르거든요.
- 보고서, 논문: 제목 기반 + 문단 기반 혼합이 효과적입니다. 섹션 제목을 메타데이터로 보존하면 검색 정확도가 올라갑니다.
- FAQ, Q&A 문서: 질문-답변 쌍을 하나의 청크로 유지하는 것이 핵심입니다. 질문과 답변이 다른 청크로 분리되면 RAG가 제대로 작동하지 않습니다.
- 표(테이블) 포함 문서: 표는 가급적 통째로 하나의 청크에 넣어야 합니다. 표의 헤더와 데이터 행이 분리되면 숫자를 정확히 읽어낼 수 없게 됩니다.
- 법률 문서, 계약서: 조항 단위로 청킹하되, 정의 조항(“본 계약에서 OO란…”)은 관련 조항의 청크에 함께 포함하거나 메타데이터로 첨부합니다.
- 채팅 로그, 회의록: 시간 단위 또는 주제 전환 지점 기준으로 청킹합니다. 발화자 정보를 메타데이터로 보존해야 “누가 말했는지”에 대한 질문에도 답할 수 있습니다.
청킹 전략을 바꾸는 것만으로 RAG 정확도가 20~40% 향상되는 사례가 보고되고 있을 만큼, 이 단계는 투자 대비 효과가 가장 큰 최적화입니다. 현재 고정 길이 청킹을 쓰고 있다면, 의미 단위 청킹으로 바꾸는 것을 첫 번째 튜닝으로 강력히 권합니다.
튜닝 2: 임베딩과 검색 파라미터를 정밀하게 조정하기
문서를 잘 쪼갰다면, 다음은 검색 단계를 최적화할 차례입니다. RAG에서 검색은 사용자의 질문과 가장 관련 높은 문서 조각을 찾아오는 과정인데, 여기에 영향을 미치는 주요 파라미터가 몇 가지 있습니다.
임베딩 모델 선택이 반은 먹고 들어간다
임베딩이란 텍스트를 숫자 벡터로 변환하는 과정입니다. 질문과 문서를 모두 벡터로 바꾼 뒤, 벡터 간 거리가 가까운 것들을 “관련 있는 문서”로 판단하는 것이 벡터 검색의 원리입니다. 따라서 이 변환을 어떤 모델로 하느냐가 검색 품질을 크게 좌우합니다.
2026년 현재 한국어 RAG에서 주로 사용되는 임베딩 모델은 크게 세 부류입니다.
- 다국어 범용 모델: OpenAI의 text-embedding-3-large나 Cohere의 embed-multilingual 같은 클라우드 API 기반 모델입니다. 설정이 간편하고 성능이 안정적이지만, API 호출 비용이 발생합니다.
- 한국어 특화 오픈소스 모델: KoSimCSE, KR-SBERT 등 한국어에 최적화된 오픈소스 임베딩 모델입니다. 로컬에서 무료로 실행할 수 있고, 한국어 고유 표현이나 줄임말에 강점이 있습니다.
- 최신 범용 오픈소스 모델: BGE, E5, GTE 시리즈 등 영어권에서 개발되었지만 다국어 성능이 우수한 모델입니다. 특히 최신 버전들은 한국어 벤치마크에서도 높은 점수를 기록합니다.
어떤 모델이 내 상황에 가장 맞는지는 직접 테스트해보는 수밖에 없습니다. 가장 좋은 방법은 실제로 자주 들어올 질문 20~30개를 미리 만들어두고, 각 질문에 대해 어떤 문서 조각이 검색되어야 정답인지 정의한 뒤, 모델별로 정답을 얼마나 잘 찾아오는지 비교하는 것입니다. 이걸 “검색 평가 세트(retrieval evaluation set)”라고 하는데, 처음에 만드는 수고가 좀 들지만 이후 모든 튜닝의 기준점이 되어줍니다.
Top-K 값 조정
Top-K는 검색 결과에서 상위 몇 개의 청크를 AI에게 전달할지 정하는 파라미터입니다. 기본값이 3인 도구도 있고, 5나 10인 도구도 있는데, 이 값을 무작정 높이거나 낮추면 오히려 역효과가 납니다.
Top-K가 너무 작으면 정답이 담긴 청크가 잘릴 위험이 있고, 너무 크면 관련 없는 청크가 섞여 들어와서 AI가 혼란에 빠집니다. 경험적으로 대부분의 경우 Top-K를 4~6 정도로 설정하는 것이 균형 잡힌 시작점입니다. 이후 답변 품질을 보면서 점진적으로 조정하면 됩니다.
한 가지 팁을 더 드리자면, Top-K를 늘리는 대신 유사도 임계값(similarity threshold)을 함께 설정하는 것이 효과적입니다. 예를 들어 “Top-K는 8로 넉넉하게 잡되, 유사도 점수가 0.7 미만인 청크는 제외”라고 설정하면, 관련 정보가 많을 때는 충분히 가져오되 관련 없는 청크는 걸러낼 수 있습니다.
하이브리드 검색으로 빈틈 메우기
벡터 검색만으로는 놓치는 정보가 있습니다. 특히 고유명사, 제품 코드, 날짜 같은 키워드는 의미적으로는 유사하지 않지만 정확히 일치해야 하는 경우가 많습니다. “PX-4820 제품의 불량률”을 물었을 때, 벡터 검색은 “불량률”의 의미에 맞는 문서는 잘 찾지만 “PX-4820″이라는 정확한 코드가 포함된 문서를 놓칠 수 있습니다.
이런 문제를 해결하는 방법이 하이브리드 검색입니다. 전통적인 키워드 검색(BM25)과 벡터 검색을 결합해서, 의미적 유사성과 키워드 일치를 동시에 고려하는 것이죠. 대부분의 벡터 데이터베이스(Weaviate, Qdrant, Milvus 등)와 RAG 프레임워크(LangChain, LlamaIndex 등)가 하이브리드 검색 모드를 지원하니, 아직 안 써봤다면 한번 켜보시길 권합니다. 체감 효과가 상당합니다.
튜닝 3: 리랭킹으로 검색 결과의 순서를 재정렬하기
청킹과 검색 파라미터를 최적화한 뒤에도 답변이 만족스럽지 않다면, 리랭킹(reranking)이라는 강력한 무기가 있습니다. 리랭킹은 1차 검색으로 가져온 후보 청크들을 한 번 더 정밀하게 평가해서 순서를 재배치하는 과정입니다.
왜 1차 검색만으로는 부족한가
벡터 검색은 빠르지만 정밀하지는 않습니다. 질문과 문서를 각각 독립적으로 벡터로 변환한 뒤 거리를 비교하기 때문에, 미묘한 맥락 차이를 놓치는 경우가 있습니다. 예를 들어 “A 회사가 B 회사를 인수한 금액”과 “B 회사가 A 회사를 인수한 금액”은 벡터 공간에서 매우 가까운 위치에 놓이지만, 실제로는 완전히 다른 정보를 묻고 있습니다.
리랭킹에 사용되는 Cross-encoder 모델은 질문과 문서 청크를 함께 하나의 입력으로 넣어서 관련도를 판단합니다. 이 방식은 벡터 검색보다 훨씬 정교하게 맥락을 이해할 수 있지만, 연산 비용이 높아서 모든 문서에 적용하기는 어렵습니다. 그래서 1차 벡터 검색으로 넓게 후보를 뽑고(Top-K를 넉넉하게, 예: 20개), 리랭커로 이 중 가장 관련 높은 것들만 추려내는(예: 상위 5개) 두 단계 파이프라인을 구성하는 것이 일반적인 패턴입니다.
리랭킹 적용 방법
리랭킹을 적용하는 가장 쉬운 방법은 Cohere Rerank API를 사용하는 것입니다. API 호출 한 줄로 리랭킹 기능을 추가할 수 있어 진입 장벽이 낮습니다. 오픈소스로는 cross-encoder/ms-marco-MiniLM이나 BGE-reranker 시리즈가 인기 있는데, 로컬 GPU가 있다면 무료로 사용할 수 있습니다.
LangChain이나 LlamaIndex 같은 프레임워크를 사용 중이라면, 파이프라인에 리랭커 노드를 하나 추가하는 것만으로 설정이 끝납니다. 코드로 치면 검색 결과를 가져온 뒤 리랭커에 한 번 더 통과시키는 단 두세 줄의 코드 추가입니다. 이 작은 변경이 체감 정확도를 크게 끌어올리는 경우가 많으니, 비용 대비 효과로 따지면 가장 추천하는 튜닝 중 하나입니다.
튜닝 4: 시스템 프롬프트와 컨텍스트 구성 최적화
검색 파이프라인을 다듬었다면, 이제 AI가 답변을 생성하는 단계를 최적화할 차례입니다. 같은 검색 결과를 받아도 AI에게 어떤 지시를 주느냐에 따라 답변의 정확도와 형태가 크게 달라집니다.
효과적인 시스템 프롬프트 작성법
RAG 시스템의 시스템 프롬프트는 일반적인 챗봇과는 다르게 작성해야 합니다. 핵심은 AI에게 “제공된 컨텍스트만 근거로 답변하라”는 제약을 명확히 거는 것입니다. 이것 하나만 제대로 해도 환각이 크게 줄어듭니다.
실전에서 효과가 검증된 시스템 프롬프트의 핵심 요소를 정리하면 다음과 같습니다.
- 역할 명시: “당신은 제공된 문서를 기반으로 질문에 답변하는 어시스턴트입니다.” 이렇게 역할을 한정하면 AI가 외부 지식에 의존하는 경향이 줄어듭니다.
- 근거 제약: “아래 제공된 문서 조각에 있는 정보만을 사용해서 답변하세요. 문서에 없는 내용은 추측하지 마세요.” 이 지시가 빠지면 AI가 자체 학습 데이터를 섞어서 답변합니다.
- 불확실성 표현 허용: “제공된 문서에서 질문에 대한 답을 찾을 수 없는 경우, 솔직하게 ‘제공된 문서에서는 해당 정보를 찾을 수 없습니다’라고 답하세요.” 이 지시가 없으면 AI는 뭐라도 답하려고 내용을 지어냅니다.
- 출처 표기 강제: “답변 시 참조한 문서의 제목이나 페이지 번호를 함께 언급하세요.” 출처를 표기하게 하면 AI가 더 신중하게 답변하는 효과가 있고, 사용자도 답변을 검증할 수 있습니다.
컨텍스트 윈도우 활용 최적화
AI 모델에는 한 번에 처리할 수 있는 텍스트 양의 한계가 있습니다. 이를 컨텍스트 윈도우라고 하는데, 이 공간을 어떻게 구성하느냐도 답변 품질에 영향을 미칩니다.
검색된 청크를 AI에게 전달할 때 가장 관련 높은 청크를 먼저 배치하는 것이 좋습니다. AI 모델은 입력의 앞부분과 뒷부분에 더 많은 주의를 기울이는 경향이 있어서, 중간에 핵심 정보가 묻히면 놓칠 수 있거든요. 또한 각 청크에 출처 정보(문서명, 페이지 등)를 명시적으로 태깅해서 넣으면, AI가 어떤 정보가 어디서 왔는지 구분하기 쉬워집니다.
청크 사이에 구분자를 넣는 것도 효과적입니다. 단순히 청크를 이어 붙이면 AI가 서로 다른 문서의 내용을 하나의 맥락으로 착각할 수 있습니다. “—문서 1—“, “—문서 2—” 같은 명확한 구분자를 넣어주면 이런 혼동을 방지할 수 있습니다.
질문 유형별 프롬프트 분기
한 걸음 더 나아가면, 질문의 유형에 따라 다른 프롬프트를 적용하는 전략도 있습니다. 예를 들어 단순 사실 확인 질문(“A의 가격은?”)과 비교·분석 질문(“A와 B의 차이점은?”), 요약 요청(“이 보고서의 핵심을 정리해줘”)은 AI에게 요구하는 답변 방식이 다릅니다.
사실 확인 질문에는 “정확한 수치나 사실만 간결하게 답하세요”라는 지시가, 비교 질문에는 “공통점과 차이점을 구분하여 표 형식으로 답하세요”라는 지시가, 요약 요청에는 “핵심 포인트를 불릿 포인트로 정리하세요”라는 지시가 각각 더 나은 결과를 만들어냅니다. 질문 분류 자체도 AI에게 맡길 수 있어서, 파이프라인 앞단에 질문 유형을 분류하는 작은 단계를 하나 두면 전체 답변 품질이 올라갑니다.
튜닝 5: 피드백 루프를 만들어 지속적으로 개선하기
마지막 다섯 번째 튜닝은 단일 기법이라기보다 시스템 운영 철학에 가깝습니다. RAG 시스템은 한 번 세팅하고 끝나는 것이 아니라, 사용하면서 계속 개선해 나가야 하는 살아있는 시스템입니다.
실패 케이스를 체계적으로 수집하기
가장 먼저 할 일은 답변이 틀렸거나 불만족스러웠던 사례를 기록하는 것입니다. 간단하게는 스프레드시트에 질문, 시스템 답변, 기대 답변, 실패 원인 추정을 적어두는 것만으로도 충분합니다. 이 기록이 쌓이면 패턴이 보이기 시작합니다.
예를 들어 “표에 있는 숫자를 물으면 자주 틀린다”는 패턴이 보이면 표 처리 청킹 전략을 개선하면 되고, “최근 문서보다 오래된 문서를 더 자주 참조한다”는 패턴이 보이면 메타데이터에 날짜 정보를 추가하고 최신 문서에 가중치를 주면 됩니다.
평가 세트 만들고 정기적으로 측정하기
앞서 임베딩 모델 선택 부분에서도 잠깐 언급했지만, 평가 세트(evaluation set)를 만드는 것이 정말 중요합니다. 30~50개의 대표 질문과 각 질문에 대한 정답, 그리고 그 정답이 포함된 문서 조각을 정리해두세요. 이 평가 세트로 현재 시스템의 정확도를 숫자로 측정할 수 있습니다.
측정해야 할 주요 지표는 두 가지입니다.
- 검색 정확도(Retrieval Accuracy): 정답이 포함된 문서 청크가 Top-K 안에 포함되는 비율. 이 수치가 낮으면 검색 단계(청킹, 임베딩, 검색 파라미터)를 개선해야 합니다.
- 답변 정확도(Answer Accuracy): AI가 생성한 답변이 정답과 일치하는 비율. 검색 정확도는 높은데 답변 정확도가 낮으면 프롬프트나 모델 선택을 개선해야 합니다.
이 두 지표를 분리해서 보면 문제가 검색 단계에 있는지 생성 단계에 있는지 명확하게 진단할 수 있습니다. 뭔가를 변경할 때마다 평가 세트를 돌려보면 그 변경이 실제로 도움이 되었는지 객관적으로 확인할 수 있고, 감이 아닌 데이터에 기반한 튜닝이 가능해집니다.
문서가 바뀌면 인덱스도 갱신하기
의외로 많은 분들이 놓치는 부분인데, RAG 시스템에 넣은 원본 문서가 업데이트되었을 때 벡터 인덱스도 함께 갱신해야 합니다. 회사 내규가 바뀌었는데 예전 내규가 여전히 인덱스에 남아 있으면, AI가 구버전 정보로 답변하게 됩니다. 정기적으로(주 1회 또는 문서 변경 시) 인덱스를 갱신하는 프로세스를 만들어두는 것이 좋습니다.
더 나아가면, 문서 버전 관리 시스템과 RAG 인덱스를 연동해서 문서가 변경되면 자동으로 해당 청크만 재처리하는 자동화 파이프라인을 구축할 수도 있습니다. 이 정도까지 가면 사실상 문서가 살아 숨 쉬는 지식 시스템이 완성되는 셈이죠.
사용자 피드백을 시스템에 반영하기
시스템을 여러 사람이 사용하는 환경이라면, 간단한 피드백 장치를 마련해두는 것도 효과적입니다. 답변 아래에 “도움이 되었나요?” 버튼을 두거나, 틀린 답변을 신고하는 기능을 넣으면 됩니다. 이렇게 모인 피드백 데이터는 평가 세트를 보강하는 데 활용할 수 있고, 어떤 유형의 질문에서 시스템이 약한지 파악하는 데에도 큰 도움이 됩니다.
봄은 새 학기, 새 프로젝트가 시작되는 시기인 만큼 팀이나 조직에서 새로운 지식 관리 체계를 도입하기 좋은 때이기도 합니다. RAG 시스템을 이 시기에 제대로 세팅해두면, 연중 내내 팀의 생산성을 높이는 든든한 도구가 되어줄 것입니다.
마무리: 작은 튜닝이 큰 차이를 만든다
지금까지 RAG 답변 정확도를 높이는 다섯 가지 실전 튜닝법을 살펴보았습니다. 정리하면 다음과 같습니다.
- 청킹 전략 최적화: 고정 길이 대신 의미 단위로 자르고, 오버랩을 설정하고, 문서 유형에 맞춤 적용.
- 임베딩과 검색 파라미터 조정: 적합한 임베딩 모델 선택, Top-K와 유사도 임계값 설정, 하이브리드 검색 도입.
- 리랭킹 적용: 1차 검색 후 Cross-encoder로 재정렬하여 정밀도 향상.
- 프롬프트와 컨텍스트 최적화: 근거 제약, 불확실성 표현, 출처 표기를 시스템 프롬프트에 반영.
- 피드백 루프 구축: 실패 사례 수집, 평가 세트 운영, 정기 인덱스 갱신.
이 다섯 가지를 모두 한꺼번에 적용할 필요는 없습니다. 현재 시스템의 가장 큰 병목이 어디인지 파악하고, 거기서부터 하나씩 개선해 나가는 것이 현실적인 접근입니다. 보통은 청킹 전략 변경 → 하이브리드 검색 도입 → 시스템 프롬프트 개선 순서로 진행하면 가성비 좋게 정확도를 끌어올릴 수 있습니다.
RAG는 완벽한 기술이 아니라 지속적으로 다듬어 나가는 기술입니다. 하지만 그 다듬는 과정 자체가 어렵거나 전문 개발자만의 영역은 아닙니다. 오늘 소개한 방법들은 대부분 RAG 프레임워크의 설정값을 바꾸거나, 프롬프트 텍스트를 수정하는 수준으로 적용할 수 있습니다. 한 번에 하나씩, 변경 전후의 차이를 확인하면서 천천히 나아가다 보면 어느새 내 문서에 정확하게 답변하는 든든한 AI 어시스턴트가 완성되어 있을 것입니다.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.