Field Log · Entry

Learned Retrieval Policy: Self-RAG·FLARE·RouteRAG (9/10)

오늘의 결론

• Learned retrieval은 검색 model 하나가 아니라 언제·무엇을·어디서·얼마나 검색하고 언제 멈출지를 고르는 policy 문제입니다.
• Self-RAG는 retrieval과 critique를 reflection token으로, FLARE는 다음 문장의 low-confidence signal로 retrieval 시점을 다룹니다.
• Adaptive-RAG는 query complexity classifier로 no/single/iterative retrieval을 route하는 비교적 단순한 출발점입니다.
• 2026년 RouteRAG와 Reflective RAG는 multi-turn strategy를 RL로 최적화하지만, 연구 benchmark의 이득을 production 안전성으로 곧바로 일반화할 수는 없습니다.
• Authorization, source allowlist, call budget은 policy가 학습해 우회할 대상이 아니라 runtime이 강제할 constraint입니다.

앞 글에서는 retriever, reranker, generator를 각각 학습했습니다. 그런데 model이 좋아져도 orchestration은 여전히 고정일 수 있습니다.

모든 query
  → dense + BM25
  → top-100
  → rerank top-10
  → generate

이 pipeline은 간단한 인사말에도 검색하고, 복잡한 multi-hop 질문에도 한 번만 검색합니다. 다음 네 질문은 필요한 action이 다릅니다.

"안녕"                         → no retrieval
"환불 기한은?"                 → one text retrieval
"A를 인수한 회사 CEO는?"       → multi-hop retrieval
"graph와 보고서가 충돌하면?"   → graph + text + verification

Retrieval policy는 이 차이를 state와 action으로 표현합니다.

그림 1. Policy는 답을 직접 생성하는 능력뿐 아니라 검색 action의 순서와 budget을 결정한다. Safety constraint는 policy 바깥의 runtime gate가 강제한다.

---

Retrieval Policy가 결정하는 것

고정 top-k RAG에서는 다음 값이 configuration입니다.

retrieval:
  enabled: true
  source: hybrid_text
  top_k: 20
  rerank_k: 5
  max_rounds: 1

Adaptive policy에서는 일부가 action이 됩니다.

1. 검색할 것인가?
2. 지금 검색할 것인가, 더 생성한 뒤 검색할 것인가?
3. Text, graph, SQL, web, visual 중 어디로 갈 것인가?
4. 어떤 query와 filter를 사용할 것인가?
5. 몇 개를 가져올 것인가?
6. 결과가 충분한가?
7. Query를 고쳐 다시 검색할 것인가?
8. 답할 것인가, abstain할 것인가?

모든 축을 한 번에 학습하면 action space가 너무 큽니다. 가장 비싼 failure가 있는 축부터 adaptive하게 만듭니다.

Rule, Classifier, Generative Policy, RL

1. Rule-Based Policy

if greeting(query):
    return ANSWER_WITHOUT_RETRIEVAL
if contains_current_date_constraint(query):
    return RETRIEVE_LATEST_TEXT
if looks_multihop(query):
    return ITERATIVE_RETRIEVAL
return SINGLE_RETRIEVAL

장점은 재현성, 설명 가능성, 즉시 rollback입니다. 많은 production system의 좋은 baseline입니다.

2. Supervised Classifier

Input feature에서 route label을 예측합니다.

f(query, conversation, corpus metadata)
→ {no_retrieval, single, iterative, graph, visual}

Label을 human이 만들거나 각 route의 실제 outcome으로 만들 수 있습니다.

3. Generative Policy

Language model이 action token이나 structured tool call을 생성합니다.

{
  "action": "retrieve_text",
  "query": "Orion S2 approved shutdown temperature",
  "filters": { "status": "approved" },
  "reason_code": "missing_current_threshold"
}

복잡한 state를 다루기 쉽지만 invalid action과 prompt injection을 runtime이 막아야 합니다.

4. Reinforcement Learning Policy

여러 action 뒤의 final quality와 cost를 reward로 학습합니다.

state → action → observation → new state → ... → terminal reward

Long-horizon credit assignment와 reward design이 어려워집니다.

MDP로 모델링하기

Retrieval agent는 environment의 모든 정보를 직접 알지 못하므로 엄밀히는 부분 관측 문제가 될 수 있습니다. 실무 설계를 위해 state-action-observation-reward로 분해해 봅시다.

