AI 리터러시 스터디 · 06

RAG

모르는 건 찾아서 읽고,
근거를 대며 답하게 하기

청킹 · 검색 · 출처 검증

칼리즈 · 2026.10

오늘 끝까지 붙잡을 질문 하나

이 AI 답,
믿어도 될까?

1 자르기 청킹→ 2 찾기 검색→ 3 읽기 컨텍스트→ 4 확인 출처 검증

01 개념

지금의 LLM은
외워서 푸는 시험 중

작년 이후 일은 모름 지식 컷오프

우리 회사 규정은 본 적도 없음

모르면 그럴듯하게 지어냄 환각

01 개념

RAG = 오픈북 시험

문서 더미

규정, 보고서, 매뉴얼

→

지난 시간에 배운 두 개가
RAG의 재료다

토큰모델이 읽는 글자 조각

한 번에 읽을 수 있는 양(컨텍스트 윈도우)이 정해져 있다

그래서 문서를 통째로 못 넣고 골라서 넣는다

임베딩뜻을 숫자 좌표로

뜻이 비슷한 문장은 좌표가 가깝다

그래서 단어가 달라도 비슷한 문서를 찾는다

토큰 = 넣을 수 있는 양의 한계 · 임베딩 = 찾는 방법

본론 들어가기 전에 지난 회차랑 연결해 볼게. 지난번에 토큰이랑 임베딩을 배웠잖아. 이 두 개가 RAG의 재료야. 먼저 토큰. 모델은 글자를 토큰 단위로 읽고, 한 번에 읽을 수 있는 토큰 수, 즉 컨텍스트 윈도우가 정해져 있어. 요즘은 100만 토큰짜리도 있지만 그래도 회사 문서 전부를 매번 넣을 수는 없고, 넣을수록 비싸고 느려져. 그래서 질문에 필요한 부분만 골라서 넣어야 해. 이게 RAG가 필요한 첫 번째 이유야. 두 번째, 임베딩. 문장을 숫자 좌표로 바꾸면 뜻이 비슷한 문장끼리 가까이 모인다고 했지. 이 성질 덕분에 출장비라고 물어도 여비라고 쓰인 문서를 찾을 수 있어. 정리하면 토큰은 넣을 수 있는 양의 한계를 만들고, 임베딩은 그 한계 안에 뭘 넣을지 찾는 방법을 줘. 오늘 내용은 전부 이 두 개 위에 서 있어.

01 개념

준비는 미리, 찾기는 매번

미리문서가 바뀔 때

문서 모으기→ 자르기→ 색인 만들기

매번질문이 올 때

질문→ 찾기→ 고르기→ 답 + 출처

동그라미 친 세 군데가 오늘의 주인공

01 개념

틀린 답은 대부분
못 찾아서 생긴다

재료가 상하면
셰프가 누구든 요리는 망한다

잘못된 문서를 넣으면 좋은 모델일수록
자신 있게 틀린 답을 낸다

그래서 모델 바꾸기 전에 검색부터 본다

출처: DEV Community, RAG in 2026: Why Retrieval, Not the Model, Is the Bottleneck

02 역사

70년 된 아이디어,
이름은 2020년에

1957단어를 센다자주 나오는 단어가 주제

1972드문 단어가 중요IDF 등장

1990sBM25지금도 현역

2020RAG 탄생검색과 생성을 한 몸으로

2023한계 발견중간은 잘 안 읽음, 인용 부실

2026에이전트의 도구찾을 때까지 다시 찾기

출처: Manning 외, Introduction to Information Retrieval · A Systematic Review of Key RAG Systems (arXiv 2507.18910)

잠깐 역사를 보자. RAG라는 이름은 2020년에 붙었지만 뿌리는 70년 됐어. 1957년에 IBM의 Luhn이 문서에 자주 나오는 단어가 그 문서의 주제를 말해 준다는 아이디어를 냈어. 1960년대에 코넬의 Salton 팀이 문서와 질문을 같은 벡터 공간에 놓고 비교하는 SMART 시스템을 만들었고, 1972년에 Spärck Jones가 여러 문서에 흔한 단어는 덜 중요하고 드문 단어가 중요하다는 IDF를 냈어. 90년대에 이걸 다듬은 BM25가 나왔는데 지금도 현역이야. 2020년에 검색과 생성을 한 시스템으로 묶은 RAG가 나왔고, 2023년쯤 LLM이 퍼지면서 한계들이 발견됐어. 긴 글 중간은 잘 안 읽는다, 인용이 부실하다 같은. 그리고 지금 2026년에는 에이전트가 검색을 도구로 쓰면서 찾을 때까지 다시 찾는 형태가 됐어.

02 역사

2020년: 작은 모델 + 검색이
큰 모델을 이겼다

다 외울 필요가 없다는 게 증명됨

출처: Lewis 외 RAG, Karpukhin 외 DPR, Guu 외 REALM (모두 2020) · arXiv 2507.18910

02 역사

2026년: 검색은
에이전트의 도구

100만 토큰 시대에도 RAG는 안 죽고 모양만 바뀜

하이브리드 검색이 기본 기능
2026.09.09 Pinecone 정식 출시

출처: Anthropic, Effective context engineering for AI agents (2025.09) · AI Innovations and Insights 161 (2026.10)

그리고 지금 2026년의 모습이야. 예전 RAG는 한 번 검색하고 바로 답했다면, 지금은 에이전트가 검색을 도구로 써. 찾아본 다음 "이걸로 충분한가?"를 스스로 판단하고, 부족하면 질문을 바꿔서 다시 찾고, 충분해지면 출처를 달아서 답해. 이걸 에이전틱 RAG라고 불러. 작년에 컨텍스트 윈도우가 100만 토큰을 넘으면서 "이제 RAG는 필요 없다"는 말이 돌았는데 결과적으로 RAG는 안 없어졌고 모양만 바뀌었어. 그리고 키워드 검색이랑 의미 검색을 같이 쓰는 하이브리드 검색이 기본이 됐어. 9월 9일에 벡터 데이터베이스로 유명한 Pinecone도 키워드 검색을 같은 인덱스에 넣은 기능을 정식으로 냈어. 하이브리드는 조금 뒤에 자세히 볼 거야.

03 청킹

청킹 = 책을 몇 쪽씩
찢어 둘까

작게 찢으면

딱 맞는 조각을 찾지만
누구 얘기인지 잊어버림

크게 찢으면

맥락은 살지만
이것저것 섞여 흐려짐

시작은 400~512토큰, 10~20% 겹치게

이제 첫 번째 키워드, 청킹이야. 청킹은 문서를 검색 단위로 자르는 거야. 책을 통째로 두면 찾기 어려우니까 몇 쪽씩 찢어 두는 거라고 생각하면 돼. 왜 자르냐면, 임베딩 모델이 한 번에 받을 수 있는 길이에 한계가 있고, 긴 문서 하나를 좌표 하나로 만들면 여러 주제가 섞여서 흐려지고, 모델에 넣을 수 있는 양도 정해져 있어서야. 여기에 트레이드오프가 있어. 작게 찢으면 질문에 딱 맞는 조각을 찾기 쉬운데, "매출이 3% 늘었다"만 남아서 어느 회사, 어느 분기 얘기인지 잊어버려. 크게 찢으면 맥락은 살지만 이것저것 섞여서 검색이 흐려져. 보통 400에서 512토큰, 앞뒤 10에서 20%를 겹치게 자르는 걸로 시작해.

03 청킹

자르는 방법은 크게 네 가지

글자 수로 기계적으로 고정 크기
가장 단순. 문장 중간에서 잘릴 수 있음

문단 → 문장 순서로 재귀 분할
큰 경계부터 맞춰 자름. 실무 기본값

제목·조항·페이지 단위로 구조 기반
규정집, 보고서 PDF, 코드에 잘 맞음

주제가 바뀌는 곳에서 의미 기반
문장 임베딩이 갑자기 달라지는 지점. 비용 큼

출발은 문단·문장 기준 400~512토큰, 문서 구조가 뚜렷하면 구조 기반

출처: Chroma Research, Evaluating Chunking Strategies (2024.07) · NVIDIA Technical Blog (2024)

