Retrieval

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangChain은 외부 검색기 통합과 다양한 검색 방식의 실험을 지원하기 위해 VectorDB 중심 체인을 Retriever 중심으로 개편하고, 하위 호환성을 유지하면서 Retrieval 체인으로의 전환을 권장했다.

📌 핵심 요약

• 검색 증강 생성은 사용자 질문과 관련된 문서를 먼저 검색한 뒤 질문과 함께 언어 모델에 전달하는 방식이며, 기존 LangChain은 임베딩과 벡터 데이터베이스를 활용한 의미 검색을 주로 지원했다.
• VectorDBQA 중심 추상화는 최대 한계 관련성, 메타데이터 필터, 그래프 인덱스 등 다양한 검색 방식의 실험과 LangChain 외부에서 만든 검색기의 활용을 어렵게 했다.
• 새 Retriever 인터페이스는 문자열 질문을 받아 문서 목록을 반환하는 get_relevant_documents만 요구하며, 메타데이터 필터 등 다른 설정은 검색기 자체의 매개변수로 보관한다.
• Python과 TypeScript 릴리스에서 VectorDBQA는 RetrievalQA로, ChatVectorDBChain은 ConversationalRetrievalChain으로 개편됐으며, 외부 검색기 통합 사례로 ChatGPT Retrieval Plugin이 추가됐다.
• 기존 체인은 하위 호환성을 유지하지만 향후 개발은 RetrievalQA에 집중된다. 기존 VectorStore는 vectorstore.as_retriever()로 변환해 사용할 수 있으며, 검색의 활용 사례로 문서 질의응답과 이전 메시지 검색을 통한 장기 기억이 제시됐다.

🧩 주요 포인트

1. VectorDB 중심에서 Retriever 중심으로 전환 → 체인이 특정 검색 저장소에 묶이는 제약을 줄이고 외부 검색기와 대체 검색 방식을 수용.
2. get_relevant_documents와 문자열 질문으로 호출 규약 단순화 → 검색기별 설정을 내부에 유지해 중첩된 체인에서 추가 매개변수를 전달하는 부담 축소.
3. 하위 호환성과 vectorstore.as_retriever() 제공 → 기존 VectorStore를 활용하면서 향후 개발이 집중되는 RetrievalQA로 전환 가능.

🧠 상세 정리

1. 개인 데이터 활용을 위한 검색 증강 생성

2023년 3월 23일 LangChain 팀이 발표한 이 글은 개인 데이터를 아는 챗봇을 만들려는 수요에서 출발한다. ChatGPT가 사용자의 고유한 데이터를 알지 못한다는 한계를 보완하는 대표적인 방법으로 검색 증강 생성을 설명한다. 이 방식은 질문을 언어 모델에 바로 보내기 전에 답변에 관련될 수 있는 문서를 검색하고, 그 문서를 원래 질문과 함께 전달해 답변을 생성한다. 당시 LangChain을 포함한 많은 구현은 문서의 임베딩을 벡터 데이터베이스에 저장하고 질문도 벡터로 변환하는 의미 검색을 사용했다. 검색 결과는 임베딩 공간에서 질문과 가까운 문서를 기준으로 선택되며, LangChain의 임베딩과 벡터 저장소 추상화도 이 과정을 지원하도록 만들어졌다.

2. VectorDB 중심 추상화의 두 가지 한계

기존 의미 검색은 잘 작동했지만, 팀은 검색 방식의 다양성과 외부 검색기의 활용이라는 두 가지 문제를 발견했다. 검색 단계에서는 단순 유사도를 최적화하는 방법 외에 최대 한계 관련성을 최적화하는 방법도 지원하고 있었다. 사용자들은 의미 검색 전에 메타데이터로 결과를 필터링하거나 그래프 같은 다른 인덱스를 활용하는 데에도 관심을 보였다. 또한 OpenAI의 ChatGPT Retrieval Plugin처럼 LangChain 밖에서 구성한 검색기를 기존 체인 안에서 사용하려는 요구도 있었다. 팀은 VectorDBQA를 중심으로 추상화를 설계한 것이 다른 검색 방식을 실험하는 사용자와 외부 검색기를 가져오는 사용자 모두에게 제약을 만들었다고 설명했다.

3. Retriever 도입과 체인 명칭 개편

해결책은 Python과 TypeScript의 당시 최신 릴리스에 Retriever 개념을 도입하고, VectorDB를 사용하던 체인이 Retriever를 사용하도록 바꾸는 것이었다. 이에 따라 VectorDBQA는 RetrievalQA로, ChatVectorDBChain은 ConversationalRetrievalChain으로 개편됐다. 명칭에서는 Conversational 접두사가 메모리 사용을, Chat 접두사가 채팅 모델 사용을 나타내도록 의도적으로 구분했다. 외부 검색기를 연결하는 첫 사례로 ChatGPT Retrieval Plugin도 추가했다. 팀은 이 플러그인의 내부 동작이 LangChain의 VectorStore와 매우 비슷하다고 인정하면서도, 외부 구현을 통합할 수 있다는 새로운 유연성을 보여주는 사례라는 점에 의미를 두었다.