State

type RetrievalState = {
  originalGoal: string;
  conversationSummary: string;
  knownFacts: Fact[];
  unresolvedSlots: Slot[];
  evidenceLedger: Evidence[];
  contradictions: Conflict[];
  visitedQueries: string[];
  sourceCoverage: string[];
  confidence: number;
  callsUsed: number;
  tokensUsed: number;
  latencyUsedMs: number;
  deadlineMs: number;
};

Hidden chain-of-thought를 저장하지 않아도 됩니다. Query, selected evidence, unresolved slot, action, observation처럼 검증 가능한 state만 남깁니다.

Action

type RetrievalAction =
  | { type: "answer_without_retrieval" }
  | { type: "retrieve_text"; query: string; topK: number; filters: Filters }
  | { type: "retrieve_graph"; seeds: string[]; hops: number }
  | { type: "retrieve_visual"; query: string; topK: number }
  | { type: "reformulate"; targetSlot: string }
  | { type: "rerank_more"; candidateIds: string[] }
  | { type: "verify_claim"; claimId: string }
  | { type: "answer" }
  | { type: "abstain"; reason: string };

Observation

type RetrievalObservation = {
  candidates: Evidence[];
  relevanceEstimate: number;
  supportDelta: number;
  newFacts: Fact[];
  newConflicts: Conflict[];
  sourceFreshness: string;
  actualCost: number;
  actualLatencyMs: number;
  error?: "timeout" | "denied" | "empty" | "invalid_query";
};

Reward

R = + task_success
    + grounded_support
    + calibrated_abstention
    - retrieval_cost
    - latency_penalty
    - redundant_call_penalty
    - unsupported_claim_penalty
    - safety_violation_penalty

Penalty weight 하나가 policy 행동을 크게 바꿀 수 있습니다.

Policy와 Constraint를 분리하라

Policy가 다음 action을 제안해도 runtime이 거부해야 합니다.

{
  "type": "retrieve_graph",
  "seeds": ["restricted-customer-record"],
  "hops": 9
}

Runtime gate:

function enforce(action: RetrievalAction, auth: AuthContext, budget: Budget) {
  assert(isAllowedAction(action.type, auth));
  assert(actionWithinSourceAllowlist(action, auth));
  assert(actionWithinAclScope(action, auth));
  assert(actionWithinHopLimit(action, budget));
  assert(actionWithinDeadline(action, budget));
  return sanitizeQueryAndFilters(action);
}

Reward로 안전성을 “학습”하는 것만으로는 부족합니다. 드문 unsafe state가 training에 없을 수 있고 reward hacking이 가능합니다.

Self-RAG: Reflection Token으로 Retrieve·Critique하기

Self-RAG는 language model이 retrieval을 필요에 따라 수행하고, retrieved passage와 generation을 reflection token으로 평가하도록 학습하는 접근입니다.

개념적으로 reflection은 다음 질문을 표시합니다.

Retrieve: 검색이 필요한가?
ISREL:    retrieved passage가 query에 relevant한가?
ISSUP:    response가 passage에 의해 supported되는가?
ISUSE:    response가 task에 useful한가?

논문의 실제 token/label 정의와 구현 세부는 version을 확인해야 하지만, 핵심은 critique를 외부 후처리만이 아니라 generation policy 안의 명시적 signal로 만든다는 점입니다.

Self-RAG Flow 직관

input
  → retrieve? [yes/no/continue]
  → passage
  → relevant? [yes/no]
  → generate segment
  → supported? [fully/partially/no]
  → useful? [rating]
  → continue or finish

Training Data

Reflection label이 필요합니다. 원 연구는 critic model을 활용해 reflection token supervision을 만들고 generator를 학습하는 절차를 제시합니다.

Production adaptation에서는 다음을 구분합니다.

• Human relevance label
• Model-generated reflection label
• Deterministic support check
• Final outcome label

Model judge가 만든 supported를 ground truth로 취급하지 않습니다.

Inference Control

Reflection token score를 이용해 candidate generation을 rerank하거나 retrieval threshold를 조절할 수 있습니다.

sequence_score = generation_likelihood
               + w_rel · relevance_score
               + w_sup · support_score
               + w_use · utility_score

Weight는 task와 risk별 validation에서 정합니다.