자르는 방법은 크게 네 가지야. 첫째, 글자 수로 기계적으로 자르는 고정 크기 방식. 제일 단순한데 문장 중간에서 뚝 잘릴 수 있어. 둘째, 재귀 분할. 먼저 문단 경계에서 자르고, 문단이 너무 길면 문장 경계에서, 그래도 길면 단어에서 자르는 식으로 큰 경계부터 맞춰 가. 비용이 거의 없고 성능도 안정적이라 실무 기본값이야. 셋째, 구조 기반. 제목, 조항, 페이지처럼 문서가 원래 가진 단위로 자르는 거야. 우리 회사 규정집처럼 제1조, 제2조로 나뉜 문서나 페이지마다 주제가 정리된 보고서에 잘 맞아. NVIDIA 실험에서는 재무 보고서 같은 PDF에서 페이지 단위가 가장 안정적이었어. 넷째, 의미 기반. 문장마다 임베딩을 구해서 뜻이 갑자기 달라지는 곳을 경계로 삼아. 그럴듯하지만 문장마다 계산해야 해서 비싸고, 다음 장에서 볼 것처럼 함정도 있어. 그래서 시작은 재귀 분할 400~512토큰, 문서 구조가 뚜렷하면 구조 기반으로 가는 게 무난해.

03 청킹

직접 잘라 보기

숙박비 한도랑 예외 조항이 같은 조각에 들어가나?

자르는 방식 조각 크기 200자 겹치는 부분 0자

0조각 수

0평균 글자

-숙박비 조각

직접 잘라 볼게. 화면에 있는 건 가상의 출장비 규정이야. 지금은 문단, 문장 순서로 200자씩 자른 상태고 조각이 3개야. 숙박비 조항이 2번 조각에 통째로 들어가 있지. 이제 조각 크기를 100자로 줄여 볼게. (슬라이더 조작) 그러면 제3조가 둘로 갈라지면서 "1박 12만 원 한도"랑 "주최 측 지정 숙소는 한도 없음"이 다른 조각에 들어가. 검색이 앞 조각만 가져오면 예외 조항을 빼먹은 반쪽짜리 답이 나와. 누가 행사 때문에 지정 숙소에 묵었는데 한도 초과라고 잘못 안내받는 거지. 이번엔 겹치는 부분을 40자 정도 줘 볼게. (조작) 점선 밑줄이 앞 조각에서 넘어온 부분인데, 경계가 조금 이어지는 게 보여. 마지막으로 글자 수로 기계적으로 자르기를 고르면 문장 중간에서 뚝뚝 끊기는 것도 볼 수 있어. 여러분이 직접 숫자를 불러 주면 바꿔 볼게.

03 청킹

너무 잘게 자르면
찾고도 틀린다

최종 정답률, 학술 논문 50편

의미로 잘랐더니 조각이 평균 43토큰
거의 한 문장!

같은 54%·69%를 글마다 다른 벤치마크라고 인용함
숫자는 방향만, 우리 문서로 다시 재기

출처: PremAI, RAG Chunking Strategies 2026 Benchmark Guide (FloTorch 2026.02 인용) · Chroma Research (2024.07)

"그럼 뜻 단위로 똑똑하게 자르면 제일 좋겠네" 싶잖아. 꼭 그렇지 않아. 학술 논문 50편으로 한 비교 실험을 보면, 문단·문장 기준으로 자른 게 최종 정답률 69%, 글자 수 기준이 67%였는데, 의미 기준으로 자른 게 54%로 오히려 제일 낮았어. 이유를 보니 의미 기준이 조각을 평균 43토큰, 거의 한 문장 크기로 잘게 만들었어. 관련 문장은 잘 찾았는데 답에 필요한 앞뒤 문맥이 같이 안 들어온 거야. 그래서 검색 점수만 보면 좋아 보이는데 최종 답은 틀려. 그리고 재밌는 게 하나 있어. 이 54%, 69%를 어떤 글은 FloTorch 벤치마크라고 하고 어떤 글은 Vecta라는 곳의 작은 실험이라고 해. 같은 숫자가 출처 설명이 다른 거지. 이럴 땐 숫자 자체보다 방향만 가져가고 우리 문서로 다시 재 보는 게 맞아. 이것도 오늘 마지막에 할 출처 검증의 작은 연습이야.

03 청킹

작게 찾고, 크게 넣기

부모-자식 청킹
찾기는 정밀하게, 읽기는 넉넉하게

Late Chunking
문서 전체를 먼저 읽힌 뒤에 자르기
조각마다 앞뒤 맥락이 섞인 좌표가 됨

출처: Günther 외, Late Chunking (Jina AI, arXiv 2409.04701, 2024)

작게 자르면 잘 찾지만 맥락을 잃고, 크게 자르면 맥락은 사는데 흐려진다고 했지. 이 둘을 동시에 얻는 요령이 있어. 첫 번째가 부모-자식 청킹이야. 문서를 작은 조각, 자식으로 잘라서 검색에 쓰고, 각 조각이 어느 큰 문단, 부모에 속하는지 기억해 둬. 검색은 작은 조각으로 정밀하게 하고, 모델한테 넘길 때는 그 조각이 속한 부모 문단 전체를 넘기는 거야. 찾기는 정밀하게, 읽기는 넉넉하게. 두 번째는 Late Chunking, 늦게 자르기야. 2024년에 Jina AI가 낸 방법인데, 보통은 먼저 자르고 조각마다 따로 임베딩을 하잖아. 그러면 조각 하나만 보고 좌표를 만드니까 "이 회사"가 어느 회사인지 몰라. Late Chunking은 문서 전체를 임베딩 모델에 한 번에 통과시켜서 앞뒤 맥락을 다 반영한 다음에 조각으로 나눠. 그래서 조각마다 문서 전체의 맥락이 섞인 좌표가 돼. 추가로 LLM을 부를 필요가 없다는 게 장점이고, 대신 긴 입력을 받는 임베딩 모델이 필요해.

03 청킹

조각마다 어디 얘기인지 한 줄

매출은 전 분기보다 3% 늘었다.

어느 회사? 언제?

→

ACME 2분기 실적 보고서의 매출 부분. 매출은 전 분기보다 3% 늘었다.

LLM이 인덱싱할 때 미리 붙여 둠

검색 실패율

5.7%→1.9%

문맥 한 줄 + 키워드 검색 + 리랭킹까지 하면 3분의 1

출처: Anthropic, Introducing Contextual Retrieval (2024.09) · 상위 20개 안에 정답 조각이 없는 비율

작게 자르면 맥락을 잃는 문제에 대해 Anthropic이 2024년에 낸 해법이 있어. Contextual Retrieval이라고 하는데 아이디어는 단순해. 인덱싱할 때 LLM한테 문서 전체를 보여 주고 "이 조각이 문서의 어느 부분인지 한두 문장으로 설명해"라고 시켜. 그리고 그 설명을 조각 앞에 붙여서 임베딩도 하고 키워드 색인도 해. 그러면 "매출은 3% 늘었다"가 "ACME 2분기 실적 보고서의 매출 부분. 매출은 3% 늘었다"가 돼서 회사 이름이나 분기로 검색해도 걸려. 실험 결과 상위 20개 안에 정답 조각이 없는 비율이 5.7%였는데, 문맥 붙이기만으로 3.7%, 키워드 검색까지 합치면 2.9%, 리랭킹까지 하면 1.9%로 3분의 1이 됐어. 다만 이건 검색 실패율이지 최종 답 품질은 아니라는 점, 그리고 조각마다 LLM을 불러야 해서 비용이 든다는 점은 기억해 둬. 같은 문서를 반복해서 보내니까 프롬프트 캐싱으로 많이 줄일 수는 있어.

04 검색

단어로 찾기 vs 뜻으로 찾기

키워드 검색BM25, 단어를 센다

잘 찾음 E-4021 오류, 사번, 조문 번호

놓침 출장비로 물었는데 문서엔 여비

단어가 똑같아야 점수가 오름

의미 검색임베딩, 뜻을 잰다

잘 찾음 출장비 ≈ 여비, 다른 표현, 다국어

놓침 E-4021과 E-4012를 헷갈림

지난 회차의 임베딩 거리 그대로

서로 반대로 실패하니까 → 둘 다 쓴다 (하이브리드)

두 번째 키워드, 검색이야. 검색은 크게 두 방식이 있어. 하나는 키워드 검색. 질문에 있는 단어가 문서에 몇 번, 얼마나 의미 있게 나오는지 세서 점수를 매겨. 대표가 BM25야. 오류 코드, 사번, 조문 번호처럼 정확히 일치해야 하는 걸 잘 찾아. 대신 출장비라고 물었는데 문서엔 여비라고 쓰여 있으면 단어가 안 겹쳐서 못 찾아. 다른 하나는 의미 검색. 지난 회차에 배운 임베딩으로 뜻이 가까운 문서를 찾아. 출장비랑 여비가 같은 뜻이라는 걸 알아서 표현이 달라도 찾고, 영어 문서를 한국어로 물어도 찾아. 대신 E-4021이랑 E-4012처럼 생김새는 비슷한데 완전히 다른 코드를 헷갈려. 둘이 정반대 상황에서 실패하니까 같이 쓰면 서로 빈틈을 메워 줘. 이게 하이브리드 검색이야. 하나씩 조금 더 들어가 볼게.

