LangChain Retriever — 문서를 찾아오는 검색기 이해하기
· LLM은 자기가 학습하지 않은 문서는 알지 못합니다 — 그래서 필요한 자료를 밖에서 찾아와야 해요.
· LangChain의 Retriever는 질문과 관련된 문서를 골라 가져오는 검색기 역할을 합니다.
· 단순 키워드 검색부터 의미 기반(임베딩) 검색까지, 상황에 맞는 방식을 고르는 게 핵심이에요.
사내 규정이나 최신 제품 매뉴얼을 챗봇에게 물어보면, 모델은 엉뚱한 답을 자신 있게 내놓곤 합니다. 학습 시점 이후의 자료거나 애초에 학습하지 않은 내부 문서라 알 방법이 없기 때문이죠. 이 빈틈을 메우는 첫 단추가 바로 Retriever입니다. 오늘은 이 검색기가 무엇이고 어떻게 동작하는지 정리합니다.
🧠 LLM은 왜 문서를 못 찾을까
LLM은 학습 때 본 데이터 안에서만 답을 만들어 냅니다. 우리가 가진 PDF 매뉴얼, 위키 문서, 어제 올라온 공지 같은 건 모델의 머릿속에 들어 있지 않아요. 그래서 그럴듯하게 지어내는 환각(hallucination)이 생기기도 합니다.
해결책은 단순합니다. 답에 필요한 문서를 먼저 찾아서 프롬프트에 같이 넣어주면 모델은 그 자료를 근거로 답합니다.
이 "먼저 찾아오는" 일을 담당하는 부품이 Retriever예요. 지식을 모델에 억지로 넣는 대신, 필요할 때 꺼내 쓰는 방식이라고 보면 됩니다.
💡 Retriever의 기본 아이디어
Retriever가 하는 일은 한 문장으로 요약됩니다. "질문을 받아, 관련 있는 문서 조각 몇 개를 돌려준다." 검색창에 키워드를 넣으면 관련 페이지가 뜨는 것과 비슷하지만, 결과를 사람이 읽는 게 아니라 LLM에게 전달할 재료로 쓴다는 점이 다릅니다.
미리 문서를 잘게 나눠(청킹) 저장고에 넣어 두고, 질문이 오면 그중 가장 관련 높은 조각을 골라 오는 구조입니다. 그래서 Retriever의 성능은 "얼마나 정확히 관련 문서를 집어내느냐"에 달려 있어요.
🗂️ 검색 방식 3가지
정답은 없고 문서 성격에 맞게 고릅니다. 정확한 용어가 중요한 규정 문서면 ①이 유리하고, 질문 표현이 제각각인 상담 데이터면 ②가, 둘 다 필요하면 ③을 씁니다.
💻 코드로 감 잡기
버전·라이브러리마다 이름은 조금씩 다르지만, 개념 뼈대는 이렇습니다.
# 1) 문서를 잘게 나눠 저장고(벡터 스토어)에 넣어 둔다
store = VectorStore.from_documents(chunks, embedding_model)
# 2) 저장고를 검색기(Retriever)로 감싼다 — 상위 3개만 가져오기
retriever = store.as_retriever(k=3)
# 3) 질문이 오면 관련 문서를 찾아온다
docs = retriever.get_relevant("환불 규정이 어떻게 되나요?")
# 4) 찾은 문서를 프롬프트에 붙여 LLM에 전달
prompt = f"참고 문서:\n{docs}\n\n질문: {question}"
reply = llm.generate(prompt)
포인트는 저장(문서를 미리 넣기) → 검색(질문에 맞는 조각 꺼내기) → 첨부(프롬프트에 붙이기)의 흐름입니다. Retriever는 이 가운데 검색 단계를 표준화된 방식으로 처리해 주는 도구예요.
🔗 Retriever와 RAG의 관계
자주 헷갈리는 부분이라 정리해 둡니다. RAG(검색 증강 생성)는 "문서를 찾아와 그걸 근거로 답을 만드는" 전체 방식의 이름이고, Retriever는 그 안에서 찾아오는 역할을 맡는 부품입니다.
| 구분 | 역할 | 비유 |
|---|---|---|
| Retriever | 질문에 맞는 문서 찾아오기 | 자료를 뒤지는 사서 |
| RAG 전체 | 찾은 자료로 답 작성까지 | 자료 받아 보고서 쓰는 사람 |
즉 Retriever는 RAG의 앞단입니다. 이 검색이 부실하면 아무리 좋은 LLM도 엉뚱한 근거로 답하게 되니, RAG 품질의 절반은 Retriever에서 갈린다고 봐도 무방해요.
🔧 실무 팁
- 청킹이 먼저 — 문서를 너무 크게 자르면 관련 없는 내용이 섞이고, 너무 잘게 자르면 맥락이 끊깁니다. 적당한 크기로 나누는 게 핵심.
- 가져올 개수(k) 조절 — 너무 많이 가져오면 프롬프트가 길어지고 비용이 늘어요. 보통 몇 개만 추려 넣습니다.
- 의미 검색엔 임베딩 모델 — 벡터 검색은 임베딩 품질에 크게 좌우되니, 한국어 문서면 한국어를 잘 다루는 모델을 고르는 게 좋습니다.
- 출처를 함께 보관 — 찾아온 문서에 원본 위치를 붙여 두면, 답변에 근거(출처)를 표시하기 쉬워집니다.
❓ 자주 묻는 질문 (FAQ)
Q. Retriever를 쓰면 모델이 새 지식을 학습하나요?
A. 아니요. 모델 자체는 그대로예요. 답할 때마다 관련 문서를 찾아 프롬프트에 넣어주는 것뿐이라, 문서를 바꾸면 답도 바로 달라집니다.
Q. 꼭 벡터(의미) 검색을 써야 하나요?
A. 아니요. 용어가 정확히 정해진 문서라면 키워드 검색만으로 충분할 때도 많습니다. 표현이 다양하면 벡터 검색이나 하이브리드가 유리합니다.
Q. Memory와는 뭐가 다른가요?
A. Memory는 '이 대화의 흐름'을 기억하는 것이고, Retriever는 '외부 문서 지식'을 찾아오는 것이에요. 목적이 다르며, 실제로는 둘을 함께 쓰는 경우가 많습니다.
마무리
정리하면, LLM은 자기가 모르는 문서엔 손을 못 대고 Retriever가 그 문서를 대신 찾아와 답의 근거로 붙여 줍니다. 핵심은 "어떤 방식으로, 얼마나 정확히 관련 문서를 집어내느냐" — 용어가 또렷하면 키워드로, 표현이 다양하면 의미 기반으로, 둘 다 필요하면 하이브리드로 고르면 됩니다. 다음 편에서는 이 검색과 생성을 하나로 잇는 RAG 파이프라인 이야기로 이어가 보겠습니다.
댓글
댓글 쓰기