Self-Critique의 한계

• 같은 model이 만든 오류를 같은 model이 놓칠 수 있습니다.
• Reflection label semantics가 drift할 수 있습니다.
• Critique token이 그럴듯해도 실제 source support와 다를 수 있습니다.
• Added token과 decoding logic가 serving stack을 복잡하게 합니다.

외부 verifier와 source-grounded metric을 유지합니다.

FLARE: 앞으로 쓸 문장이 불확실할 때 검색하기

FLARE는 long-form generation 중 다가올 문장을 먼저 예측하고, 낮은 confidence token이 포함되면 그 예측을 query로 retrieval한 뒤 문장을 다시 생성하는 active retrieval 접근입니다.

current draft
  → predict next sentence
  → detect low-confidence tokens
  → use forward-looking content as retrieval query
  → retrieve evidence
  → regenerate grounded sentence
  → continue

왜 Original Query만 반복하지 않는가

Long-form answer는 진행하며 새로운 topic에 도달합니다.

Original query: "Apollo mission의 기술적 유산을 설명해 줘."

Later sentence topic:
"이 guidance computer의 integrated circuit 수요는 ..."

나중 문장에 필요한 evidence는 original query보다 예측된 upcoming content가 더 구체적인 query가 될 수 있습니다.

Confidence는 무엇인가

Token probability를 사용할 수 있지만 calibration이 필요합니다.

trigger if min(token_confidence in next_sentence) < τ

문제:

• Model은 틀린 사실에도 높은 confidence를 가질 수 있습니다.
• 고유명사 tokenization 때문에 confidence가 낮아질 수 있습니다.
• Temperature와 decoding 설정이 confidence를 바꿉니다.
• API가 token log probability를 제공하지 않을 수 있습니다.

Alternative signal로 semantic uncertainty, verifier disagreement, missing citation을 사용할 수 있습니다.

FLARE가 맞는 Task

• 긴 report 생성
• 여러 paragraph의 factual writing
• 생성 중 topic이 이동하는 설명
• 문장별 citation이 필요한 작업

짧은 single-fact QA에서는 overhead가 과할 수 있습니다.

Adaptive-RAG: Query Complexity로 Route 선택하기

Adaptive-RAG 연구는 작은 classifier가 incoming query의 complexity level을 예측하고 세 전략 사이를 선택합니다.

Level A → no retrieval
Level B → single-step retrieval
Level C → iterative retrieval

Label을 어떻게 만드는가

논문은 model의 실제 predicted outcome과 dataset의 inductive bias를 이용해 complexity label을 자동 수집하는 방법을 사용합니다. 여기서 가져올 실무 원칙은 query 표면만 보고 임의 label을 붙이지 말고 route별 outcome을 관찰해 label을 만든다는 것입니다.

def oracle_route(example, routes):
    results = [run(route, example) for route in routes]
    feasible = [r for r in results if r.quality >= QUALITY_FLOOR]
    return min(feasible, key=lambda r: r.cost).route

실제 oracle은 모든 route를 실행해야 하므로 training/offline에서만 만듭니다.

Complexity가 곧 Retrieval Need는 아니다

어려운 수학 문제는 retrieval 없이 reasoning이 필요할 수 있고, 쉬운 최신 환율 질문은 retrieval이 반드시 필요합니다.

Feature에 다음을 분리합니다.

reasoning complexity
knowledge freshness
corpus specificity
evidence availability
authorization
answer risk

세 접근 비교

접근	결정 시점	Signal	대표 Action Granularity
Adaptive-RAG	주로 query 시작	complexity classifier	no/single/iterative route
Self-RAG	generation 중	reflection tokens	retrieve·critique·continue
FLARE	다음 문장 전	low-confidence future tokens	retrieve and regenerate sentence

하나가 다른 하나의 최신 version은 아닙니다. 결정 시점과 supervision이 다릅니다.

RouteRAG: Text와 Graph 사이를 RL로 Route하기

2026년 ACL Findings에 실린 RouteRAG는 text와 graph evidence를 함께 쓰는 환경에서 multi-turn adaptive RAG를 RL로 학습하는 연구입니다.

논문이 다루는 action 직관은 다음과 같습니다.

reason
retrieve text
retrieve graph
integrate observation
retrieve again
produce final answer

