[논문 리뷰] Parametric Retrieval-Augmented Generation using Latent Routing of LoRA Adapters
Psalms 12:6-7
2026. 1. 8. 23:31
본 논문 리뷰는 저의 개인적인 해석과 의견을 바탕으로 작성된 글입니다. 내용 중 해석의 오류나 개념적인 착오가 있다면, 망설이지 마시고 댓글로 혼내주시면 감사하겠습니다~
Preview - 기존 PRAG의 문제점인 (1)각 문서마다 LoRA를 학습시키는 과정(one-to-one)과 (2) 추론 시 검색된 문서에 대응되는 LoRA 파라미터를 loading/unloading 반복하는 과정을 개선하고자 Poly-PRAG 제안 - LLM에 주입할 LoRA 파라미터를 Latent Routing을 통해 특정 개수의 Expert(LoRA) 조합으로 전체 문서를 표현할 수 있게 학습 진행 (many-to-few) - 그 결과 Offline 과정에서의 저장 공간 효율화 및 Inference time 절약 달성
기존 P-RAG offline 방식 : 문서 1개당 LoRA 1개를 따로 학습/보관하는 1:1 인코딩(문서 수가 늘면 LoRA가 문서 수만큼 폭증)
본 논문에서 말하는 이로 인한 문제점
1) 각 문서별 LoRA가 학습할 데이터가 너무 적어지는(data scarcity) 발생
문서 하나만 가지고 LoRA를 학습하면 신호가 약하고, 지식을 안정적으로 파라미터화하기 어려움
2) 추론 시 오버헤드
검색으로 후보 패시지(문서 조각)가 여러 개 나오면, 후보마다 새로운 LoRA를 모델에 merge(가중치에 반영/적용)해야 해서 계산적으로 비효율적
따라서 본 논문에서 P-RAG에서 문서를 인코딩하는 방식을 바꿔서, latent routing(잠재 라우팅)으로 소수의 LoRA를 “공유 자원처럼” 쓰는 Poly-PRAG를 제안
오프라인 단계(문서 파라미터화 학습)에서는 문서들을 각각 따로 학습하지 않고, 여러 문서를 한꺼번에 멀티태스크처럼 학습하되 문서마다 task id를 붙여 “이 문서는 어떤 작업/전문가 조합으로 표현할지”를 학습한다는 뜻
핵심은 라우팅 함수(게이트)가 작은 수의 “latent LoRA(잠재 전문가들)” 중에서 일부를 골라 조합해, 전체 문서 공간을 표현하게 만든다(문서마다 LoRA를 새로 만들지 않음)
온라인 추론에서는 쿼리를 보고 라우팅 함수가 필요한 latent LoRA(전문가) 몇 개만 활성화해서 답변 생성에 사용. 즉, 후보마다 “새 LoRA merge”가 아니라 미리 로드된 전문가 풀에서 선택/활성화로 비용을 줄임
📍1. Introduction
기존 RAG의 in-context learning을 보완하기 위해 문서를 파라미터화해 LLM FFN에 주입시켜주는 P-RAG가 등장함
그러나 각 문서를 LoRA 파라미터화 시키는 offline 과정에서 cost가 너무 많이 필요
그래서 DyPRAG라는 새로운 프레임워크 등장
문서에서 LoRA를 만들어주는 하이퍼네트워크로 저장 부담을 완화
그러나 여전히 P-RAG가 가지고 있는 근본적이 문제 해결 못함
1) 문서별 LoRA 학습은 여전히 각 LoRA가 볼 데이터가 적어서 과적합/지식추출 실패 문제가 생김(perplexing curse)
2) 온라인 추론에서는 쿼리가 바뀔 때마다 LoRA를 내렸다가 새로 올리는(load/unload) 오버헤드가 커지고, 문서가 많을수록 감당 안됨
따라서 본 논문의 Motivation Question : 문서마다 LoRA를 만들지 말고, 문서 컬렉션 전체를 대표하는(document-agnostic) LoRA 풀을 만들어서 새 쿼리에도 효율적으로 쓸 수 없을까?
위 질문에 대해 문서별 LoRA(1:1, one-to-one) 대신, 작은 수의 latent LoRA(m ≪ |T|)를 만들고 문서/쿼리에 맞게 라우팅으로 고르는 방식 제안
Offline Stage
라우팅 함수가 문서별로 ‘어떤 LoRA 몇 개를 쓸지’를 골라서 그 조합으로 해당 문서를 인코딩
이때 라우팅 함수(고르는 규칙)는 행렬 Z로 표현하는데, 𝑍 ∈R|T|×𝑚는 (문서 수 |T|) × (latent LoRA 개수 m) 크기. 즉, 각 문서(행)마다 latent LoRA들(열) 중 무엇을 얼마나 쓸지를 정하는 값들이 있고, 핵심은 latent LoRA 개수 m을 문서 수 |T|보다 훨씬 작게 둔다(𝑚 ≪|T|) →문서마다 LoRA를 만들지 말고, 적은 LoRA 풀을 공유해서 커버하자
이렇게 소수로 유지되는 공유 LoRA 풀을 논문에서는 'latent LoRA'라고 부르고, 이 풀에서 뽑아 쓰는 선택 메커니즘(routing function)을 'latent routing'이라고 부름
Online Stage
온라인(질의 응답)에서는 쿼리마다 “문서별 LoRA를 새로 로드/언로드(갈아끼우기)” 하는 대신, 이미 메모리에 올려둔 latent LoRA 풀에서 라우터가 쿼리를 보고 필요한 것만 활성화(active)
📍2. Methodology
2.1 Document Eocoding: From one-to-one to Many-to-few Latent Experts
기존 P-RAG는 각 문서 당 개별 LoRA 파라미터 튜닝 진행 (one-to-one)
P-RAG 문서 인코딩
아무래도 이렇게 각 문서의 개별 LoRA를 만들게 되면 확장성(scalability) 부분에서 문제가 생김
(1)문서 코퍼스 크기 |T|가 커질수록 저장해야 할 것과 (2)추론 시 LoRA를 합치는(merge) 오버헤드가 선형으로 증가
위 문제(병목)를 해결하기 위해 본 논문에서는 many-to-few latent experts encoding 제시
한 문서당 어댑터 1개 대신, 각 문서 𝒅𝑖를 "공유되고 고정된 latent experts 집합" M= {𝜙1,...,𝜙𝑚}의 ‘희소(sparse) + 가중(weighted) 조합’으로 인코딩
𝜙1,...,𝜙𝑚는 문서 전용이 아니라 여러 문서가 같이 쓰는 LoRA들
문서 하나를 표현할 때, 이 LoRA들을 전부 다 쓰는 게 아니라 일부만(희소하게) 골라서 가중치(비율)를 줘서 섞어 "그 문서용 파라미터"를 만들어낸다
위 방식은 지식 압축(compression)과 문서 간 지식 공유(sharing)를 가능하게 하고, 전문가 수 m이 문서 수 |T|보다 훨씬 작음
Poly-P-RAG 문서 인코딩
many-to-few encoding 장점
1) 전체 문서를 소수의 LoRA로 인코딩하면, 기존 PRAG의 데이터 희소성(dataset sparsity) 문제를 완화할 수 있음
문서마다 LoRA를 따로 학습하면 “문서 하나에 대한 학습 데이터”가 적어서 과적합/학습 부족이 생기기 쉬운데, 여러 문서가 같은 LoRA들을 공유해서 학습하면, 각 LoRA가 더 많은 데이터로 학습되므로 이 문제가 해결 가능
2) |T|개 문서 지식을 m개의 공유 expert로 압축해서 저장을 크게 줄이고, 추론 효율도 높임
문서가 많을수록 저장/서빙이 폭발하는 문제를 "m개만 들고 있으면 되게" 만들어서 크게 개선 가능
3) Poly-PRAG에서는 LoRA들이 전체 문서 컬렉션에서 ‘가장 의미 있는 내용’을 인코딩 할 수 있음
공유 expert들이 문서 전체를 학습하면서, 반복적으로 중요하게 등장하는 패턴/지식을 더 잘 잡아낼 수 있음
각 LoRA는 문서 컬렉션의 ‘서로 다른 특성(distinct characteristics)’을 포착할 수 있음
2.2 Poly-PRAG: Latent Routing for Document Parametrization
Poly-PRAG는 latent expert 단위로 쪼개서 문서를 저장하고, 입력에 따라 적절한 latent expert를 찾아 연결해 주는 latent routing architecture 사용
Latent Expert - 모델 내부의 파라미터 그룹이나 어댑터(Adapter) 모듈을 말함 - 학습 과정에서 모델이 스스로 데이터의 잠재 공간(Latent Space) 상에서 특징을 나누어 학습했기 때문에 'Latent'이라고 함
Latent Routing - 현재 입력된 데이터가 어떤 Expert를 거쳐야 가장 결과가 좋을지 결정하는 경로 설정 메커니즘 - 입력 데이터(Query)의 임베딩(Vector)을 분석하여, 준비된 여러 Latent Expert 중 누구를 활성화할지(또는 가중치를 얼마나 줄지) 계산 - Routing이 선행되어야 Expert가 작동
문서 T 전용 LoRA의 두 저랭크 행렬 𝐴T, 𝐵T를 직접 학습해서 저장하는 대신, 미리 갖고 있는 공유 expert들의 파라미터 𝐴(𝑖), 𝐵(𝑖)를 가중합(조합) 해서 동적으로 생성. 즉, 문서 전용 LoRA = 공유 LoRA들의 혼합 결과물
공유 experts 집합 M을 고정된 인벤토리(풀)처럼 유지하고, 각 expert 𝜙𝑖는 LoRA 하나(= 𝐴(𝑖),𝐵(𝑖) ∈R𝑑×𝑟)로 정의
문서별로 어떤 expert들을 쓸지 결정하는 핵심 파라미터가 라우팅 행렬 𝑍 ∈R|T|×|M| (행 : 문서(또는 문서 ID), 열 : latent experts(LoRA들))
즉 Z가 "이 문서는 expert 3, 7을 주로 써라" 같은 선택 신호를 담고 있음
예를 들어, 특정 문서 T𝜏에 대해 Z의 𝜏번째 행을 뽑은 𝑧𝜏 = 𝑍𝜏,: ∈R|M|가 있고, 그 안의 값들은 각 expert를 쓸 "선호도(logits)"
라우팅 함수𝑟(·)는 문서들을 expert들에 나눠 맡기되, soft(0/1처럼 딱 끊지 말고(미분 가능하게) 확률/가중치로 부드럽게), sparse(모든 expert를 다 쓰지 말고 일부만 쓰게(희소하게))하게 만들도록 설계됨
학습 중에는 "어떤 expert를 켤지/얼마나 섞을지"를 나타내는 mixing coefficients ^𝑍𝜏,𝑗를 Gumbel-sigmoid로 샘플링
^𝑍𝜏,𝑗 ~ Gumbel(𝑍𝜏,𝑗)
Gumbel-Softmax(Sigmoid)는 Latent Expert(MoE) 구조 학습 시, 미분이 불가능한 이산적(Discrete) 선택 과정을 미분 가능한 형태(Continuous)로 근사해주는 함수
Q : 어떻게 이산적인 선택을 하면서 동시에 학습(역전파)을 시키는가? - 문제 상황 : "선택(Argmax)"은 미분이 안됨 - 상황 : 라우터가 experts A, B, C에 대해 각각 점수(확률)를 [0.1, 0.8, 0.1]로 냈다고 가정하면 - 원래 목표 : 확률이 가장 높은 B를 선택(Index = 1) - 수학적 연산 : argmax (최댓값의 인덱스 뽑기) 혹은 Categorical Sampling - 문제점 : argmax나 sampling은 계단 함수(Step function)와 같다. 위 예시에서 가장 높은 값이 인덱스 1이므로 결과는 원-핫 벡터 [0,1,0]으로 나오기 때문에 값이 툭 끊어짐. 따라서 기울기(Gradient)가 0이거나 정의되지 않음. 즉, 역전파(Backpropagation)가 여기서 막혀버려 라우터가 학습을 못 함
- 해결책 : Gumbel-Softmax(Sigmoid) (Reparameterization Trick) - 1 단계 : Gumbel Noise 더하기 라우터가 낸 점수(Logits)에 Gumbel 분포에서 뽑은 무작위 노이즈를 더함. 이 노이즈는 모델이 매번 똑같은 선택만 하지 않고, 약간의 무작위성을 갖게 해줌 - 2 단계 : Softmax(Sigmoid)로 근사하기 가장 큰 값을 딱 뽑는(argmax) 대신, Softmax 함수를 쓰는데, 여기에 Temperature(𝜏)라는 개념을 추가 Gumbel-Softmax 수식 결과는 [0.001, 0.998, 0.001] 처럼 One-hot vector(하나만 1이고 나머지 0)에 아주 가까운 연속적인 값 - 3 단계 : 𝜏 조절 𝜏가 높으면 : 분포가 평평해짐(모든 전문가를 골고루 섞어서 씀 -> 평균적인 학습) 𝜏가 0에 가까우면 : 분포가 뾰족해져서 argmax와 거의 똑같아짐 (확실하게 하나만 고름) - 기본적인 Latent Expert를 학습시키는 과정 1) Router의 예측 : 입력 데이터 x가 들어오면 라우터가 각 전문가에 대한 점수(Logits)를 계산 2) Gumbel-Softmax 적용 : 점수에 Gumbel 분포에서 뽑은 노이즈를 더하고, 𝜏를 적용한 Softmax를 통과시킴. 결과물 벡터 Z: [0.05, 0.90, 0.05] (전문가 2번이 강력하게 선택됨) 3) Expert 연산 (Weighted Sum) : 입력 x를 모든 전문가에게 통과시키되, 위에서 구한 Z값을 가중치로 곱해서 합침. Output = 0.05 * E_1(x) + 0.90 * E_2(x) + 0.05 * E_3(x) 4) 역전파 (Backpropagation) : 최종 결과와 정답 사이의 Loss를 구함. 이 Loss에 대한 미분값이 Z벡터를 타고 라우터까지 흘러감 (모든 연산이 더하기/곱하기/지수함수이므로 미분 가능) 5) 학습 결과: 라우터는 "아, 이 데이터는 전문가 2번에게 가중치를 많이 줬더니 Loss가 줄었네? 다음에도 2번으로 보내야지" 라고 학습하게 됨
추론 시 (또는 문서 T𝜏에 대한 “실제 적용될 LoRA”를 만들 때) 최종 𝐴𝜏, 𝐵𝜏는 아래처럼 계산
문서 T𝜏에 들어갈 LoRA는, 공유 expert들의 LoRA를 𝛼𝑖 가중치로 섞은 가중합
𝛼𝑖는 그냥 아무 값이 아니라, 활성화된(샘플링된) 로짓들을 정규화해서 만든 값
𝛼𝑖는 ^𝑍𝜏,𝑗를 합으로 나눈 값이라서 가중치 합이 1이 되는 형태
이 가중합 설계 덕분에, 공유 expert를 '다' 쓰는 게 아니라 일부만(희소 subset)써서도 문서마다 고유한 (𝐴𝜏,𝐵𝜏)를 만들 수 있음
마지막으로 Poly-PRAG가 만든 LoRA 업데이트 출력은, 원래 고정된 backbone 레이어 출력(𝑊0)에 더해지는 방식으로 적용
2.3 Poly-PRAG Inference
문서 전체를 커버하는 latent LoRA(공유 expert LoRA)로 문서 집합을 인코딩했기 때문에 문서 인코딩(LoRA 준비)을 오프라인에서 미리 끝낼 수 있고, 온라인 추론 단계에서는 어댑터를 새로 로드할 필요가 사실상 없음
새 쿼리 𝑞𝑡 가 들어오면, Poly-PRAG는 LoRA를 갈아끼우는 대신 latent routing(라우팅 함수)으로 “이번 쿼리/검색 결과에 맞는 latent LoRA들만” 직접 선택해서 활성화시킴
P-RAG에 비해 각 문서마다 LoRA 파라미터가 디스크에 저장되어 있지 않기 때문에 loading 시간이 사라진다는 뜻
대신, 검색된 문서에 맞는 LoRA를 만들기 위한 expert들을 조합하는 연산은 발생하는 듯
2.4 Computation and Storage Cost Analysis
Offline Storage Cost
문서가 |T|개 있고, 문서 하나당 LoRA 파라미터 수가 p라고 가정하면 기존 P-RAG(문서 1개↔LoRA 1개)에서는 저장량이 문서 수에 선형 비례해서 p|T|
반대로 Poly-PRAG는 문서마다 LoRA를 따로 저장하는 게 아니라, 소수의 latent LoRA expert(공유 전문가들)로 문서 전체를 인코딩하기 때문에 학습해야 할 파라미터가 𝑚×|T|규모이고 여기서 m은 latent LoRA 개수이고 𝑚 ≪T
따라서 𝑚×|T| < p|T|이므로 기존 P-RAG 보다 훨씬 적음
Online Computation
|d| : 문서 한 개 당 평균 토큰 길이
|c| : 검색된 문서의 수
|q| : 질문 길이
Standard RAG : 질문 + 검색 문서들이므로 c|d| + |q|
P-RAG : |q|
P-RAG가 기존 RAG에 비해 inference에서 계산량은 확실히 장점이 있음
하지만 새 질문이 오면 P-RAG는 이전에 주입했던 LoRA를 빼고(unload), 새로 검색된 문서들에 해당하는 LoRA를 다시 불러와서(load)주입해야 함
Poly-PRAG는 latent LoRA m개만 한 번 메모리에 올려두면 되고, 이후에는 라우팅 함수가 이번 쿼리/문서에 필요한 expert만 선택(활성화)하면 됨
새 쿼리가 오면 (1) 검색기가 문서를 가져오고, (2) 라우팅이 그 문서들을 표현하는 데 필요한 latent experts만 골라서 활성화
결론적으로 LoRA를 한 번만 로드해두고 계속 재사용
📍3. Experiments
3.1 Datasets
P-RAG와 동일하게 2wikimultihopQA(2WQA), HotpotQA, PopQA, ComplexWebQuestions 사용
3.2 Evaluation Metrics
P-RAG와 동일하게 F1 Score 사용
2WQA와 HQA는 질문의 유형에 따라 4개의 항목으로 세분화 (P-RAG와 동일)
개수도 각 데이터셋마다 첫 질문 300개 사용 (P-RAG와 동일)
3.3 Baselines
Vanilla : 외부 지식 없이, 원래 LLM이 단독으로 생성
Standard RAG : 기존 RAG
P-RAG
DyPRAG : 온라인 추론 시 문서를 LoRA 어댑터로 변환하는 하이퍼네트워크를 학습시키는 프레임워크
3.4 Appendix (아래 Ablation Study에서 더 자세히)
Training loss analysis
PRAG 또는 DyPRAG의 인코딩(문서 파라미터화) 과정에서, 성능은 각 문서를 LoRA로 1 epoch만 학습하는 설정을 기반으로 함
논문 저자들은 1 epoch만으로는 학습이 덜 되지 않을까?하는 생각으로 Training loss를 1 epoch vs 5 epoch 비교함 [Figure 6]
결론적으로 PRAG의 오프라인 인코딩 과정에서 학습 스텝(epochs)을 늘릴 필요가 있음
1 epoch만 학습하면 학습이 너무 일찍 멈춰, 손실이 크게 남은 과소적합(underfitting) 발생
반면에 5 epoch 학습은 손실이 효과적으로 수렴하게 해주고, 문서를 충분히 인코딩하여 PRAG 시스템에서 효과적 검색에 필요한 고품질 표현(high-quality representation)을 만들려면 충분한 학습 스텝이 중요함
결국 trade-off 발생
모델 품질(낮은 loss)을 얻으려면 더 많은 학습 스텝(더 긴 인코딩 시간)이 필요하며, 특히 대규모 코퍼스에서는 효율적인 인코딩 전략의 필요성이 더욱 커짐
LoRA rank analysis
PRAG에서는 네 가지 LoRA rank 모두 25 스텝 학습이 끝날 때 거의 동일한 최종 검증 손실(0.00에 가까움)로 수렴함
즉, LoRA rank size 영향 별로 없음
결론적으로 PRAG에서 데이터셋의 복잡도는 최소 rank만으로도 충분히 포착되며, 따라서 rank로 모델 용량을 더 늘려도 성능 향상 없음. 효율적으로 작은 LoRA를 공유/조합하는 방식이 더 합리적일 수 있음
Implementation Details
LoRA 학습에 사용한 데이터 증강법은 PRAG와 동일하게
LoRA 어댑터 학습에는 학습률 0.0003
LLama3-2.1B와 Qwen2.5-1.5B 실험은 모두 NVIDIA A100 80GB GPU 1장에서 수행
LLama3-8B의 경우 NVIDIA H100 80GB GPU 4장 사용
데이터 증강을 위해 DyPRAG 논문에서 제공한 전처리(pre-processing) 데이터셋 사용
3.5 Results
LLaMa3-2.1B, Qwen2.5-1.5B
모든 데이터셋에서 최고 성능 달성
LLaMa3-8B
2WQA Compare처럼 비교에 필요한 미세한 사실(정확한 수치/표현)을 찾아 답하는 질문에서는 기본 RAG가 앞섰고, Bridge(연결형)나 Compose(구성형)는 “문서 조각을 단순히 인용”하기보다, 질문 의도를 따라가며 연결/구성하는 추론 패턴에서는 Poly-PRAG가 앞섬
📍4. Ablation Study
4.1 LoRA rank analysis for PRAG and Poly-PRAG
두 방법 모두 1 epoch으로 학습 진행
두 방법 모두 LoRA rank와 Offline Storage가 선형적으로 증가
Poly-PRAG가 PRAG 대비 Storage cost에서 장점이 뚜렷함
같은 LoRA rank에서 PRAG의 거의 1%만 사용
4.2 The number of latent LoRA for Poly-PRAG
Poly-PRAG는 latent LoRA(공유 어댑터) + routing 구조라고 했는데, 그렇다면 모든 문서의 표현을 모두 담기에 몇 개의 LoRA Adapters가 필요한가?
[Figure 3] 참고. 결국 각 Task마다 세밀한 조정 필요
4.3 Offline Storage Comparison
[Table 3] 오프라인 인코딩 과정에서 PRAG/DyPRAG/Poly-PRAG 3가지 방법의 저장 요구량을 4개 QA 태스크(각 서브태스크당 문서 300개)별로 비교하고, 전체 저장량(“ALL”)도 함께 제시
같은 베이스 LLM을 쓰는 경우, PRAG와 DyPRAG는 모든 태스크에서 저장 요구량이 동일(둘다 1:1 인코딩 스키마 사용)
결정적으로, 가장 큰 모델(LLaMa3-8B)에서도 Poly-PRAG의 저장 요구량은 872MB로 관리 가능한 수준에 그침
결론적으로 Poly-PRAG는 인코딩된 표현을 압축해, 다양한 LLM 크기에서 100배 이상의 저장 절감을 제공
4.4 Offline Encoding Time Comparison
LLaMA3 1B 모델을 사용하고, LoRA rank는 2
Poly-PRAG는 모든 QA 태스크에서 PRAG(및 DyPRAG)보다 인코딩 시간이 유의미하게 낮고, 약 47%~60% 더 빠름
결론적으로 Poly-PRAG가 제공하는 큰 시간 절감은 확장성과 배포에서 핵심 장점이며, 특히 지식 소스의 초기 인덱싱/인코딩이 병목인 시스템에서 중요
4.5 Online Inference Time
Offline 과정 뿐만 아니라 Online에서 검색된 문서를 loading하는 mechanism이 PRAG와 Poly-PRAG의 차이점 중 하나
PRAG는 매 질문마다 검색된 문서에 따라 loading / unloading 반복
Poly-PRAG는 모든 문서에 대한 LoRA Adapter를 한 번만 loading 하면 됨
상대적 시간 절감률으로 계산했을 때, 일관되게 6%~14% Poly-PRAG가 더 time이 적음
상대적 시간 절감률
Poly-PRAG의 구조적 장점, 특히 매우 효율적인 LoRA 기반 적응 방식이 온라인 추론 단계에서 시간 감소로 이어짐
4.6 Which parts in the transformer to inject the LoRAs?
LoRA를 트랜스포머의 어디에 꽂아야 성능이 잘 나오는가?
Cross Injection Method가 모든 Task에서 우위
FFN Method가 Self-Attn Method보다 우위
📍5. Discussion
Poly-PRAG의 개선 방향
1) Dependency on Document ID
라우터가 ‘이 문서들 중에서’ 어떤 latent LoRA를 쓸지를 학습하는 방식이라서, 학습할 때 문서 목록이 고정되어 있다는 뜻
따라서 새 문서를 추가하면 routing 함수와 latent LoRA 어댑터를 둘 다 전체 재학습 필요
모델이 제한 없이 계속 늘어나는, 학습에서 보지 못한 문서 코퍼스에도 효과적으로 일반화할 수 있게 해주는 제로샷(zero-shot) 라우팅 메커니즘을 개발 필요
2) Lack of Semantic Control
latent LoRA를 “여러 문서가 공유하는 전문가 풀”로 쓰면 좋긴 한데, 그 전문가들이 각자 무슨 분야 담당인지가 자연스럽게 정렬되지 않음
특정 도메인/주제와 관련된 유용한 의미 정보를 어떤 어댑터가 가지고 있는지 명시적으로 파악하기가 어려움
📍6. Conclusion
기존 PRAG처럼 문서 조각마다 LoRA 어댑터를 하나씩 할당하는 방식과 달리, 공유 LoRA 어댑터 풀(pool)을 전략적으로 활용해 문서 전체를 인코딩
온라인 inference에서 Poly-PRAG는 질의마다 관련 어댑터 집합을 동적으로 선택·활성화하는 latent routing 함수 사용
💬 7. Takeaway
일단 PRAG의 Offline 과정과 Online 과정에서 불필요하고 과도한 계산량을 줄이기 위한 시도는 좋으나 일반화가 되지않아 RAG의 장점을 살리진 못한거 같다. RAG의 Motivation이 특정 시점의 데이터로 튜닝이 끝난 LLM이 그 이후 시점의 데이터를 보고 답을 하게 만드는 것인데 Poly-PRAG는 학습한 LoRA 조합으로 답을 생성하기 때문에 학습 데이터 이외의 질문에 대한 답은 과연 잘할까?의문이다. 문서를 LLM 파라미터로 집어넣으면서 새로운 질문에 대한 일반화가 가능한 방법론은 무엇이 있을까...😢