04 검색

키워드 검색은
드문 단어에 점수를 준다

문서 1,000개짜리 규정집에서
단어별 희귀도 점수(IDF)

같은 단어가 10번 나와도 10배는 아님 포화

긴 문서는 우연히 걸릴 확률이 높으니 점수를 깎음

출처: Robertson & Spärck Jones, Okapi BM25 IDF 공식으로 계산 · 문서 수는 시연용 가상 값

키워드 검색의 대표인 BM25가 점수를 어떻게 매기는지 보자. 핵심은 세 가지야. 첫째, 드문 단어일수록 점수가 커. 문서 1,000개짜리 규정집이 있다고 해 보자. "규정"이라는 단어는 900개 문서에 다 나오니까 이 단어가 들어 있다고 해서 별 의미가 없어. 점수 0.1. 반면 "숙박비"는 12개 문서에만 나오니까 4.4, 오류 코드 E-4021은 딱 한 문서에만 있으니까 6.5야. 이게 1972년 Spärck Jones가 낸 IDF, 역문서빈도 아이디어야. 그래서 질문에 흔한 단어랑 드문 단어가 섞여 있으면 드문 단어가 순위를 거의 다 정해. 둘째, 같은 단어가 여러 번 나오면 점수가 오르긴 하는데 금방 포화돼. 10번 나왔다고 10배가 되지는 않아. 셋째, 긴 문서는 단어가 우연히 들어갈 확률이 높으니까 길이만큼 점수를 조금 깎아. 이 세 가지를 합친 공식이 90년대에 나온 BM25이고, 지금도 검색 엔진의 기본 부품이야.

04 검색

한국어는 조사를 떼야
단어가 보인다

띄어쓰기로 금융보험은장기적인상품입니다 "금융보험"과 안 맞음

형태소로 금융보험은 장기상품

Kiwi, Nori, Mecab 같은 형태소 분석기를 키워드 검색 앞에

출처: WikiDocs, 한글 형태소 분석기와 BM25Retriever의 결합

04 검색

의미 검색은 질문도 좌표로 바꿔
가까운 이웃을 찾는다

문서 조각마다 좌표를 미리 계산해 둔다

질문이 오면 질문 좌표 근처만 본다
수백만 개를 다 비교하지 않는다 (ANN)

비슷한 책끼리 꽂힌 서가에서 그 근처만 둘러보는 것

출처: Karpukhin 외, Dense Passage Retrieval (2020) · 그림은 2차원으로 단순화한 개념도

이번엔 의미 검색이야. 지난 회차 임베딩 그대로야. 문서 조각마다 임베딩 좌표를 미리 계산해서 저장해 두고, 질문이 오면 질문도 같은 모델로 좌표로 바꿔. 그리고 질문 좌표랑 가까운 조각을 찾는 거야. 그림을 보면 "출장비 얼마까지?"라는 질문 근처에 여비 규정, 숙박비 한도, 교통비가 모여 있고, 배당 공시나 채용 공고는 멀리 있어. 질문에 "여비"라는 단어가 없어도 여비 규정이 걸리는 이유야. 실제로는 좌표가 수백, 수천 차원이고 조각도 수백만 개라서 하나하나 다 비교하면 너무 느려. 그래서 ANN, 근사 최근접 탐색이라는 걸 써. 도서관에서 비슷한 책끼리 같은 서가에 꽂혀 있으니까 질문이랑 비슷한 서가 근처만 둘러보는 거라고 생각하면 돼. 아주 약간 놓칠 수는 있지만 엄청 빨라져. 이 좌표들을 저장하고 근처를 찾아 주는 게 벡터 데이터베이스야. 2020년 DPR 논문이 이렇게 질문과 문단을 따로 임베딩하는 구조를 정리했어.

04 검색

둘 다 돌리고 등수로 합치기 · RRF

점수 = 1 / (60 + 등수) 를 목록마다 더하기 BM25 12.7점과 유사도 0.83은 단위가 달라 그냥 못 더함

문서	키워드 등수	의미 등수	계산	RRF 점수	최종
A	1	2	1/61 + 1/62	0.0325	1등
B	3	1	1/63 + 1/61	0.0323	2등
C	2	4	1/62 + 1/64	0.0318	3등
D	없음	3	1/63	0.0159	4등
E	4	없음	1/64	0.0156	5등

양쪽 다 상위면 위로, 60은 한쪽 1등의 독주를 막는 완충재

출처: Cormack, Clarke, Buettcher, Reciprocal Rank Fusion (SIGIR 2009) · 등수는 시연용 가상 값

키워드 검색이랑 의미 검색을 같이 돌리면 결과 목록이 두 개 나와. 이걸 하나로 합쳐야 하는데 문제가 있어. 키워드 점수는 12.7, 8.3처럼 범위가 정해지지 않은 숫자고, 의미 검색 점수는 0.83처럼 1을 넘지 않는 숫자야. 그냥 더하면 숫자 큰 키워드 쪽이 다 이겨. 오디션 심사위원 한 명은 100점 만점, 한 명은 5점 만점으로 채점한 상황이랑 같아. 그래서 RRF는 점수를 버리고 등수만 써. 각 목록에서 1 나누기 60 더하기 등수를 구해서 더해. 표를 보면, (넘기면서) A는 키워드 1등, 의미 2등이라 1/61 더하기 1/62로 1등이 돼. B는 3등, 1등이라 아주 근소하게 2등. 한쪽 목록에만 있는 D, E는 반쪽 점수라 아래로 밀려. 양쪽에서 다 상위인 문서가 진짜 관련 있을 가능성이 높다는 직관을 그대로 계산으로 옮긴 거야. 60을 더하는 이유는 1등과 2등 차이를 완만하게 해서 한쪽 목록 1등이 결과를 독차지하지 않게 하려는 거고, 2009년 원 논문에서 정한 값을 지금도 기본으로 써. 이따 eaglenest 화면에서 이 점수를 실제로 볼 거야.

04 검색

넓게 건지고, 좁게 고르기

리랭커는 질문과 문서를 한 쌍씩 같이 읽고 다시 줄 세움
정확하지만 느려서 2단계에만

후보에 없는 문서는 리랭커도 못 살린다

출처: Anthropic, Introducing Contextual Retrieval (2024.09) · wz-it.com, Hybrid search and reranking for RAG

실무에서는 검색을 2단계로 해. 1단계는 넓게 건지기야. 키워드 검색, 의미 검색으로 수십 개씩 빠르게 찾아서 RRF로 합쳐 후보 50에서 100개를 만들어. 2단계는 좁게 고르기. 리랭커라는 모델이 질문과 후보를 한 쌍씩 같이 읽으면서 "이 문서가 이 질문에 얼마나 답이 되나"를 다시 채점하고, 상위 5에서 20개만 모델한테 줘. 그럼 처음부터 리랭커로 하면 되지 않냐? 리랭커는 질문이 올 때마다 문서를 한 쌍씩 다시 읽어야 해서 너무 느려. 수백만 개 문서에 다 할 수는 없어. 반면 1단계 검색은 문서 좌표를 미리 계산해 두니까 빨라. 그래서 빠른 걸로 넓게, 정확한 걸로 좁게. 주의할 건 리랭커는 순서만 바꿀 수 있다는 거야. 1단계 후보에 정답이 없으면 아무 소용 없어. 그래서 성능을 볼 때 1단계가 정답을 후보에 넣는지부터 확인해.

04 검색

문서 말고 질문을 고쳐서 찾기도 한다

재작성대화 맥락 풀기

"그거 한도는?"→"국내 출장 숙박비 한도는?"

분해여러 개를 묻는 질문

"국내와 해외 출장 차이?"→국내 규정해외 규정

가상 답변HyDE

짧은 질문→그럴듯한 답을 먼저 써서 그걸로 검색

필터먼저 거르기

날짜부서권한권한은 반드시 검색 단계에서

출처: Gao 외, HyDE (arXiv 2212.10496, 2022) · Jeong 외, Adaptive-RAG (arXiv 2403.14403, 2024)