Graph retrieval은 relational structure에 유용하지만 text retrieval보다 비쌀 수 있습니다. RouteRAG는 task outcome뿐 아니라 retrieval efficiency를 고려하는 2단계 training framework를 제안하고, 언제 reason하고 text/graph 중 무엇을 검색하며 언제 답할지를 unified generation policy로 최적화합니다.

실무에 가져올 점

• Source type도 action으로 모델링할 수 있습니다.
• Expensive graph call에 별도 penalty를 둘 수 있습니다.
• Multi-turn trajectory 전체의 outcome을 봐야 합니다.
• Fixed hybrid pipeline과 learned route를 비교해야 합니다.

그대로 가져오면 안 되는 점

논문은 다섯 QA benchmark에서 연구한 결과입니다. Production의 ACL, prompt injection, partial outage, cost contract, domain graph quality까지 자동으로 검증한 것은 아닙니다. 먼저 offline simulator와 shadow traffic에서 재현합니다.

Reflective RAG: Evaluation Signal과 Strategy를 분리하기

2026년 ACL Findings의 Reflective RAG: Self-Evaluation Driven Strategy Optimization in Agentic Retrieval-Augmented Generation은 retrieved content의 utility를 reflection tag로 평가하고 이후 policy를 안내하는 framework를 제안합니다.

Training은 두 단계입니다.

Stage 1 · SFT
  self-corrected labels와 internal uncertainty를 이용해
  reflection signal의 의미와 기본 post-evaluation strategy를 학습

Stage 2 · RL
  reflection-guided constraint로 strategy를 최적화하고
  dynamic KL regularization으로 안정화

중요한 설계 아이디어는 평가 의미를 먼저 어느 정도 고정한 뒤 전략을 최적화하는 것입니다. Reflection semantics와 policy가 동시에 자유롭게 변하면 relevant token의 뜻 자체가 reward에 맞춰 왜곡될 수 있습니다.

논문은 다섯 knowledge-intensive QA benchmark에서 강한 agentic baseline 대비 결과를 보고합니다. 이것도 해당 실험 범위의 결과이며 domain production 보장은 아닙니다.

Reward Design

Outcome Reward만 쓸 때

+1 exact answer
 0 wrong answer

문제가 있습니다.

• Answer string을 추측해 맞히면 retrieval을 배우지 않을 수 있습니다.
• Partial support와 citation quality를 구분하지 않습니다.
• 비용이 반영되지 않습니다.
• 긴 trajectory의 어느 action이 좋았는지 알기 어렵습니다.

Shaped Reward 예시

R_terminal = 3.0 · answer_correct
           + 2.0 · all_claims_supported
           + 1.0 · citations_correct
           + 1.0 · correct_abstention

R_step = 0.3 · new_required_fact
       - 0.1 · text_call
       - 0.4 · graph_call
       - 0.2 · duplicate_query
       - 0.001 · latency_ms

숫자는 예시입니다. Step reward가 너무 크면 final answer 없이 evidence만 모을 수 있고, cost penalty가 너무 크면 검색을 회피합니다.

Reward Hacking 사례

1. Search Avoidance

Retrieval penalty가 커서 internal memory로 추측합니다.

2. Citation Spam

Citation 개수 reward를 얻으려고 모든 문장에 source를 붙입니다.

3. Easy Abstention

Unsupported claim penalty를 피하려 항상 모르겠습니다라고 답합니다.

4. Query Fragmentation

Step reward를 얻기 위해 같은 질문을 미세하게 바꿔 반복합니다.

5. Judge Exploitation

Answer judge가 좋아하는 표현을 생성하지만 source에는 없습니다.

6. Graph Shortcut

Graph edge label에 answer가 노출돼 reasoning 없이 복사합니다.

Reward component별 behavior와 adversarial validation을 봅니다.

Stop Policy

좋은 retrieval policy는 무엇을 찾을지만큼 언제 멈출지도 배웁니다.

Success Stop

• 모든 required claim이 evidence를 가집니다.
• Contradiction이 authority/time으로 해소됐습니다.
• Citation source가 accessible합니다.

Insufficient Stop

• Search space를 충분히 탐색했지만 required evidence가 없습니다.
• Source가 answer를 명시하지 않습니다.

No-Progress Stop

• 새 검색이 새 fact를 추가하지 않습니다.
• Query가 반복됩니다.
• Candidate overlap이 threshold를 넘습니다.