4. 최소 인터페이스와 검색 설정의 위치

Retriever에 요구하는 인터페이스는 문자열 질문을 입력받아 문서 목록을 반환하는 get_relevant_documents 메서드 하나다. 팀은 가능한 한 다양한 구현을 수용하기 위해 검색기를 구성하는 방법에 대해서는 아직 통일된 메서드를 요구하지 않았다. 호출 인수도 query라는 문자열 하나로 제한하고, 메타데이터 필터를 포함한 나머지 설정은 검색기 자체의 매개변수로 보관하도록 했다. 이는 검색기가 체인 안에 중첩되어 사용될 때 추가 매개변수를 여러 단계에 걸쳐 전달하는 일을 피하려는 설계다. 궁극적인 목적은 LangChain의 VectorStore 이외의 검색기도 체인과 에이전트에 쉽게 연결하고, 하이브리드 검색을 포함한 대체 검색 방식의 실험을 장려하는 데 있다.

5. 기존 사용자 전환과 향후 지원 방향

이번 개편은 하위 호환성을 유지하므로 기존 체인은 이전과 같이 계속 작동하도록 설계됐다. 다만 팀은 앞으로 가장 충실하게 지원할 대상이 새로운 Retrieval 체인이므로 가능한 한 빨리 전환할 것을 권장했다. 기존 VectorDBQA 등에 전달하던 VectorStore는 vectorstore.as_retriever()를 호출해 VectorStoreRetriever로 만든 뒤 RetrievalQA에 사용할 수 있다. VectorDBQA 같은 기존 체인도 남아 있지만, 팀은 더 이상 여기에 집중하지 않고 향후 개발을 RetrievalQA에서 진행할 것이라고 밝혔다. 따라서 기존 벡터 저장소를 활용하면서도 검색기 인터페이스를 통해 새 체인으로 옮길 수 있는 전환 경로가 제공됐다.

6. 인덱스와 검색기의 구분 및 활용 범위

글의 질의응답은 인덱스를 효율적인 검색을 지원하는 자료구조로, 검색기를 그 인덱스를 이용해 사용자 질문에 관련된 문서를 찾아 반환하는 구성 요소로 구분한다. 이 설명에서 인덱스는 검색기가 기능을 수행할 때 의존하는 핵심 요소이며, 검색기 자체와 같은 개념은 아니다. 새로운 검색 방식을 기여할 수 있도록 langchain/retrievers 모듈도 마련됐다고 안내한다. 대표적인 실제 활용은 사용자의 문서를 대상으로 더 나은 질의응답을 제공하는 것이다. 또한 이전 메시지를 수집하고 검색하는 대상으로 삼으면 같은 접근을 AI의 장기 기억 개선으로 볼 수 있다고 설명하며, 검색기 추상화가 문서 검색을 넘어 대화 기록 활용에도 적용될 수 있음을 제시한다.

🧾 핵심 주장 / 시사점

• 이번 개편의 핵심은 검색 알고리즘 하나를 바꾸는 것이 아니라, 다양한 검색 구현을 체인에 연결할 수 있도록 추상화의 중심을 옮기는 데 있다.
• 문자열 질문만 받는 호출 규약은 체인 연결을 단순화하며, 메타데이터 필터 같은 검색별 설정은 검색기 내부에서 관리하도록 역할을 나눈다.
• 기존 체인의 작동 보장과 향후 개발의 집중 대상은 구분된다. 하위 호환성을 유지하더라도 새 기능을 따라가려면 Retrieval 체인으로의 전환이 권장된다.

✅ 액션 아이템

• 기존 VectorDBQA 사용 부분의 RetrievalQA 전환 검토.
• 기존 VectorStore에 vectorstore.as_retriever()를 적용하는 전환 방식 확인.
• get_relevant_documents의 문자열 질문 규약과 검색기 내부 메타데이터 필터 설정 방식 확인.

❓ 열린 질문

• 기존 VectorDBQA 사용 부분을 RetrievalQA로 전환할 때 하위 호환성과 향후 개발 방향을 어떻게 반영할 것인가?
• 메타데이터 필터를 검색기 자체의 매개변수로 보관하는 방식은 현재 검색 요구에 적합한가?
• Retriever를 문서 질의응답과 이전 메시지 검색을 통한 장기 기억 중 어디에 우선 적용할 것인가?