검색을 잘하려면 문서만 손보는 게 아니라 질문도 손봐. 대표적인 게 네 가지야. 첫째, 재작성. 챗봇에서 "그거 한도는?"이라고 물으면 "그거"가 뭔지 검색기는 몰라. 그래서 대화 맥락을 풀어서 "국내 출장 숙박비 한도는?"처럼 혼자서도 뜻이 통하는 질문으로 바꿔서 검색해. 둘째, 분해. "국내랑 해외 출장 차이가 뭐야?"처럼 두 개를 같이 묻는 질문은 국내 규정, 해외 규정으로 나눠서 각각 찾고 나중에 합쳐. 셋째, HyDE라는 기법이야. 질문은 짧고 문서는 길어서 문체가 많이 다르잖아. 그래서 모델한테 그럴듯한 답을 먼저 써 보게 하고, 그 가짜 답으로 검색해. 답처럼 생긴 글이 실제 답 문서랑 더 비슷하니까. 다만 효과가 상황마다 달라서 꼭 실험해 봐야 해. 넷째, 필터. 날짜, 부서, 문서 버전으로 먼저 걸러. 특히 권한은 꼭 검색 단계에서 걸러야 해. 권한 없는 문서를 일단 가져와 놓고 "이건 쓰지 마"라고 프롬프트로 말하는 건 통제가 아니야. 이미 모델 눈앞에 보여 준 거니까.

04 검색

"전체적으로 어때?"는
조각 몇 개로 답이 안 된다

일반 RAG는 질문과 비슷한 조각 몇 개만 가져온다

"규정집 전체에서 반복되는 원칙은?"
재료가 문서 곳곳에 흩어져 있다

그래서 2024년 Microsoft:
구조를 미리 만들어 두자 → GraphRAG

출처: Edge 외, From Local to Global: A GraphRAG Approach (Microsoft Research, arXiv 2404.16130, 2024)

지금까지 본 검색은 전부 질문이랑 비슷한 조각 몇 개를 찾아오는 방식이었어. 숙박비 한도처럼 답이 한 군데 있는 질문엔 이게 잘 맞아. 그런데 "우리 규정집 전체에서 반복되는 원칙이 뭐야?" 같은 질문을 생각해 봐. 답의 재료가 출장 규정에도, 보안 규정에도, 인사 규정에도 조금씩 흩어져 있어. 그림에서 노란 표시가 재료고, 빨간 동그라미가 검색이 가져온 조각이야. 상위 몇 개만 가져오면 일부만 보고 답하게 되지. 그렇다고 문서 전체를 매번 다 넣을 수도 없고. 이 문제를 풀려고 2024년에 Microsoft Research가 낸 게 GraphRAG야. 아이디어는 간단해. 질문이 올 때마다 찾지 말고, 문서 전체의 구조를 미리 만들어 두자는 거야. 다음 장에서 그 구조를 어떻게 만드는지 볼게.

04 검색

그래프는 LLM이 미리 다 읽고 만든다

1 자르기 평소 RAG처럼 문서를 조각으로

→

2 개체·관계 뽑기 LLM이 조각마다 누가·무엇이 어떻게 이어지는지 추출

→

3 묶음 찾기 많이 이어진 개체끼리 묶음(커뮤니티). 큰 묶음 안에 작은 묶음

→

4 묶음 요약 LLM이 묶음마다 요약 보고서를 미리 작성

1~4가 전부 인덱싱→ 문서가 많을수록 LLM 호출도 그만큼 늘어난다

출처: Edge 외, From Local to Global (arXiv 2404.16130, 2024) · 묶음 찾기는 Traag 외, Leiden 알고리즘 (2019)

GraphRAG 인덱싱은 네 단계야. 첫째, 문서를 조각으로 자르는 건 일반 RAG랑 같아. 둘째가 핵심인데, LLM이 조각을 하나하나 읽으면서 개체와 관계를 뽑아. 개체는 사람, 부서, 규정, 시스템 같은 거고, 관계는 "김대리가 여비 규정을 담당한다" 같은 연결이야. 이걸 다 모으면 점과 선으로 된 그래프가 돼. 셋째, 그래프에서 서로 많이 이어진 점들끼리 묶어. 이 묶음을 커뮤니티라고 하고, Leiden이라는 알고리즘을 써. 큰 묶음 안에 작은 묶음이 있는 식으로 여러 층이 나와. 출장 묶음 안에 국내 출장 묶음, 해외 출장 묶음이 있는 느낌이야. 넷째, LLM이 묶음마다 요약 보고서를 미리 써 둬. 이 묶음엔 누가 있고 무슨 얘기가 오가는지. 여기까지가 전부 인덱싱이야. 보면 알겠지만 2번과 4번에서 LLM을 엄청 많이 불러. 문서가 많아질수록 비용이 같이 커진다는 게 GraphRAG의 가장 큰 약점이야. 이건 두 장 뒤에서 다시 볼게.

04 검색

묻는 범위에 따라 찾는 길이 다르다

로컬 검색 특정 대상을 물을 때

"김대리가 맡은 규정은?" 질문 속 개체에서 출발해 이웃 관계와 관련 조각을 모아서 답

글로벌 검색 전체를 물을 때

"규정집 전체의 공통 원칙은?" 묶음 요약마다 부분 답을 쓰고, 쓸모 있는 것만 골라 하나로 합침

논문 실험: LLM 심판 비교에서 일반 RAG보다 "더 포괄적" 판정 72~83% (심판 편향 지적이 있어 방향만 참고)

출처: Edge 외, From Local to Global (arXiv 2404.16130, 2024) · 심판 순서 편향은 Han 외, RAG vs. GraphRAG (arXiv 2502.11371, 2025)

이렇게 만들어 둔 그래프로 답하는 방법이 두 가지야. 로컬 검색은 특정 대상을 묻는 질문용이야. "김대리가 맡은 규정은?"이라고 물으면 질문 속 김대리라는 개체에서 출발해서 연결된 이웃, 관련 조각, 그 개체가 속한 묶음 요약을 모아서 답해. 관계를 따라가니까 여러 단계를 건너야 하는 질문에 강해. 글로벌 검색은 전체를 묻는 질문용이야. 묶음 요약 하나하나한테 질문을 던져서 각자 부분 답을 쓰게 해. 이걸 map이라고 해. 그다음 쓸모 있는 부분 답만 골라서 하나로 합쳐. 이건 reduce. 팀원들이 자기 파트를 요약해 오면 팀장이 골라서 합치는 거랑 비슷해. 논문에서는 100만 토큰쯤 되는 팟캐스트 대본과 뉴스 기사로 실험했는데, LLM 심판한테 두 답을 비교시켰더니 일반 RAG보다 더 포괄적이라는 판정이 72에서 83퍼센트였어. 다만 이후 연구에서 LLM 심판이 두 답을 보여 주는 순서만 바꿔도 판정을 뒤집는 편향이 있다는 지적이 나왔어. 그러니까 이 숫자는 방향 정도로만 받아들이자.

04 검색

비싼 건 미루고, 질문 따라 골라 쓴다

LazyGraphRAG 2024.11

미리 요약하지 않는다. 명사구만 뽑아 연결을 잡아 두고, LLM은 질문이 오면 필요한 만큼만

0.1%인덱싱 비용
GraphRAG 대비

1/700쿼리 비용
글로벌 질문, 비슷한 품질

질문 유형	예시	고를 것
사실 하나	"숙박비 한도는?"	일반 RAG
관계 여러 번 건너기	"김대리 팀 프로젝트 마감은?"	그래프 로컬
전체 주제·요약	"공통 원칙은?"	그래프 글로벌
섞여서 들어옴	실제 서비스	질문 보고 라우팅

자동 생성 그래프엔 정답 개체가 3분의 2쯤만 → 일반 RAG와 같이 쓰기

출처: Microsoft Research 블로그, LazyGraphRAG (2024.11) · Han 외, RAG vs. GraphRAG: A Systematic Evaluation (arXiv 2502.11371, 2025)