Budget Stop

• call, token, latency, cost limit에 도달했습니다.

def should_stop(state):
    if state.all_required_claims_supported():
        return "answer"
    if state.budget.exhausted():
        return "budget_stop"
    if state.no_progress(rounds=2):
        return "no_progress"
    if state.search_space_exhausted():
        return "insufficient"
    return "continue"

Learned stop action이 있어도 hard budget은 runtime이 강제합니다.

Offline Trajectory Dataset

{
  "task_id": "qa-881",
  "initial_state": { "query": "..." },
  "steps": [
    {
      "action": { "type": "retrieve_text", "query": "..." },
      "observation_ids": ["ev-1", "ev-2"],
      "new_fact_count": 1,
      "cost": 0.003,
      "latency_ms": 182
    },
    {
      "action": { "type": "retrieve_graph", "seeds": ["entity-7"] },
      "observation_ids": ["ev-3"],
      "new_fact_count": 2,
      "cost": 0.018,
      "latency_ms": 441
    }
  ],
  "outcome": {
    "answer_correct": true,
    "claims_supported": true,
    "total_cost": 0.024
  },
  "behavior_policy": "rules-v5"
}

Behavior Policy Bias

기존 rule policy가 graph search를 거의 호출하지 않았다면 log에는 graph action의 outcome이 없습니다. Logged data만으로 다른 action의 효과를 알기 어렵습니다.

완화:

• offline environment에서 safe exploration
• 작은 randomized route experiment
• counterfactual evaluation with propensity logging
• human-authored expert trajectories
• simulator와 실제 traffic의 gap 측정

단, high-risk source나 action을 random exploration하지 않습니다.

SFT부터 시작하기

좋은 action trajectory가 있으면 imitation learning으로 시작합니다.

state serialization
  → target action JSON
  → observation
  → next target action

SFT가 action schema, basic routing, stop behavior를 안정시킨 뒤 RL을 고려합니다.

SFT Data Mix

• rule policy의 성공 trajectory
• human-corrected failure trajectory
• oracle route trajectory
• no-retrieval example
• early-stop example
• denied/error observation example
• prompt injection을 무시하는 example

RL은 나쁜 action grammar를 처음부터 발견하는 도구가 아닙니다.

Policy Evaluation

Final Quality

• answer correctness
• claim support
• citation precision/recall
• correct abstention
• contradiction resolution

Trajectory Quality

• required evidence coverage per step
• first useful evidence step
• redundant call rate
• duplicate query rate
• unsupported action rate
• stop reason accuracy

Efficiency

• retrieval calls per query
• source별 call 수
• graph traversal cost
• tokens and latency p50/p95
• cache hit

Policy Metric

• oracle best route 대비 regret
• quality floor를 만족하는 최소 cost와의 차이
• action probability calibration
• budget violation rate
• runtime gate rejection rate

Policy Regret

각 query에 여러 route를 offline 실행해 quality floor를 만족하는 가장 싼 route를 oracle로 정의할 수 있습니다.

regret(query)
= utility(oracle_route) - utility(policy_route)

Utility는 quality와 cost를 합치지만 weight가 stakeholder preference를 숨길 수 있습니다. Quality-cost Pareto frontier도 함께 보여 줍니다.

Policy A: accuracy 0.84, 1.2 calls
Policy B: accuracy 0.87, 3.9 calls
Policy C: accuracy 0.87, 2.1 calls  ← B를 dominate

Counterfactual Replay

같은 frozen corpus snapshot과 tool response cache에서 여러 policy를 replay합니다.

replay_contract:
  corpus_snapshot: corpus-2026-07-16
  text_index: text-v42
  graph_index: graph-v18
  tool_response_cache: replay-991
  model_versions:
    generator: lm-v7
    verifier: verify-v3
  max_steps: 8

Tool 결과가 매번 바뀌면 policy 비교가 불공정합니다. 먼저 deterministic replay, 그다음 live shadow로 갑니다.

Deployment Ladder

1. Observe Only

Policy가 action을 제안하지만 기존 rule이 실행합니다. Disagreement를 기록합니다.

2. Shadow Execute

Policy action을 별도 sandbox에서 실행해 cost와 outcome을 비교합니다. User response에는 사용하지 않습니다.

3. Bounded Canary

