RAG ( Retrieval-Augmented Generation ) 미래는 ? - 과연 돈이 될 것인가

 

RAG는 어떤 팀은 '랙'으로, 어떤 회사는 '알에이지'라고 말하기도 한다. 그리고 출시된지 어언 2년정도 흘렀는데 여전히 둘의 단어는 통합이 안되었고, 명칭의 혼란만큼 RAG 자체의 한계도 다소 여전하다.

 

 

LLM이 큰 반향을 일으킨 2023년 2월경, 많은 기업은 일단 tuning이라는 단어가 custom에 가깝다고 생각했는지 fine-tuning을 찾아헤메기 시작했다. 물론 fine-tuning은 좋은 방향이다. 돈이랑 데이터가 많다면 말이다. 특히 fine-tuning은 거대 모델을 local에 얹는 것도 부담스러웠지만, 이미 tuning 된 데이터를 바꾸는 일은 생각보다 더 어려운 일이였다. 데이터라는 것은 다소 변하고 수정되기 마련인데 fine-tuning은 그런 작업을 자주하기에는 다소 부담스러웠다. ( 사실 그것보다 대다수 기업은 LLM을 local 기반에서 사용할 수 없었으며, 현재에도 성능이 좋은 모델은 API 형태로만 제공된다 ) 

 

 

RAG는 사실 Meta가 2020년 정도에 논문으로 제시한 개념이다.

논문: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"

주요 개념 : Dense Retriever + Generator (BART or GPT-style)

 

 

 

 

당시에는 큰 주목을 받지 못했지만, GPT-3.5 이후 LLM 기반의 최적의 검색기법이라는 타이틀을 받기 시작했다. 그 시점 LangChain이라는 LLM 프레임워크가 시장에 주목을 받으면서 성장하기 시작했고, 이 LangChain의 가장 대표적인 도구가 RAG였다.특히 LangChain은 RAG에 가장 필요한 VectorDB와의 연동성이 좋았는데, LLM 전용으로 출시된 ChromaDB나 기존에 성능이 좋다고 평가받던 FAISS, Pinecone 등의 API와도 유연하게 연결되며 RAG이 쉽게 구현 될 수 있게 하였다. 

 

특히 RDB 위주로 개발 및 구현하던 개발자들이 VectorDB 등의 DS 기반의 지식과 다소 직접적으로 맞닿게 되는 지점이기도 했다. 당시에 나는 LangChain으로 기존에 있던 위키에 모든 데이터를 LLM이 대답할 수 있게 하라는 다소 과격한(?) 태스크가 주어졌는데, LangChain을 통해서 꽤 즐겁게 구현했던 기억이 있다. 

 

다만 RAG은 항상 한계가 명확했는데, Vector 검색으로 임베딩이 너무 많거나 잘못되면 정확히 검색이 안되었고, 애초에 벡터형태로 데이터가 저장되어 있기 때문에 기존의 검색엔진처럼 쉽게 수정하거나 구조를 바꿀 수도 없었다. (애초에 Pinecone 등의 일부 DB아니면 쉽게 조회하는 것 자체가 거의 불가능했다 ) 

또한 나름 구조화를 한다고 하지만 결국 모두가 평등한(?) chunk의 구조였고, 결국 세밀한 제어가 필요한 검색시스템에서는 사실 큰 성능을 기대하기는 어렵고 현재에도 다소 한계가 있다. 

 

이를 보완하기 위해 다양한 방법이 시도되었는데 

 

1) GPTs 처럼 문서자체를 나눠서 카테고리화 시키기

2) ReRank와 같이 거리에 대한 Rank화를 통해 블랙박스 문제 감소

3) 엄청난 양의 프롬프트 엔지니어링

4) CoT를 통해 다양한 단계의 지식 구조화 및 드릴다운

5) neo4j와 같은 GraphDB 등을 이용하여 데이터를 구조화하여 저장

6) 메모리를 따로 할당하여 중요한 정보는 저장하면서 세션 유지

 

등의 대표적인 사례가 시도되었고, 많은 케이스가 이미 UI 혹은 API 상에서 적용되어 있다.

특히 numeric data 등을 찾는 SQL Agent 등에서는 굉장히 안좋은 성과를 보였고, 결국 텍스트 데이터의 일부만 찾아오는 다소 반쪽짜리 검색시스템이 다수 탄생하였다고 할 수 있다. 그럼에도 기존의 bm25 등의 검색보다는 훨씬 유연하게 대처할 때가 많았다. 

 

 

현재에는 위의 구조화를 프로덕트화하여 출시하는 기업들이 많아지고 있다. SQL Agent를 열심히 meta data로 wrap-up하여 좋은 기능을 보여주는 Databricks의 Genie. 해당 RAG을 Graph 형태로 인덱싱하여 bm25, vector, tree 방식으로 검색하는 neo4j와 llamaIndex. 다양한 형태의 인덱싱(hierachical, GraphRAG) 과 외부 API 까지 lambda로 연동할 수 있는 AWS의 Bedrock Agent 까지. 비즈니스 레벨에서 충분히 사용할 수 있는 인프라가 거의 다 갖춰졌다고 생각한다.

 

 

다만 이게 B2C 기업의 프로덕트가 되려면 훨씬 더 Robust 한 결과물이 나와야하는데 아직은 다소 힘들다고 생각한다. 특히 numeric한 부분에 대한 검색이 아직도 쉽지 않아 보이고, 너무 방대한 양의 검색은 결국 프롬프트에서 소화하기 어려울 정도의 내용이 제공되므로 어느순간 장기기억의 문제가 발생한다고 생각한다. 

 

 

2년간 많은 기업들이 RAG를 프로덕트화 하고 더 안정적으로 만드려고 노력했지만 사실상 알고리즘이 더 좋아지고, 장기기억 이슈가 해결되지 않는 이상 해당 부분이 쉽게 해결되기는 어려워보인다. 특히 LLM이 데이터를 검색하는 방법은 SQL 정도가 최선이기에 SQL 데이터의 스키마와 메타가 정말 세세하게 잘 정리되어 있지 않는이상  numeric 데이터도 LLM이 오류나 환각없이 정확히 찾아오기에 다소 한계가 있다고도 생각한다. 

 

 

오히려 YouTube 데이터를 기반으로 이미지 인식에 상당한 강점, 실시간 비디오 인식, 음성 인식과 TTS 등에 매우 강점을 보이는 Gemini가 더 BM에 앞서가고 있다고 생각한다.  Gemini 2.5 Flash Pro는 굉장히 놀라운 수준의 비디오 OCR과 자연스러운 음성데이터 생성 능력을 보여준다. 

https://aistudio.google.com/prompts/new_chat 

로그인 - Google 계정

 

이는 기존의 구글 글라스와 합쳐져 실시간으로 세상을 인식하고, 정보를 제공하고, 번역을 해주며, 대화를 하는 우리가 생각하는 AI에 그리고 정말 매력적인 AI BM 이 탄생할 기반이라고도 생각한다. ( 주식을 줍줍해야할까 )

사실 LLM과 RAG가 처음 출시 되었을 때 가장 긴장한 기업은 Google이었고, 지금도 마찬가지일 것이다. 검색엔진에서 다소 밀린 Google은 AI로 또 한번의 시대를 풍미할 수 있을 것인지 궁금해진다.