이제 비용 얘기. 원래 GraphRAG는 인덱싱 때 LLM으로 다 요약해 두니까 비쌌어. 그래서 2024년 11월에 Microsoft가 LazyGraphRAG를 냈어. 이름처럼 게으르게, 미리 요약을 안 해. 인덱싱 때는 LLM 대신 가벼운 언어 처리로 명사구만 뽑아서 어떤 개념이 같이 나오는지만 잡아 둬. 그리고 질문이 오면 그때 필요한 부분만 LLM으로 읽어. 발표에 따르면 인덱싱 비용이 GraphRAG의 0.1퍼센트로 벡터 RAG랑 같은 수준이고, 글로벌 질문에서 비슷한 품질을 700분의 1 쿼리 비용으로 냈어. 그럼 언제 뭘 쓰냐. 2025년에 RAG와 GraphRAG를 같은 조건에서 비교한 연구가 있는데, 사실 하나를 묻는 질문은 일반 RAG가 더 잘했고, 여러 단계를 건너는 질문은 GraphRAG 로컬 검색이 더 잘했어. 그리고 LLM이 자동으로 만든 그래프에는 정답에 필요한 개체가 3분의 2 정도만 들어 있었어. 뽑다가 놓치는 거지. 그래서 결론은 둘 중 하나를 고르는 게 아니라, 질문을 보고 맞는 쪽으로 보내는 라우팅이야. eaglenest도 이렇게 하고 있는데 이따 화면으로 보여 줄게.

05 컨텍스트

많이 넣는다고
잘 읽는 건 아니다

Lost in the Middle
정답 문서가 중간에 있으면 문서를 안 준 것보다 못할 때도

Context Rot
18개 모델 모두 입력이 길수록 흔들림

적게 넣고, 중요한 건 앞이나 뒤에

출처: Liu 외, Lost in the Middle (TACL 2024) · Chroma, Context Rot (2025.07)

세 번째 단계, 모델이 찾아온 문서를 잘 읽는가로 넘어가 보자. 많이 넣으면 좋을 것 같은데 그렇지 않아. 2023년 스탠퍼드 연구진의 Lost in the Middle 실험이 유명해. 문서 20개를 주고 그중 정답 문서의 위치만 바꿔 봤더니, 맨 앞이나 맨 뒤에 있을 땐 잘 맞히는데 중간에 있으면 확 떨어졌어. U자 모양이 나왔지. 어떤 경우엔 정답이 중간에 있을 때가 문서를 아예 안 줬을 때보다 못했어. 2025년에는 Chroma가 GPT-4.1, Claude 4, Gemini 2.5 같은 최신 모델 18개를 시험했는데 전부 입력이 길어질수록 성능이 흔들렸어. 이걸 Context Rot, 컨텍스트가 썩는다고 불러. 비슷하지만 틀린 문장이 섞여 있으면 더 심해지고. 그래서 컨텍스트는 많이 담는 창고가 아니라 아껴 쓰는 예산이야. 리랭킹으로 적게 고르고, 제일 중요한 건 앞이나 뒤에 두는 게 기본이야.

05 컨텍스트

통째로 넣으면 조금 더 정확,
대신 26배 비쌈

문서 통째로 73.1% 정답률 ×26 쿼리당 비용

검색해서 일부만 65.4% 정답률 ×1 쿼리당 비용

안 바뀌는 문서 몇 개면 통째로 + 캐싱

많고 자주 바뀌고 권한이 다르면 RAG

출처: Hamilton 외, The Token Tax of Epistemic Accuracy (2026.06, HackerNoon 인용)

그럼 검색 따위 하지 말고 문서를 통째로 넣으면? 올해 6월에 나온 비교 연구가 있어. 같은 질문을 문서 전체를 넣어서 답하게 했을 때와 검색으로 일부만 넣었을 때를 비교했더니, 통째로 넣은 쪽이 정답률 73.1%로 검색 방식 65.4%보다 8%포인트 가까이 높았어. 대신 질문 한 번에 드는 비용이 26배였어. 결론은 어느 쪽이 이기냐가 아니라 상황마다 고르는 거야. 문서가 몇 개 안 되고 잘 안 바뀌고 여러 사람이 같은 문서를 본다면 통째로 넣고 프롬프트 캐싱을 쓰는 게 더 단순하고 정확해. 반대로 문서가 많고 자주 바뀌고 사람마다 볼 수 있는 문서가 다르다면 RAG가 맞아. 권한별로 거르기도 쉽고 출처도 남거든. 요즘은 검색으로 관련 문서를 좁힌 다음 조각 대신 그 문서 전체를 긴 윈도우에 넣는 혼합 방식도 많이 써.

05 컨텍스트

"RAG는 죽었다, grep이면 된다"?

미리 색인 (인덱스)

미리 잘라 좌표를 만들어 둠

찾기는 빠름 · 문서가 바뀌면 낡음

큰 문서 더미, 자주 묻는 질문

그때그때 탐색 (grep)

에이전트가 파일을 직접 뒤져 봄

항상 최신 · 토큰을 많이 씀

코드, 이름이 곧 색인인 데이터

둘 다 찾아서 읽고 답하기, 즉 둘 다 RAG

출처: AI Engineer Europe 2026, "RAG is dead, right?" · Anthropic, Effective context engineering for AI agents (2025.09)

작년부터 "RAG는 죽었다"는 말이 많이 돌았어. 계기 중 하나가 Claude Code야. 초기 버전은 코드를 미리 잘라서 벡터 데이터베이스에 넣는 방식을 썼는데, 에이전트가 grep으로 파일을 직접 뒤지고 다시 뒤지는 방식이 더 잘 찾아서 바꿨다고 알려졌어. 그럼 인덱스는 필요 없나? 그렇지 않아. 미리 색인하는 방식은 찾기가 빠르고 쌀 대신 문서가 바뀌면 다시 색인할 때까지 낡은 정보를 줘. 그때그때 탐색하는 방식은 항상 최신 파일을 보지만 질문마다 여러 번 뒤지느라 토큰을 많이 써. 코드처럼 함수 이름, 파일 이름이 곧 색인 역할을 하는 데이터는 grep이 잘 맞고, 회사 문서 수만 건처럼 크고 표현이 제각각인 데이터는 인덱스가 유리해. 그리고 중요한 건, grep으로 찾아서 읽고 답하는 것도 결국 검색 증강 생성이라는 거야. 죽은 건 RAG가 아니라 "벡터 검색 한 번 하고 끝"이라는 단순한 방식이고, 요즘은 둘을 섞어 쓰는 게 기본이야.

05 컨텍스트

가져온 문서가 별로면
스스로 판단해서 다시

Self-RAG 2023
모델이 검색이 필요한지, 근거가 맞는지 스스로 체크하도록 학습

CRAG 2024
작은 평가기가 결과를 3단계로 판정. 기존 RAG에 끼워 넣는 방식

출처: Asai 외, Self-RAG (arXiv 2310.11511, 2023) · Yan 외, Corrective RAG (arXiv 2401.15884, 2024)

기본 RAG는 검색 결과가 좋든 나쁘든 무조건 모델한테 넘겨. 그래서 엉뚱한 문서가 오면 그대로 엉뚱한 답이 나와. 이걸 고치려는 연구가 2023년부터 나왔어. Self-RAG는 모델을 학습시켜서 "지금 검색이 필요한가", "가져온 문서가 관련 있나", "내 답이 근거랑 맞나"를 특수한 신호로 스스로 판단하게 했어. 효과는 있는데 모델을 따로 학습시켜야 한다는 부담이 있어. 2024년에 나온 CRAG, Corrective RAG는 더 실용적이야. 작은 평가기를 하나 두고 검색 결과를 정확, 애매, 틀림 세 가지로 판정해. 정확하면 그대로 쓰고, 틀리면 버리고 웹 검색 같은 다른 경로로 다시 찾고, 애매하면 둘을 섞어. 기존 RAG에 끼워 넣기만 하면 돼서 모델을 다시 학습시킬 필요가 없어. 이런 "확인하고 다시 찾는" 아이디어가 아까 본 2026년 에이전틱 RAG 루프의 뿌리야. 지금은 평가기 대신 에이전트 자체가 판단하는 경우가 많아.

06 출처 검증

출처가 달렸다고
맞는 말은 아니다

해외 출장은 반드시 일반석입니다 [3]

→

3번 문서
항공권은 일반석을 원칙으로 한다

원칙 ≠ 반드시

근거에 있는 말인가? 주장마다 인용이 다 달렸나? 그 인용이 정말 그 말을 하나?

출처: Gao 외, ALCE (EMNLP 2023) · Ragas 공식 문서

