Don’t Build LLM Apps…Before Knowing About RAG
RAG는 현재 유행 중이며, 그에는 충분한 이유가 있습니다.
만약 여러분이 대규모 언어 모델의 세계에서 활동해왔다면, RAG라는 용어를 접해보셨을 것입니다 — 이는 retrieval augmented generation의 약자입니다. RAG는 현재 매우 인기가 있습니다. 최근에 참석한 AWS 컨퍼런스에서 제가 만난 엔지니어 중 약 80%가 RAG 응용 프로그램을 개발하고 있었습니다. 왜 이렇게 많은 엔지니어들이 RAG 응용 프로그램을 구축하는 데 집중하고 있을까요? 간단한 답은 RAG가 대규모 언어 모델의 고유한 한계점을 극복하는 데 도움을 주고 있다는 것입니다.
어떻게 도움을 주는지 살펴보겠습니다…
대규모 언어 모델의 한계 지금까지,
우리 대부분은 Chat-GPT와 같은 제품을 통해 LLMs를 탐색해왔습니다. 충분히 사용해본다면, 그들의 고유한 한계점들을 (이상한 환영을 넘어서) 눈치챘을지도 모릅니다. 훈련 데이터의 한계는 가장 먼저 떠오르는 주요한 한계점이며, 아래의 짧은 gif로 가장 잘 설명됩니다.
만약 gif에서 명확하게 보이지 않았다면, 제가 Chat-GPT에게 2023년 은행 위기에서 첫 번째로 실패한 은행이 무엇인지 물었을 때, 그것을 알려줄 수 없었습니다. 그것은 응답에서 이 모델이 2021년 9월까지의 데이터만으로 훈련되었다고 명시하고 있습니다. 분명히, 2023년 은행 위기는 이후에 발생했습니다.
그렇다면, 만약 데이터를 제공하고 같은 질문을 한다면 어떨까요? 2023년 은행 위기에 관한 위키백과 기사를 채팅 창에 복사하여 같은 질문을 했습니다. 여기서 우리는 LLMs의 또 다른 한계, 그들의 문맥 창을 만나게 됩니다. Chat-GPT로부터 제가 보낸 메시지가 너무 길다는 오류 응답을 받았습니다. 이것은 아래의 gif에서 보여지는 것과 같습니다.
이것은 Chat-GPT 뒤에 있는 모델이 한 번에 처리할 수 있는 토큰의 수가 제한되어 있기 때문에 발생합니다. 우리는 이것을 최대 문맥 길이라고 부릅니다.
LLMs Need to be Augmented
대규모 언어 모델의 많은 비즈니스 응용 프로그램들은 모델이 기업의 독점적인 비즈니스 데이터에 대한 어느 정도의 지식을 가져야 합니다. 예를 들면, 내부 정책 문서, 계약서, 저널, 절차, 레시피 등이 있습니다. 더불어, 모델이 최신 문서에 접근할 수 있어야 하는 비즈니스 응용 프로그램도 있습니다. 여기서 뉴스 미디어 관련 응용 프로그램이 떠오릅니다.
이 시점에서 여러분은 Chat-GPT나 선반에서 꺼낸 어떤 LLM이라도 이러한 응용 프로그램에는 제한적이거나 쓸모 없을 것이라는 것을 확신해야 합니다. 그러나 좀 더 자세히 설명하고, 우리 모두가 같은 생각을 하고 있다는 것을 확실히 하기 위해 이유를 명확히 말하겠습니다.
선반에서 구할 수 있는 대규모 언어 모델들은 많은 사적 독점 문서와 최신 문서에 대해 훈련되지 않았을 것입니다. 게다가, 많은 독점 문서들은 대부분의 선반에서 구할 수 있는 LLMs의 최대 문맥 길이를 초과하기도 합니다.
결과적으로, RAG가 이 문제에 대한 효과적인 해결책 중 하나로 입증되고 있습니다. 대규모 언어 모델에 RAG를 활성화함으로써, 이러한 고유한 제한 사항을 극복할 수 있도록 그것을 보강할 수 있습니다.
Retrieval Augmented Generation (RAG)이란 무엇인가요?
RAG는 지식 베이스에서 정보를 검색하고 검색하는 능력을 부여함으로써 LLM의 능력을 보강하는 방법입니다. 지식 베이스는 기업의 독점 문서일 수도 있고, 뉴스에서 발생한 최근의 사건들에 대한 저장소일 수도 있으며, 또는 대규모 언어 모델이 원래 훈련되지 않았던 다른 것일 수도 있습니다.
RAG 파이프라인은 3부분으로 쉽게 개념화될 수 있습니다.
Part 1 — 지식 베이스는 벡터화된 형식으로 변환되어 저장되어 검색이 쉽게 됩니다.
Part 2 — 두 가지 구성 요소로 구성된 도구, 첫 번째는 검색기이고 두 번째는 질문-응답 모델입니다. 검색기는 유사성 검색을 사용하여 쿼리에 답변하기 위한 지식 베이스의 관련 부분을 찾습니다. 이것은 관련 정보가 있는 더 짧은 문맥을 제공함으로써 문맥 창 문제를 극복합니다. 그런 다음 질문 응답 모델은 이 짧아진 문맥에서 작동하여 쿼리에 대한 응답을 제공합니다.
Part 3 — LLM은 도구에 액세스 할 수 있는 에이전트를 구동하는 데 사용됩니다. 에이전트는 필수적이지는 않지만, ReAct와 같은 프롬프트 엔지니어링 프레임워크를 사용하여 추론을 지시받을 수 있기 때문에 더 복잡한 질문에 답하는 데 유용합니다. 에이전트는 도구가 지식 베이스에서 관련 정보를 검색하고 원래의 질문에 답했는지 여부를 판단할 수 있는 중재자 역할을 합니다.
이 gif를 보면 RAG가 활성화된 LLM이 앞서 Chapt-GPT에 제안한 질문에 어떻게 답하는지 볼 수 있습니다.
참고: 나는 GPT-4 모델에 지식 베이스에 넣은 위키백과 기사에 액세스 할 수 있게 했습니다. 기술적인 깊은 탐구를 원하시면, 이것을 읽어보세요.
RAG의 한계점들
이 글을 지금까지 따라왔다면, RAG가 만능 해결책처럼 보일 수 있습니다. 그러나, 저는 책임 있는 전문가로서 RAG의 몇 가지 제한 사항에 대해 알려드리지 않을 수 없습니다.
RAG를 활용한 LLM의 성능을 평가하는 것은 여러 부분으로 구성되어 있기 때문에 굉장히 어렵습니다. 실질적인 접근 방식은 검색과 질문 응답, 이 두 부분을 따로 평가하는 것입니다. 그러나 여기에는 명백한 문제가 있습니다: 두 부분 사이의 상호작용입니다. 검색 부분의 성능이 나쁘면, 질문 응답 부분의 성능도 나빠집니다.
평가용 데이터 세트를 만드는 것도 단순하지 않을 수 있습니다. 독점적인 비즈니스 문서를 다루는 RAG 애플리케이션의 경우, 기존의 데이터 세트가 적합하지 않을 수 있어 특별한 평가 데이터 세트를 만들어야 할 수도 있습니다.
성능을 정확하게 평가할 수 있다 하더라도, 어떤 시스템도 완벽하지 않다는 것을 명심해야 합니다. RAG 기반 애플리케이션에 대한 이 문제를 어떻게 해결할까요? 제가 대화한 엔지니어들과의 공통된 의견은 투명한 사용자 인터페이스(UI)를 제공하는 것입니다. 엔지니어들은 당신의 질문에 답하는 것뿐만 아니라, 그 답변이 어떤 지식 베이스 부분에서 나왔는지를 인용하거나 참조하여 제공하는 RAG 기반 애플리케이션을 개발하고 있습니다. 이는 사용자에게 더 많은 문맥을 제공하며, RAG 애플리케이션이 잘못된 정보를 제공하고 있는지 판단하는 데 도움을 줍니다.
결론
RAG는 LLMs를 보강하고 그들의 고유한 제한 사항 중 일부를 극복하기 위한 상대적으로 저렴하고 간단한 방법입니다. 그러나 실제로 RAG를 활용한 모델들은 정확하게 평가하기 어려울 수 있습니다. UI와 UX에 많은 주의를 기울여 사용자들에게 충분한 문맥을 제공하여 RAG를 활용한 모델이 그들에게 합리적인 답변을 제공하는지 판별할 수 있도록 해야 합니다.
