검색 증강 생성(Retrieval Augmented Generation)

요약: LangChain은 다른 검색 방법들을 위해 추상화 방식을 조정하고 있습니다. 이는 LangChain의 VectorDB 외의 객체도 사용할 수 있게 하기 위함입니다. 목표는 (1) 외부에서 구성된 리트리버를 LangChain에서 더 쉽게 사용하도록 하고, (2) 하이브리드 검색과 같은 대체 검색 방법들에 대한 실험을 장려하는 것입니다. 이 변경은 하위 호환성을 유지하므로 기존 체인들은 이전처럼 작동해야 합니다. 하지만 가능한 한 빨리 VectorDB 체인들을 새로운 Retrieval 체인으로 업데이트할 것을 권장합니다. 왜냐하면 앞으로 가장 완벽하게 지원될 부분들이 바로 그 부분이 될 것이기 때문입니다.

서론

ChatGPT가 출시된 이래로 사람들은 자신들의 데이터를 위한 개인화된 ChatGPT를 구축해 왔습니다. 저희는 이에 대한 튜토리얼을 작성하기도 했고, 몇 달 전에는 이것에 관한 대회를 열기도 했습니다. 이러한 욕구와 수요는 ChatGPT의 중요한 한계점을 부각합니다. 바로 ChatGPT가 사용자의 데이터에 대해 알지 못한다는 것이며, 대부분의 사람들은 그것이 알고 있다면 더 유용하다고 느낄 것입니다. 그렇다면 사용자 데이터에 대해 아는 챗봇을 구축하려면 어떻게 해야 할까요?

이를 수행하는 주요 방법은 흔히 '검색 증강 생성(Retrieval Augmented Generation)'이라고 불리는 과정을 통해서입니다. 이 과정에서는 단순히 사용자의 질문을 언어 모델에 직접 전달하는 대신, 시스템이 질문에 답변하는 데 관련성이 있을 수 있는 문서를

대부분의 사람들이—LangChain을 포함하여 우리도—검색(retrieval)을 수행해 온 주요 방식은 의미론적 검색(semantic search)을 사용하는 것입니다. 이 과정에서는 모든 문서에 대해 수치형 벡터(임베딩, embedding)가 계산되고, 그 벡터들은 벡터 데이터베이스(vector database, 벡터 저장을 위해 최적화된 데이터베이스)에 저장됩니다. 들어오는 질의(query) 역시 벡터화되며, 검색되는 문서는 임베딩 공간에서 해당 질의와 가장 가까운 문서들입니다. 여기서 너무 자세히 다루지는 않겠지만, 이 주제에 대한 더 심층적인 튜토리얼이 있으며 아래에는 이를 깔끔하게 요약한 다이어그램이 있습니다.

문제점 (Problems)

이 과정은 상당히 잘 작동하며, 우리가 구축해 온 많은 구성 요소와 추상화(embeddings, vectorstores)는 이 과정을 용이하게 하는 것을 목표로 합니다.

하지만 두 가지 문제를 발견했습니다.

첫째: 검색 단계를 수행하는 방식에 매우 다양한 변형들이 있습니다. 사람들은 의미론적 검색을 넘어선 것들을 하고 싶어 합니다. 구체적으로 말씀드리자면:

• 우리는 유사성만 최적화하는 방법과 최대 한계 관련성(maximal marginal relevance)을 최적화하는 방법을 포함하여 두 가지 다른 질의 방식을 지원합니다.
• 사용자는 의미론적 검색을 수행하기 전에 결과를 필터링하기 위해 메타데이터 필터(metadata filters)를 지정하고 싶어 하는 경우가 많습니다.
• 그래프와 같은 다른 유형의 인덱스(indexes)들이 사용자들의 관심을 끌고 있습니다.

둘째: 사람들은 LangChain 외부에서 리트리버(retriever)를 구성할 수도 있다는 것을 깨달았습니다. 예를 들어 OpenAI는 ChatGPT Retrieval Plugin을 출시했습니다.

우리는 사람들이 자신이 만든 어떤 리트리버든 LangChain 내에서 최대한 쉽게 사용할 수 있도록 하고 싶습니다.

우리는 실수했다는 것을 깨달았습니다. 우리의 추상화(abstractions)를 VectorDBQA 중심으로 만들면서, 우리의 체인 사용을 제한하고 있었고, 이로 인해 다른 검색 방법을 실험하려는 사용자나 LangChain 생태계 외부에서 리트리버를 만든 사용자들에게 사용하기 어렵게 만들었습니다.