이제 마지막 키워드, 출처 검증이야. 답 밑에 출처 번호가 붙어 있으면 믿고 싶어지잖아. 그런데 열어 보면 미묘하게 다른 경우가 꽤 많아. 예를 들어 AI가 "해외 출장은 반드시 일반석입니다 [3]"이라고 했는데 3번 문서를 열어 보면 "항공권은 일반석을 원칙으로 한다"고 쓰여 있어. 원칙이라는 건 예외가 있다는 뜻이고, 반드시는 예외가 없다는 뜻이야. 완전히 다른 말이지. 출처가 달려 있다는 것과 출처가 그 말을 뒷받침한다는 건 다른 얘기야. 그래서 확인할 건 세 가지야. 첫째, 답의 주장이 근거 안에 실제로 있는 말인가. 둘째, 주장마다 인용이 빠짐없이 달렸나. 셋째, 달린 인용이 정말 그 주장과 관련 있나. 연구에서는 이걸 각각 충실도, 인용 재현율, 인용 정밀도라고 불러.

06 출처 검증

최고 모델도 절반은
근거가 모자랐다

ELI5 질문에서 최고 모델 답의 약 절반이
인용만으로는 완전히 뒷받침되지 않음

근거가 부족해도 모델은 잘 안 멈춘다
RAG를 붙이면 더 자신 있게 틀린다

"문서로는 확인이 안 돼요"를
정답으로 인정해 주기

출처: Gao 외, ALCE (EMNLP 2023) · Joren 외, Sufficient Context (ICLR 2025)

이게 얼마나 어려운지 보여 주는 연구가 있어. 2023년 프린스턴 연구진이 만든 ALCE라는 벤치마크는 AI 답의 인용이 주장을 제대로 뒷받침하는지 자동으로 채점해. ELI5라는 설명형 질문 데이터에서는 당시 최고 모델도 답의 절반 정도가 인용만으로는 완전히 뒷받침되지 않았어. 더 무서운 건 2025년 구글 연구야. 근거가 충분한지 부족한지를 나눠서 봤더니, 큰 모델은 근거가 충분하면 잘 답하는데, 근거가 부족할 때 "모르겠다"고 하기보다 틀린 답을 내는 경우가 더 많았어. 심지어 RAG로 문서를 붙여 주면 관련은 있는데 답은 없는 문서 때문에 자신감이 올라가서 모른다는 답이 더 줄었어. 그래서 시스템을 만들 때 "제공된 문서로는 확인할 수 없습니다"를 실패가 아니라 정상적인 답으로 설계해야 해. 이따 eaglenest에서 실제로 이런 답을 보여 줄게.

06 출처 검증

인용은 부탁하지 말고
시스템으로 강제한다

시스템 프롬프트 규칙 1. 사실 문장마다 끝에 [문서번호] 2. 문서에 없는 내용은 쓰지 않기 3. 문서끼리 다르면 날짜와 함께 둘 다 4. 못 찾으면 "확인할 수 없습니다"

모델 내장 인용 기능 도입 후

10%→0%

출처 환각·형식 오류 (금융 기술 기업 Endex 사례)

출처: Anthropic, Introducing Citations on the Anthropic API (2025.01) · 수치는 고객사 자체 보고

그럼 인용을 어떻게 잘 달게 할까? 방법은 두 단계야. 첫째, 프롬프트로 규칙을 분명히 줘. 사실을 말하는 문장마다 끝에 문서 번호를 달 것, 문서에 없는 내용은 일반 상식으로 채우지 말 것, 문서끼리 내용이 다르면 둘 다 날짜와 함께 보여 줄 것, 끝내 못 찾으면 "확인할 수 없습니다"라고만 답할 것. 이것만 해도 꽤 좋아져. 둘째, 모델이 원래 갖고 있는 인용 기능을 써. Anthropic이 2025년 1월에 낸 Citations 기능은 문서를 문장 단위로 쪼개서 모델이 정확히 어느 문장을 근거로 썼는지 가리키게 해. 프롬프트로 부탁하는 것보다 훨씬 일관돼. 이걸 도입한 금융 기술 기업 Endex는 출처를 지어내거나 형식이 틀리는 비율이 10%에서 0%로 줄었다고 했어. 물론 회사가 스스로 발표한 수치니까 그대로 믿기보다 방향을 참고하면 돼. 핵심은 "인용 좀 달아 줘"라고 부탁하는 게 아니라 구조로 강제하는 거야.

06 출처 검증

악성 문서 5개면 답이 바뀐다

90%

수백만 건 중 질문당 5개만 심어도
원하는 답이 나올 확률

문서 안에 숨긴 "이전 지시 무시해" 같은 명령도 공격

누가 지식 베이스에 쓸 수 있나 = 답의 신뢰도

출처: Zou 외, PoisonedRAG (arXiv 2402.07867, 2024)

보안 얘기도 하나 하자. RAG는 문서를 믿고 답하잖아. 그럼 누가 문서를 조작하면? 2024년 PoisonedRAG 연구에서 수백만 건짜리 지식 베이스에 질문당 악성 문서를 딱 5개만 심었는데, 90% 확률로 공격자가 원하는 답이 나왔어. 그림에서 빨간 게 그 5개야. 바다에 물감 몇 방울 떨어뜨린 것 같은데 그게 검색에 걸리도록 만들어진 거라 효과가 엄청나. 연구에서 시험한 기본적인 방어로는 막지 못했어. 더 나아가 문서 안에 "이전 지시를 무시하고 이렇게 해" 같은 명령을 숨겨 두면, 에이전트가 그걸 지시로 착각해서 엉뚱한 도구를 실행할 수도 있어. 이걸 간접 프롬프트 인젝션이라고 해. 그래서 누가 지식 베이스에 문서를 넣을 수 있는지 관리하고, 검색된 문서는 지시가 아니라 데이터로 다루게 하고, 되돌릴 수 없는 행동은 사람이 확인하게 하는 게 중요해. 누가 쓸 수 있느냐가 곧 답의 신뢰도야.

06 출처 검증

AI 답을 받으면 30초 점검

출처가 달려 있나? 원문에 그대로 있나? 숫자, "원칙적으로", "단" 같은 조건까지 출처 날짜는 언제인가? 구판 규정은 아닌가 원본 자료인가, 그걸 옮긴 글인가? 중요한 결정이면 서로 다른 출처 두 개가 맞는가?

눌러서 같이 체크해 보기

이제 우리 같은 사용자 입장에서 할 수 있는 거야. AI 답을 받았을 때 30초만 들여서 이 다섯 가지를 확인해 보자. 하나씩 눌러 볼게. 첫째, 출처가 달려 있나. 없으면 모델 기억에서 나온 말일 수 있어. 둘째, 출처를 열어서 원문에 그대로 있나. 특히 숫자랑 "원칙적으로", "단" 같은 조건이 바뀌지 않았는지. 셋째, 출처 날짜가 언제인가. 구판 규정이나 지난 분기 자료는 아닌지. 넷째, 원본 자료인가 그걸 옮긴 글인가. 아까 청킹 장에서 같은 숫자를 다른 출처로 인용한 사례 봤잖아. 옮기는 과정에서 숫자나 맥락이 바뀌는 경우가 많아. 다섯째, 중요한 결정이면 서로 다른 출처 두 개가 같은 말을 하는지. 다 하면 30초 넘을 수도 있는데, 적어도 2번, 원문 대조는 습관으로 만들면 좋겠어.

07 평가

점수를 검색과 생성으로 나눠야
고칠 곳이 보인다

검색 · Context Recall
필요한 근거를 다 가져왔나?
낮으면 청킹, 임베딩, 하이브리드, 질문 고치기

검색 · Context Precision
쓸데없는 건 덜 가져왔나?
낮으면 리랭커, 넣는 개수 줄이기

생성 · Faithfulness
답이 근거 안에 있는 말인가?
낮으면 인용 강제, 배치, 모델 교체

생성 · Answer Relevancy
질문에 실제로 답했나?
낮으면 질문 이해, 재작성

출처: Ragas 공식 문서 (RAGAS 4대 지표)

이제 평가 얘기를 할게. RAG가 틀렸을 때 최종 답만 보고 "틀렸네" 하면 어디를 고쳐야 할지 몰라. 검색이 문제인지 생성이 문제인지 구분이 안 되거든. 그래서 많이 쓰는 RAGAS라는 평가 도구는 점수를 네 개로 나눠. 검색 쪽 두 개. Context Recall은 답에 필요한 근거를 다 가져왔는지, Context Precision은 쓸데없는 건 덜 가져왔는지, 관련 있는 게 위에 있는지를 봐. 생성 쪽 두 개. Faithfulness는 답의 주장 하나하나가 가져온 근거 안에 실제로 있는지, 즉 지어낸 게 없는지를 보고, Answer Relevancy는 질문에 실제로 답했는지를 봐. 이렇게 나누면 처방이 달라져. Recall이 낮으면 애초에 못 찾은 거니까 청킹이나 검색 방식을 고쳐야 하고, Precision이 낮으면 리랭커를 붙이거나 넣는 개수를 줄이고, 근거는 좋은데 Faithfulness가 낮으면 모델이 지어내는 거니까 인용 강제나 컨텍스트 배치를 바꿔. 점수 대부분은 다른 LLM이 채점하는 방식이라 완벽하진 않지만 어디를 볼지 알려 주는 지도로는 충분해.

