Graph 와 Agentic RAG 에 대한 주저리주저리

Agentic RAG를 잘하기 위해선 무엇을 하는게 좋을까?

Oct 19, 2024

Contents

안녕하세요 정이태입니다.Embedded database 와 RAG 끝으로 그래프 데이터 베이스 엔진 레퍼런스

안녕하세요 정이태입니다.

요즘 Real-world & Product 에서 어떻게 RAG를 효율적으로 사용할 수 있을까라는 고민을 많이 하고 있습니다. 속도 , 정확성 Trade-off 라고 하지만, 저희는 둘 다 포기할 수 없겠죠. 적확한 Context를 ms 단위로 가져온다는 것. 참 어려운 일 인거 같습니다.

하지만, 저희는 해내야겠죠? 방법을 생각해보면 여러개가 떠오릅니다. 좋은 데이터, 좋은 Foundation model , 좋은 하드웨어 , 좋은 소프트웨어 엔지니어링 등등 그 중, 저는 RAG의 Retrieval 대상이 되는 지식베이스를 개선해보면 가장 효율적이겠다 라는 생각을 많이 하고 있어요.

그래서 이 가설이 맞는지를 검증 해보기위해 열심히 공부하고 있답니다. 그럼 이 지식베이스를 개선한다는 것 구체적으로 무엇을 의미할까요? Database 라고 할 수 있을거 같네요. 회사에서 사용하고 있는 OLTP 들의 자료들을 RAG 를 위한 OLAP(Datawarehouse)를 만드는게 핵심이다. 라는걸요.

그러면 이때, 어떤 OLAP를 선택해야하는지 갈림길에 놓이기 마련입니다. SQL 포멧으로 구축할지, NoSQL 포멧으로 구축할지부터 갈림길의 시작이겠네요. 요새 Vector database가 아니더라도, 웬만한 database들은 vector indexing 기능이 개발되었기때문에, 플랫폼을 옮기면서까지 굳이?라는 생각이 많이 들기 때문이에요.

만약 Vector Database 검증이 되어 있지않아, 도입하기가 고민된다면, vector search 기능이 잘 구현되어 있는 FAISS나 Annoy 로 사내 자체적으로 mini PoC를 진행하여, 효용을 검증해보고 Milvus weaviate 등과 같은 관리형 vector database 프로덕트 도입을 해도 늦지 않기 때문이죠.

여러 갈림길 중 저는 "Embedded database를 활용하면 좋겠다" 라는 생각을 했습니다.

Embedded database 와 RAG

1.Limited Scalability, 2.Single Process Limitation, 3.Lack of Remote Access, 4.Complex Backup and Recovery, 5.Limited Features, 6.Memory and Resource Usage 여섯가지 큰 문제점을 가지고 있지만, 쉽게 구현할 수 있고 빠르다 라는 장점이 이를 상쇄할 수 있을거라 생각했기 때문이에요.

Fine tuning 대신 RAG를 선택한 이상, 주기적으로 들어오는 데이터들을 잘 관리하고 Retrieval 해야합니다. 이때, 들어오는 데이터들을 쉽고 빠르게 메타 분류하여 여러개의 Embedded database 에 담아두고, 이를 각 Retrieval Agent로써 역할을 부여한다면 결국 Agentic RAG 의 핵심인 Multi Agent 를 잘 활용할 수 있는 조건에 부합하게 되는거죠.

이렇게 상황에 적합한 OLAP 선택하고 구축하게 된다면, 드디어 요새 많이들 시도하고 도입하고 있는 Agentic , MultiAgent RAG 를 활용하기 위한 뼈대가 세워졌다 라고 봐도 될 거 같습니다.

대표적인 Agent Architecture 인 supervisor 최종 유저에게 답을 내놓기 전 supervisor agent 에게 검사를 받는 아키텍쳐 , collaboration Agent 간 협업을 통해 최종 유저에게 답을 내놓는 collaboration 아키텍쳐 , hierarchical 각 팀마다 supervisor 가 설계되어, Agent 조직화가 된 hierarchical 아키텍쳐 고민은 Agent 가 어디에서 어느 정보를 가져온 후에 해도 늦지 않을거란 생각입니다.

참고로, Agent modeling 에 많이 활용하고 있는 Langgraph는 그래프로부터 많은 영감을 받았다고 하는데요. 대용량 그래프 프로세싱의 대표주자 Pregel 그리고 그래프 분석 모듈인 Networkx 를 직접 github에 언급했을정도면, 이 철학들을 많이 따라가지 않을까 합니다.

때문에, 최종적으로 product level agent RAG는 Graph Database 로 관리하는 기술이 오지 않을까 하는 생각입니다. 수많은 agent 들로부터 정보를 종합하고 추려서, 답변을 내놓기 때문에 agent들간 관계를 체계적으로 관리하는게 중요하기 때문이죠.

끝으로

짧은 글을 마치며, 요즘 제 근황을 추가로 공유해보자면 그래프로 논문이나 글을 작성하며 얻은 지식들 혹은 튜토리얼 , 강연 , 프로젝트를 하며 그래프에 대해 어느정도 알고있겠다 싶었는데, 큰 착각이였습니다.

그래프 데이터 베이스 엔진 관련해서 구체적으로 어떻게 데이터를 받고 내부 엔진이 동작 그리고 사용자에게 쿼리 결과를 내놓는것까지를 다른 사람에게 설명하려다보니, 추상적으로만 알고 있던 제가 구체적으로 답변을 못하는 부분이 많았던거죠.

이를 답변하기 위해 잘 모르는 c++ 공부와 그래프 데이터 베이스 엔진 오픈소스 코드 스터디를 병행하며, 동작 방식과 이론을 함께 살펴보고 있답니다. 3개의 그래프 데이터 베이스 엔진 neo4j , memgraph 그리고 kuzu 를 공부하고 있는데 궁금하신 분들은 아래 레퍼런스를 남겨놓겠습니다.

요즘들어 제가 데이터베이스와 컴퓨터 아키텍쳐에 대한 이해도 및 지식이 많이 부족했고, '애매'하게 알고 있었다는걸 많이 깨닫게 되었는데요. 아마, 제 성장에 중요한 tipping point 가 되지 않을까 생각합니다. 덕분에, 무엇을 몰랐는지를 알게되었으니 열심히 공부하고 보완해나가면 되기 때문이죠.

역시 그래프는 재밌네요! 그래프와 RAG 를 잘 결합하려는 노력 앞으로도 많이 응원해주시고 관심 가져주시면 감사하겠습니다~ 이 글에 있는 정보가 도움이 되었으면 하네요. 그럼 이번 주말도 좋은 주말 되세요!