[RAG] Parametric Memory to Self-Reflection
AI 모델이 지식을 저장하는 방식은 크게 두 가지로 정의됨.
Parametric Memory - 모델 학습으로 가중치 내부에 저장된 지식으로, 하드코딩된 데이터라고 생각하면 된다.
Non-Parametric Memory - 모델 외부에 존재하는 지식으로, 웹으로 치면 DB라고 보면 된다.
새로운 지식이 나올 때 마다 모델을 매번 새로 학습시키는건 오버헤드가 너무 크고, 수십억개로 구성된 가중치 파라미터에 의존하다 보니 답변을 역추적하기가 힘들다.
기존 LLM은 지식이 모델의 가중치에만 의존한다.
앞서 말한 문제들을 해결하기 위해 두 가지 Memory를 결합한 구조를 사용함.
Query Encoder는 질문을 벡터로 변환하고, 질문 벡터와 가장 유사한 상위 K개의 문서를 빠르게 찾아온다. (MIPS)
그리고 질문 x와 찾아온 문서 z를 함께 입력받아 최종 답변인 y를 생성하는 방식.
여기서 MIPS 가 벡터DB라고 생각하면 됨.
검색을 담당하는 Retriver와 생성을 담당하는 Generator를 하나로 연결해 답변이 틀리면 검색을 잘못했는지, 답변을 잘못 생성했는지를 함께 학습해서 더 높은 수준의 최적화를 구현한다.
Neural Network 기반인 Query Encoder를 사용하기에 미분할 수 있어 최종 답변의 오차가 Retriver까지 전파되어 학습이 가능함.
질문 x에 대해 문서 z가 여러개 나올 수 있는데, 이 때는 Marginalization을 사용해 각 문서 z가 주어졌을 때 정답 y가 나올 확률을 모두 계산해서 합산한다.
알고싶은건 질문 x가 주어졌을 때 답변 y가 나올 확률인데, RAG에서는 x와 y에 문서 z가 끼어든다.
이 때 z가 여러개라면 어떤 문서가 진짜 정답을 가지고 있는지 확신할 수 없기에 각각의 기여도를 합산하는 방식을 사용함.
RAG-Sequence
문장 하나를 완성할 때 까지는 단일 문서의 맥락을 유지한다.
1번 문서로 만든 문장의 전체 확률 / 2번 문서로 만든 문장 전체의 확률 .. 이렇게 모든 확률을 구하고 합산
RAG-Token
단어를 생성할 때 마다 문서를 매번 합산한다.
첫 단어를 뱉을 때 문서의 의견을 종합하고, 그 다음 단어를 뱉을 때도 문서의 의견을 종합한다.
LIMIT 1로 맨 위에꺼만 가져올 수도 있겠지만.. 첫 번째 문서가 무조건 성능이 좋은 문서라는 보장은 없음.
여러 문서를 확률적으로 합산하면 결과가 다음 답변에 얼마나 기여했는지가 수치로 남으니 학습에 사용할 수 있다.
학습 중에 문서 인코더가 변하면 모든 문서의 벡터를 새로 계산해서 인덱스를 다시 빌드해야하니..
문서 인코더와 인덱스는 업데이트하지 않고 고정하고, 질문 인코더와 생성기만 학습시킨다.
핵심은 재학습 없이 인덱스 교체만으로 지식을 업데이트 하는 것. 이 부분으로 기존 LLM의 한계를 극복한다.
기존 RAG는 질문이 어렵든 쉽든 문서 K개를 무조건 가져와서 답변을 생성하는데 활용한다.
외부 정보를 가져와서 답변 생성에 활용하는건 좋은데, 이러면 오히려 불필요한 정보 때문에 오답을 낼 확률을 높히고 유연성을 떨어뜨림.
그러니 Self-RAG를 사용해 모델이 외부 지식이 필요할 때만 문서에 쿼리하는 구조를 사용함.
reflection tokens을 도입해 지금 가져온 문서가 질문과 연관되는지, 내가 쓴 문장이 문서 내용과 일치하는지를 확인한다.
현재 문맥을 보고 검색이 필요한 시점인지를 판단해 Retrieve 토큰을 생성하고, 문서 K개를 병렬로 처리해 답변 후보를 만든다.
이후 생성된 답변에 Critique Token을 붙여 점수를 매기고 가장 신뢰도가 높은 최종 답변을 선택함.
일반적인 LLM은 저런 행동을 할 수 없음.
중간에 Retrive를 뱉지도 않고 틀린지 맞는지 Critique 점수를 매기는 법도 모른다.
그러니 저 동작이 가능하려면 Fine-Tuning이 선행되어야 함.
Critic은 Fine-Tuning에 필요한 데이터를 만드는 역할을 한다. (이 부분은 검색이 필요하고, 이 답변은 5점짜리고.. 등)
LLM 자체를 Fine-Tuning 하는거지, LLM 외부나 내부에 다른 모델을 Fine-Tuning 해서 배치하는게 아님.
기존 RAG가 Static하게 무조건 탐색하는 방식을 사용했다면 Self-RAG는 Dynamic하게 필요할 때만 검색한다.
모델이 뱉는 상태코드를 먼저 정의한다.
RETRIEVE : 현재 문맥에서 외부 DB 조회가 필요한지?
ISREL : 가져온 문저가 질문을 해결하는데 실질적인 도움이 되는지?
ISSUP : 생성된 답변이 문서에 기록된 사실과 일치하는지?
ISUSE : 생성된 답변이 사용자의 질문에 얼마나 유용한지?
저 4가지 토큰 기반의 데이터를 GPT-4를 활용해 데이터를 수집한다. 이 데이터를 가지고 Critic 모델을 만들 예정.
이제 저 Critic 모델을 Critique Token을 달아줄 수 있는 채점기로 사용한다.
텍스트 데이터에 Critic 모델을 돌려 [Retrieval] [ISREL] 토큰을 텍스트 사이사이에 삽입하고, Generator에게 데이터를 통째로 입력.
모델은 어느 타이밍에 [Retrieval]을 뱉을지, 문서를 읽고 어떤 Critique 토큰을 뱉을지 학습한다.
즉.. GPT-4 로 Generator를 학습시키면 좋은데, API 비용이 비싸니 Critic 모델을 만들어 사용하는 것.
논문에서는 학습 시 데이터 15만개를 사용하는데, 15만개를 전부 GPT-4에게 시키면 비용 감당이 안됨,,
GPT-4 -> Critic -> Generator 까지 학습했다면 이제 Self-RAG 모델을 돌려볼 수 있다.
학습이 끝나면 이제 앞서 말했던 Dynamic한 동작이 시작된다.
점수 계산 시에는 ISREL, ISSUP 토큰을 사용한다. 시스템은 이 토큰들의 확률값을 보고 점수를 계산함.
토큰 값을 조작할 수 있으니 도메인별로 모델의 특성을 커스텀 할 수 있는 것도 장점.
디테일한 부분을 물어보면 잘 대답할 수 있지만, 전체적인 질문에 대한 답변은 힘들다.
질문과 비슷한 Chunk만 몇 개 가져오기에 문서 전체 토큰의 문맥을 유지할 수 없고.. 요약할 수도 없다.
그래서 GraphRAG가 도입됐다. 데이터를 단순하게 자르지 않고, Graph를 도입해 지식의 관계를 정립함.
텍스트에서 Node를 뽑아내고, 그 사이의 관계를 이어준다.
LLM은 완성된 그래프를 미리 요약하고, 답변을 생성할 때 활용함.
기존 방식을 Vector RAG라고 하자.
VectorRAG는 텍스트 임베딩으로 벡터 공간에서 가까운 정보를 검색하는데, 이건 Local Similarity에 의존함.
GraphRAG는 데이터를 큰 단위로 요약해서 전체 맥락을 기억한다.
Leiden이나 Louvain 같은 커뮤니티 탐지 알고리즘을 사용해 그래프를 구성하는 노드를 하나의 커뮤니티로 묶어준다.
그래프 탐색이 목적이 아니라, 그래프를 계층적인 커뮤니티 요약본으로 변환하는게 목적.
문서를 적당한 크기로 자르고, LLM이 Chunk에서 노드와의 관계를 뽑아낸다.
이후 추출된 정보로 그래프 인덱스를 만들고 앞서 말한 알고리즘으로 커뮤니티를 구성한다.
이제 각 커뮤니티의 내용을 LLM으로 미리 요약함.
질문이 들어오면 관련 있는 커뮤니티의 요약본을 찾는다.
Map - Reduce 방식으로, 각 요약본에서 부분 답변을 만들고 그 답변들을 합쳐 최종 답변을 만들어낸다.
Gemini나 GPT 같은 서비스 수준의 LLM은 RAG가 기본적으로 구현되어있다.
그러니까, GPT나 Gemini 모델 자체는 Parametric Memory만 가진 상태로 학습 데이터 Cut-Off 시점 이후의 정보는 모름.
다만 웹이나 API를 통해 접근하는 GPT와 Gemini는 Retriever가 붙어있는 시스템으로 서빙된다.
내가 요즘 자바취업전망 어떠냐고 물어보면 시스템 내부의 라우터가 판단해서 외부 데이터를 쿼리해서 모델에게 던지고, 모델은 그 데이터까지 함께 입력받아서 출력을 만들어 내는 것. - 그냥 RAG 개념이 그대로 사용되고 있음.
기본적으로 RAG는 모델이 한 번에 읽을 수 있는 양이 작아서 탄생한 기술.
그런데 크기가 커지면 한 번에 다 때려박을 수 있지 않나?
Attention 연산 복잡도는 입력 길이 N 에 대해 N^2 이니 한 번 질문할 때 마다 발생하는 API 비용이 기하급수적으로 늘어날 수 있다.
즉, 비용과 속도를 고려할 때 아직까지는 RAG를 배제할 수 없음.
RAG도 어떻게 보면 VRAM을 효과적으로 쓴다는 측면이긴 함.
VRAM에 안 올리고 저렴하고 용량이 큰 Vector DB에 데이터를 저장하고 필요할 때만 로드하는 방식이니까.
그리고 VRAM 공간이 무한이라 모든 단어를 다 올릴 수 있다고 해도, 모든 걸 다 읽는게 항상 좋지는 않음.
N이 커질수록 특정 단어에 집중하는 점수가 낮아질 수 밖에 없다. (Attention is All you need)
컴퓨터구조 이론을 그대로 따라가게 되는..
그러니 실전에서 내가 거대 기업을 이기려면, 특정 영역에 집중해야 하고 RAG를 잘 사용한다면 가능성이 있어 보임.
Specific Data는 내가 알아서 수집하고, 그 데이터와 Gemini / GPT api를 쓸지 아님 로컬 모델 파인튜닝을 할지는 고려해 봐야 하고..
실제로 RAG를 구현할 때는 논문을 내가 직접 구현하기보다는 ChromaDB 같은 벡터디비 서비스를 사용하거나 LangChain에서 Retriever를 호출하거나.. 상용 라이브러리를 사용하는 방식을 사용한다.
참고문헌
1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
https://arxiv.org/abs/2005.11401
2. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
https://arxiv.org/abs/2310.11511
3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization
https://arxiv.org/abs/2404.16130