07 평가

시험 보기 전에 정답지부터

1
실제 사용자 질문 50~200개 모으기

2
질문마다 정답과 근거 위치(문서·조항) 적기

3
답이 없는 질문도 섞기
모른다고 하는지 보려고

4
설정을 바꿀 때마다 같은 시험 다시 보기

한 번에 한 가지만 바꿔야 무엇이 효과였는지 안다

출처: Ragas 공식 문서 · AI 리터러시 학습 노트 06 평가 섹션

점수를 매기려면 정답지가 있어야겠지. 이걸 골든셋이라고 불러. 만드는 법은 네 단계야. 첫째, 실제 사용자 질문을 50개에서 200개 정도 모아. 내가 상상한 질문 말고 실제로 들어오는 질문이 중요해. 둘째, 질문마다 정답이랑 정답의 근거가 어느 문서 몇 조에 있는지 적어 둬. 근거 위치가 있어야 검색이 그걸 찾아왔는지 채점할 수 있어. 셋째, 문서에 답이 없는 질문도 일부러 섞어. 그래야 시스템이 모를 때 모른다고 하는지, 지어내는지 볼 수 있어. 아까 본 연구처럼 RAG를 붙이면 오히려 모른다고 안 하는 경향이 있으니까 이게 꽤 중요해. 넷째, 청킹 크기든 모델이든 프롬프트든 뭔가를 바꿀 때마다 같은 시험을 다시 봐. 이때 한 번에 하나만 바꿔야 해. 세 개를 동시에 바꾸면 점수가 올라도 뭐가 효과였는지 알 수 없거든. LLM으로 질문을 자동 생성해서 보충할 수도 있는데, 실제 질문이랑 말투가 달라서 그것만 믿으면 안 돼.

08 정리

오늘부터 쓸 기본값 다섯 개

1
구판·중복 정리, 날짜·권한 붙이기

2
400~512토큰으로 자르고 제목 붙이기

3
키워드 + 의미 검색을 RRF로

4
리랭커로 5~20개만 넣기

5
문장마다 출처, 정답셋으로 평가

자세한 체크리스트는 학습 노트 06

RAG 품질은
찾기와 확인에서 정해진다

이론은 여기까지다음: 내가 직접 만든 eaglenest →

09 eaglenest

그럼 내가 직접 만든 건?

eaglenest

사내 문서와 프로젝트 기록을 근거로, 출처와 함께 답하는 지식 허브

오늘 배운 청킹 · 검색 · 출처 검증이 실제로 어디에 들어갔는지 볼게

09 eaglenest

문서 · 좌표 · 관계를 세 군데에 나눠 담았다

문서 업로드
PDF · DOCX · PPTX
XLSX · TXT · MD

원본 파일은 NAS

→

PostgreSQL 문서 정보 · 권한

Qdrant 조각 좌표 (벡터)

Neo4j 사람·프로젝트 관계

→

누리
AI 에이전트
답변 + 출처

웹 · Slack @nuri

질문한 사람이 볼 수 있는 정보만 찾아서 답한다

출처: eaglenest 시스템 구성 · 릴리즈 노트 (2026.09.30, 2026.10.08)

구성은 이래. 문서를 올리면 원본 파일은 NAS에 보관하고, 데이터는 세 군데에 나눠 담아. PostgreSQL에는 문서 정보, 메타데이터, 권한 같은 일반 데이터를, Qdrant라는 벡터 데이터베이스에는 아까 말한 조각별 좌표를, Neo4j라는 그래프 데이터베이스에는 사람, 팀, 프로젝트, 업무 사이의 관계를 담아. 오늘 배운 것과 연결하면 Qdrant가 의미 검색, Neo4j가 GraphRAG처럼 관계를 따라가는 부분이야. 그 위에 누리라는 AI 에이전트가 있어서 질문을 받으면 필요한 곳을 찾아보고 출처와 함께 답해. 웹 화면에서도 쓰고, Slack에서 @nuri라고 부르거나 "누리야"라고 해도 답해. 그리고 중요한 원칙 하나. 누리는 질문한 사람이 볼 수 있는 정보만 찾아서 답해. 아까 권한은 프롬프트가 아니라 검색 단계에서 걸러야 한다고 했던 것과 같은 얘기야.

09 eaglenest

올리면 자르고 좌표로 바꿔 색인한다

eaglenest / 문서

파란 동그라미: 끌어다 놓으면 업로드

빨간 동그라미: 인덱싱 완료

인덱싱 = 텍스트 추출 → 청킹 → 임베딩 → 저장

eaglenest 문서 화면 · 화면 속 문서명·대화 제목·이메일은 공개용 가상 데이터로 바꿔서 캡처

09 eaglenest

통합 검색은 하이브리드, 점수는 등수로 합친 값

eaglenest / 검색

하이브리드 배지
키워드와 의미 검색 둘 다에 걸림

키워드 배지
키워드 검색에만 걸림

점수 0.0xx = 1/(60+등수)의 합
한쪽 1등만이면 1/61 ≈ 0.016

eaglenest 통합 검색 화면 · 화면 속 문서명·대화 제목·이메일은 공개용 가상 데이터로 바꿔서 캡처

통합 검색 화면이야. 위에 "키워드와 의미를 결합한 하이브리드 검색"이라고 쓰여 있지. 오늘 배운 그대로야. 결과 제목이랑 내용은 발표용 가상 데이터로 바꿨는데, 배지랑 점수는 실제 화면 그대로야. 결과마다 오른쪽에 배지가 붙어 있는데, 하이브리드라고 붙은 건 키워드 검색과 의미 검색 양쪽에 다 걸린 문서고, 다섯 번째처럼 키워드라고 붙은 건 키워드 검색에만 걸린 문서야. 그리고 옆의 점수를 봐. 0.029, 0.028처럼 아주 작은 숫자지? 이게 아까 본 RRF 점수야. 1 나누기 60 더하기 등수를 더한 값이라 이렇게 작게 나와. 양쪽 목록에 다 있는 문서는 두 번 더해져서 0.03 근처가 되고, 한쪽에만 있는 문서는 반쪽이라 0.016 근처야. 키워드 배지 문서 점수가 0.016인 게 딱 한쪽 목록 1등, 1/61 값이야. 이론으로 본 표가 실제 화면에 그대로 나온 거지.

09 eaglenest

누리는 문장마다 출처 번호를 단다

eaglenest / 누리

문장 끝 작은 숫자 = 근거 번호

오른쪽 출처 패널: 근거 원문과 검색 점수

신뢰도 표시

원문을 바로 열어 볼 수 있어야
30초 점검이 가능하다

eaglenest 누리 대화 화면 · 화면 속 문서명·대화 제목·이메일은 공개용 가상 데이터로 바꿔서 캡처

이제 누리한테 물어본 화면이야. "PAXG는 어떤 방식으로 발행돼?"라고 물었어. PAXG는 금 1온스에 연동된 공개된 토큰이라 답 내용은 그대로 두고, 출처 문서 이름만 가상으로 바꿨어. 답을 보면 문장마다 끝에 작은 숫자가 붙어 있지. 이게 근거 번호야. 오늘 출처 검증에서 말한 "사실 문장마다 인용 달기"를 그대로 적용한 거야. 오른쪽 출처 패널에는 그 번호에 해당하는 근거 원문 일부랑 검색 점수가 나와. 점수는 그 조각이 질문과 얼마나 가까운지를 나타내. 사용자가 답을 보다가 의심 가면 번호를 눌러서 원문을 바로 확인할 수 있어. 아까 30초 점검에서 원문 대조가 제일 중요하다고 했잖아. 그게 가능하려면 시스템이 원문까지 한 번에 보여 줘야 해. 답 아래에는 신뢰도 표시도 있고, 부정확해요, 수정 제안 버튼으로 사용자가 바로 피드백을 남길 수 있어.

09 eaglenest

근거가 없으면 없다고 말하게 했다