Low-risk query와 작은 traffic에서 실행합니다. Source와 step 수를 제한합니다.

4. Selective Expansion

Calibration이 좋은 query slice만 늘립니다.

5. Continuous Audit

Corpus·model·price·latency가 바뀌면 policy frontier를 다시 평가합니다.

Learned Policy가 필요 없는 경우

• Query type이 두세 개이고 rule로 잘 분리됩니다.
• Retrieval cost가 매우 낮고 quality penalty가 없습니다.
• Training trajectory와 reliable reward가 없습니다.
• Action이 high-risk라 exploration을 허용할 수 없습니다.
• Corpus와 workflow가 자주 바뀌어 policy가 금방 stale해집니다.
• Observability가 없어 first failure를 모릅니다.

작은 calibrated classifier가 큰 RL agent보다 나을 수 있습니다.

흔한 오해와 처방

1. Self-RAG는 Prompt로 “스스로 검토해”라고 하는 것이다

원 연구는 reflection token supervision과 학습·inference control을 포함합니다.

처방: Prompted self-check와 trained reflection policy를 구분합니다.

2. Low Confidence면 항상 Retrieval해야 한다

Token confidence는 calibration과 tokenizer에 영향을 받습니다.

처방: FLARE trigger를 actual factual error와 calibrate하고 support signal을 결합합니다.

3. Query가 복잡하면 Multi-hop Retrieval이다

Reasoning complexity와 external knowledge need는 다릅니다.

처방: freshness·corpus specificity·evidence availability를 별도 feature로 둡니다.

4. RL이면 Handcrafted Rule이 필요 없다

Action schema, safety constraint, budget, reward는 여전히 사람이 설계합니다.

처방: Runtime guardrail과 deterministic fallback을 유지합니다.

5. Final Answer Reward만 있으면 된다

Guessing, search avoidance, citation spam을 유발할 수 있습니다.

처방: support·cost·abstention reward와 behavior audit를 함께 둡니다.

6. Model의 Reflection은 Ground Truth다

Self-evaluation도 틀리고 semantics가 drift할 수 있습니다.

처방: Human calibration, source entailment verifier, reflection stability metric을 사용합니다.

Production 체크리스트

• policy가 결정할 축을 retrieval need·timing·source·query·stop으로 분리했다.
• rule과 supervised classifier baseline이 있다.
• state에 goal·unresolved slot·evidence·conflict·budget이 있다.
• action은 typed schema이며 invalid field가 거부된다.
• authorization·allowlist·budget은 runtime이 강제한다.
• document instruction이 policy action을 직접 바꾸지 못한다.
• no-retrieval과 correct-abstention example이 있다.
• reward component별 hacking behavior를 audit한다.
• success·insufficient·no-progress·budget stop을 구분한다.
• behavior policy와 action propensity를 log한다.
• deterministic tool replay environment가 있다.
• final quality와 trajectory quality를 함께 평가한다.
• source별 call cost와 p95 latency를 측정한다.
• oracle route regret와 quality-cost frontier를 본다.
• observe→shadow→bounded canary 순서로 배포한다.
• deterministic fallback과 policy rollback이 있다.

스스로 확인하기

1. Retriever model 학습과 retrieval policy 학습은 무엇이 다른가?
2. Self-RAG의 reflection token과 FLARE의 low-confidence trigger는 retrieval 시점을 어떻게 다르게 정하는가?
3. Adaptive-RAG의 query complexity와 실제 retrieval need가 항상 일치하지 않는 이유는 무엇인가?
4. Retrieval cost penalty를 크게 주면 어떤 reward hacking이 생길 수 있는가?
5. Learned policy가 authorization이나 max-call constraint를 직접 결정하게 하면 안 되는 이유는 무엇인가?

다음 글에서는 지금까지 만든 graph·multi-hop·multimodal·long-context·trained model·learned policy를 하나의 RAGAS·ARES·RAGChecker 기반 평가와 실험 설계로 통합합니다.

참고자료

• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
• Active Retrieval Augmented Generation — FLARE
• Adaptive-RAG: Learning to Adapt Retrieval-Augmented LLMs through Question Complexity
• RouteRAG: Efficient Retrieval-Augmented Generation from Text and Graph via Reinforcement Learning
• Reflective RAG: Self-Evaluation Driven Strategy Optimization in Agentic RAG