해결책 (Solution)

그렇다면 어떻게 이것을 고쳤을까요?

최근 Python 및 TypeScript 릴리스에서 우리는 다음을 수행했습니다:

• Retriever 개념을 도입했습니다.

Retriever는 다음 시그니처를 가진 get_relevant_documents 메서드를 노출해야 합니다:
def get_relevant_documents(self, query: str) -> List[Document]
이것이 우리가 Retriever에 대해 하는 유일한 가정입니다. 이 인터페이스에 대한 더 자세한 내용은 아래를 참조하세요. - VectorDB를 사용하던 모든 체인을 이제 Retriever를 사용하도록 변경했습니다.
VectorDBQA는 이제 RetrievalQA가 되었고, ChatVectorDBChain은 이제 ConversationalRetrievalChain이 되었습니다 등.*참고: 앞으로 우리는 체인이 메모리를 사용하는 경우에 Conversational 접두사를 의도적으로 사용하고, 채팅 모델을 사용하는 경우에 Chat 접두사를 사용한다는 것을 나타낼 것입니다. - LangChain의 Retriever가 아닌 첫 번째 인스턴스인 ChatGPT Retrieval Plugin을 추가했습니다. 이것은 OpenAI가 회사들이 ChatGPT에 연결할 검색 엔드포인트를 노출하는 데 도움을 주기 위해 어제 오픈소스로 공개한 모듈입니다. 참고: 모든 목적상, ChatGPT Retrieval Plugin의 내부 작동 방식은 우리의 VectorStore와 매우 유사하지만, 우리는 여전히 이를 통합하여 존재하는 새로운 유연성을 강조하는 방식으로 매우 기대하고 있습니다.

Retriever 인터페이스 확장:

• 가능한 한 관대하게 만들기 위해 의도적으로 하나의 메서드(get_relevant_documents)만 요구합니다. 우리는 (아직) 이 Retriever들의 구성에 대한 통일된 메서드를 요구하지 않습니다. - 우리는 의도적으로 query: str을 유일한 인수로 강제합니다. 메타데이터 필터링을 포함하여 다른 모든 매개변수는 Retriever 자체의 매개변수로 저장되어야 합니다. 이는 우리가 Retriever가 종종 체인 내부에 중첩되어 사용될 것으로 예상하며, 다른 매개변수들을 끌어와서 사용하고 싶지 않기 때문입니다.

*이 모든 것은 대체 Retriever(LangChain VectorStore 외)를 체인과 에이전트에서 사용하기 쉽게 만들고, 대체 검색 방법론의 혁신을 장려하는 최종 목표로 수행되었습니다. *

Q&A

질문: 인덱스와 Retriever의 차이점은 무엇인가요?

Q&A

질문: 인덱스와 Retriever의 차이점은 무엇인가요?

답변: 인덱스(index)는 효율적인 검색을 지원하는 데이터 구조이며, 리트리버(retriever)는 이 인덱스를 사용하여 사용자의 질의에 응답하여 관련 문서를 찾고 반환하는 구성 요소입니다. 인덱스는 리트리버가 기능을 수행하는 데 의존하는 핵심 구성 요소입니다.

질문: 만약 제가 이전에 VectorDBQA 체인(또는 다른 VectorDB 유형의 체인)을 사용하고 있었다면, RetrievalQA 체인에서는 무엇을 사용해야 하나요?

답변: VectorStoreRetriever를 사용할 수 있습니다. 이는 기존 벡터 스토어(vectorstore)로부터 vectorstore.as_retriever()를 수행하여 생성할 수 있습니다.

질문: VectorDBQA 체인(또는 다른 VectorDB 유형의 체인)은 여전히 존재하나요?

답변: 네, 하지만 더 이상 여기에 초점을 맞추지는 않을 것입니다. 향후 개발은 RetrievalQA 체인에서 이루어질 것으로 예상됩니다.

질문: 라이브러리에 새로운 검색 방법을 기여할 수 있나요?

답변: 예! 저희는 바로 이 목적을 위해 새로운 langchain/retrievers 모듈을 시작했습니다.

질문: 이것이 현실 세계에서 어떤 예를 가능하게 하나요?

답변: 가장 큰 장점은 문서에 대한 더 나은 질의응답(question-answering)입니다. 하지만 이전 메시지를 수집하고 검색하기 시작한다면, 이는 AI를 위한 더 나은 장기 기억으로 간주될 수 있습니다.