eaglenest / 누리

"직접 설명한 문서는 찾지 못했습니다"

관련은 있지만 답은 아닌 문서는 따로 표시

근거가 부족할 때 지어내는 대신
추가 자료를 요청

eaglenest 누리 대화 화면 · Joren 외, Sufficient Context (ICLR 2025) · 화면 속 문서명·대화 제목·이메일은 공개용 가상 데이터로 바꿔서 캡처

이 화면이 개인적으로 제일 보여 주고 싶었던 거야. "온체인 채권 발행의 장점은 뭐야?"라고 물었는데, 누리가 "직접 설명한 문서는 찾지 못했습니다"라고 답했어. 그리고 관련된 내용, 온체인 데이터 활용이나 토큰증권 발행 시스템에 관한 문서는 있지만 채권 발행의 구체적 장점을 판단할 근거는 부족하다고 구분해서 말하고, 추가 자료를 주면 정리해 주겠다고 해. 아까 구글 연구에서 모델은 근거가 부족하면 모른다고 하기보다 지어내는 경향이 있고, RAG를 붙이면 관련은 있는데 답은 없는 문서 때문에 더 자신 있게 틀린다고 했잖아. 바로 그 상황이야. 관련 문서가 검색은 됐는데 답은 없는 경우. 이럴 때 지어내지 않고 멈추도록 설계하는 게 회사 시스템에서는 정말 중요해. 틀린 답 하나가 신뢰를 다 깎아 먹거든.

09 eaglenest

사람 · 프로젝트 · 업무는 관계 그래프로

eaglenest / 업무 온톨로지

팀 · 사람 · 프로젝트 · 업무가 선으로 연결

막힌 곳(기한 지난 업무, 담당자 없음)이 바로 보임

"○○ 대리가 하는 일 뭐야?"
누리가 이 관계를 직접 조회해 답함

eaglenest 업무 온톨로지 화면 · 릴리즈 노트 (2026.09.30) · 화면 속 문서명·대화 제목·이메일은 공개용 가상 데이터로 바꿔서 캡처

업무 온톨로지 화면이야. 팀, 사람, 프로젝트, 업무가 점으로 있고 서로 선으로 연결돼 있어. 이게 Neo4j에 담긴 관계 그래프야. 오른쪽에는 기한 지난 업무나 담당자 없는 업무처럼 막힌 곳이 바로 보여. 이게 RAG랑 무슨 상관이냐면, "누가 무슨 일을 하고 있어?" 같은 질문은 문서 조각을 검색해서는 답하기 어려워. 아까 GraphRAG 로컬 검색에서 본 것처럼 관계를 따라가야 하는 질문이거든. 그래서 누리는 사람이나 프로젝트에 관한 질문이 오면 문서 검색 대신 이 관계 데이터를 직접 조회해서 답하고, 답 아래에 참고한 사람이나 프로젝트로 가는 링크를 붙여. 질문 종류에 따라 찾는 곳을 바꾸는 것, 아까 말한 라우팅이야.

09 eaglenest

오늘 배운 것, eaglenest에서는

오늘 배운 것	eaglenest에서는
청킹 · 임베딩 · 메타데이터	문서 업로드 후 인덱싱, 종류·부서·태그
하이브리드 + RRF	통합 검색의 하이브리드·키워드 배지와 점수
문장마다 인용 · 원문 대조	근거 번호 + 출처 패널
근거 부족하면 멈추기	"찾지 못했습니다" + 추가 자료 요청
권한은 검색 단계에서 · 그래프 · 라우팅	볼 수 있는 정보만 · 업무 온톨로지 직접 조회
정답지와 평가	부정확해요 · 수정 제안 피드백

마지막으로 오늘 배운 걸 eaglenest랑 짝지어 보면 이래. 청킹, 임베딩, 메타데이터는 문서 업로드 후 인덱싱 단계에서. 하이브리드 검색과 RRF는 통합 검색의 배지랑 점수로 직접 볼 수 있었고. 문장마다 인용하고 원문을 대조하게 하는 건 근거 번호와 출처 패널로. 근거가 부족하면 멈추는 건 "찾지 못했습니다"라는 답으로. 권한, 그래프, 라우팅은 볼 수 있는 정보만 답하는 원칙이랑 업무 온톨로지 직접 조회로. 그리고 평가 쪽은 사용자가 남기는 부정확해요, 수정 제안 피드백이 정답지를 키워 가는 재료가 돼. 결국 이론에서 본 것들이 하나하나 실제 기능이 돼 있다는 걸 보여 주고 싶었어. 발표는 여기까지야.

질문 있어?

질문이 없으면 같이 얘기해 보자

1. 컨텍스트가 1,000만 토큰이 돼도 RAG가 필요할까?

2. 출처 링크가 붙어 있으면 사람은 오히려 덜 확인하게 될까?

칼리즈 · 고마워!

RAG

이 AI 답,믿어도 될까?

지금의 LLM은외워서 푸는 시험 중

RAG = 오픈북 시험

지난 시간에 배운 두 개가RAG의 재료다

준비는 미리, 찾기는 매번

틀린 답은 대부분못 찾아서 생긴다

70년 된 아이디어,이름은 2020년에

2020년: 작은 모델 + 검색이큰 모델을 이겼다

2026년: 검색은에이전트의 도구

청킹 = 책을 몇 쪽씩찢어 둘까

자르는 방법은 크게 네 가지

직접 잘라 보기

너무 잘게 자르면찾고도 틀린다

작게 찾고, 크게 넣기

조각마다 어디 얘기인지 한 줄

단어로 찾기 vs 뜻으로 찾기

키워드 검색은드문 단어에 점수를 준다

한국어는 조사를 떼야단어가 보인다

의미 검색은 질문도 좌표로 바꿔가까운 이웃을 찾는다

둘 다 돌리고 등수로 합치기 · RRF

넓게 건지고, 좁게 고르기

문서 말고 질문을 고쳐서 찾기도 한다

"전체적으로 어때?"는조각 몇 개로 답이 안 된다

그래프는 LLM이 미리 다 읽고 만든다

묻는 범위에 따라 찾는 길이 다르다

비싼 건 미루고, 질문 따라 골라 쓴다

많이 넣는다고잘 읽는 건 아니다

통째로 넣으면 조금 더 정확,대신 26배 비쌈

"RAG는 죽었다, grep이면 된다"?

가져온 문서가 별로면스스로 판단해서 다시

출처가 달렸다고맞는 말은 아니다

최고 모델도 절반은근거가 모자랐다

인용은 부탁하지 말고시스템으로 강제한다

악성 문서 5개면 답이 바뀐다

AI 답을 받으면 30초 점검

점수를 검색과 생성으로 나눠야고칠 곳이 보인다

시험 보기 전에 정답지부터

오늘부터 쓸 기본값 다섯 개

RAG 품질은찾기와 확인에서 정해진다

eaglenest

문서 · 좌표 · 관계를 세 군데에 나눠 담았다

올리면 자르고 좌표로 바꿔 색인한다

통합 검색은 하이브리드, 점수는 등수로 합친 값

누리는 문장마다 출처 번호를 단다

근거가 없으면 없다고 말하게 했다

사람 · 프로젝트 · 업무는 관계 그래프로

오늘 배운 것, eaglenest에서는

질문 있어?

이 AI 답,
믿어도 될까?

지금의 LLM은
외워서 푸는 시험 중

지난 시간에 배운 두 개가
RAG의 재료다

틀린 답은 대부분
못 찾아서 생긴다

70년 된 아이디어,
이름은 2020년에

2020년: 작은 모델 + 검색이
큰 모델을 이겼다

2026년: 검색은
에이전트의 도구

청킹 = 책을 몇 쪽씩
찢어 둘까

너무 잘게 자르면
찾고도 틀린다

키워드 검색은
드문 단어에 점수를 준다

한국어는 조사를 떼야
단어가 보인다

의미 검색은 질문도 좌표로 바꿔
가까운 이웃을 찾는다

"전체적으로 어때?"는
조각 몇 개로 답이 안 된다

많이 넣는다고
잘 읽는 건 아니다

통째로 넣으면 조금 더 정확,
대신 26배 비쌈

가져온 문서가 별로면
스스로 판단해서 다시

출처가 달렸다고
맞는 말은 아니다

최고 모델도 절반은
근거가 모자랐다

인용은 부탁하지 말고
시스템으로 강제한다

점수를 검색과 생성으로 나눠야
고칠 곳이 보인다

RAG 품질은
찾기와 확인에서 정해진다