Xây dựng Agentic RAG có trạng thái cho truy vấn nhiều bước

Tóm tắt nội dung

• Với truy vấn nhiều bước, thông tin cần tìm ở bước sau thường phụ thuộc vào bằng chứng vừa thu được ở bước trước; pipeline retrieve-once-then-generate vì vậy có thể không đủ.
• Trạng thái của Agentic RAG nên lưu câu hỏi gốc, mục tiêu chưa giải quyết, truy vấn đã thực hiện, bằng chứng, provenance, ngân sách và trạng thái dừng.
• Vòng lặp hiệu quả cần tách rõ các thao tác: chọn bước tiếp theo → truy xuất → đánh giá bằng chứng → cập nhật state → quyết định truy xuất tiếp hay trả lời.
• Điều kiện dừng, phát hiện không tiến triển và kiểm soát query drift quan trọng không kém retriever hay LLM vì chúng ngăn agent lặp vô hạn hoặc rời khỏi câu hỏi ban đầu.

Vòng lặp có trạng thái trong Agentic RAG giải quyết một hạn chế quan trọng của RAG một lượt: với câu hỏi nhiều bước, truy vấn cần thực hiện tiếp theo thường chỉ xuất hiện sau khi hệ thống đã tìm được một phần câu trả lời. Thay vì cố lấy mọi tài liệu trong một lần retrieval, hệ thống duy trì một state tường minh và lặp giữa lập kế hoạch, truy xuất, kiểm tra bằng chứng và cập nhật mục tiêu.

Agentic RAG không phải một thuật toán duy nhất có kiến trúc được chuẩn hóa. Có thể xem đây là một nhóm thiết kế kết hợp RAG với cơ chế quyết định nhiều bước; các công trình như ReAct, IRCoT, FLARE, Self-RAG và Adaptive-RAG lần lượt cho thấy giá trị của việc xen kẽ hành động với suy luận, truy xuất theo từng bước, quyết định thời điểm retrieval, tự đánh giá bằng chứng và chọn chiến lược retrieval theo độ phức tạp của truy vấn [2]–[6].

Vì sao RAG một lượt gặp khó với truy vấn nhiều bước?

RAG cổ điển kết hợp bộ nhớ tham số của mô hình ngôn ngữ với bộ nhớ ngoài được truy xuất từ một kho tài liệu [1]. Một pipeline ứng dụng thường có dạng đơn giản:

Question → Retrieve(q) → Context → LLM → Answer

Cấu trúc này phù hợp khi một truy vấn retrieval đủ để tìm ra các tài liệu chứa phần lớn bằng chứng cần thiết. Vấn đề xuất hiện với câu hỏi nhiều chặng, nơi thực thể hoặc quan hệ cần dùng cho lần tìm kiếm thứ hai chưa có trong câu hỏi ban đầu.

Ví dụ, xét câu hỏi giả định: “Ai sáng lập tổ chức đã phát triển Project Aurora?”. Kho tài liệu có thể không chứa một đoạn duy nhất trả lời toàn bộ câu hỏi. Hệ thống trước hết cần tìm:

Bước 1: Project Aurora được phát triển bởi tổ chức nào?

Bước 2: Sau khi biết đó là Lab Delta, truy vấn tiếp theo mới trở thành: Ai sáng lập Lab Delta?

Trivedi và cộng sự mô tả đúng hiện tượng này trong IRCoT: đối với câu hỏi nhiều bước, nội dung cần retrieval tiếp theo phụ thuộc vào những gì đã được suy ra từ kết quả retrieval trước [3]. Vì vậy, retrieval và xử lý bằng chứng cần được xen kẽ thay vì coi retrieval là một bước cố định ở đầu pipeline.

FLARE mở rộng trực giác tương tự cho sinh văn bản dài bằng cách chủ động quyết định khi nào và cần truy xuất nội dung gì trong quá trình generation [4]. Self-RAG cũng tránh quan niệm “luôn lấy cố định k passage”, thay vào đó học cách yêu cầu retrieval và đánh giá tài liệu khi cần [5]. Điểm chung của các hướng này là retrieval trở thành một hành động có điều kiện, không còn là bước tiền xử lý duy nhất.

State trong Agentic RAG thực sự phải lưu những gì?

“Có trạng thái” ở đây không có nghĩa hidden state của Transformer, RNN hay mô hình ngôn ngữ. Nó là trạng thái workflow ở tầng ứng dụng: dữ liệu có cấu trúc được truyền từ iteration này sang iteration tiếp theo để agent biết mình đã làm gì, còn thiếu gì và có nên tiếp tục hay không.

Một state tối thiểu cho Agentic RAG có thể biểu diễn ở bước t như sau:

S_t = { q₀, P_t, E_t, H_t, B_t, status_t }

Đây là một biểu diễn kỹ thuật tổng quát, không phải công thức của một paper cụ thể. Trong đó:

• q₀: câu hỏi gốc, luôn được giữ nguyên để chống query drift.
• P_t: các mục tiêu hoặc câu hỏi con còn chưa giải quyết.
• E_t: tập bằng chứng đã chấp nhận cùng nguồn gốc tài liệu.
• H_t: lịch sử hành động như query, document ID, quyết định accept/reject và lỗi tool.
• B_t: ngân sách còn lại, ví dụ số bước, token, thời gian hoặc số lần gọi retriever.
• status_t: running, done, failed hoặc stopped.

Một điểm thiết kế quan trọng là không cần lưu chuỗi suy luận nội bộ dài của LLM. Với hệ thống production, state nên lưu những dữ liệu có thể kiểm tra: subgoal, action, document, fact, score, lỗi và quyết định. Cách này vừa dễ debug hơn vừa tránh biến state thành một transcript reasoning khó kiểm soát.

Field	Ví dụ	Mục đích
original_question	Ai sáng lập tổ chức đã phát triển Project Aurora?	Giữ mục tiêu gốc trong mọi vòng lặp.
pending_goals	Tìm tổ chức phát triển Aurora.	Biết phần nào của câu hỏi chưa được giải quyết.
evidence	doc_17 → Aurora được phát triển bởi Lab Delta.	Làm căn cứ cho bước tiếp theo và câu trả lời cuối.
seen_queries	Hash hoặc chuỗi query đã dùng.	Phát hiện vòng lặp truy vấn lặp lại.
budget	max_steps = 6	Đặt giới hạn chi phí và bảo đảm termination.

Thiết kế vòng lặp: plan → retrieve → evaluate → update

Một Agentic RAG nhiều bước có thể được mô hình hóa như một máy trạng thái. Tại mỗi iteration, policy chọn hành động dựa trên state hiện tại, tool tạo observation, sau đó state được cập nhật:

a_t = π(S_t)

o_t = Tool(a_t)

S_t+1 = U(S_t, a_t, o_t)

Trong triển khai thực tế, π có thể là LLM, classifier hoặc logic kết hợp; Tool có thể là vector search, BM25, SQL, web search hoặc API; còn U nên là logic cập nhật state càng xác định càng tốt.

Hình 1. Vòng lặp Agentic RAG có trạng thái. Sơ đồ là thiết kế tổng hợp dựa trên nguyên tắc interleaved reasoning/action và adaptive retrieval trong [2]–[6].

1. Chọn bước tiếp theo

Planner không nhất thiết phải lập toàn bộ kế hoạch ngay từ đầu. Với nhiều truy vấn, cách an toàn hơn là xác định subgoal kế tiếp có thể kiểm chứng, thực hiện retrieval rồi điều chỉnh kế hoạch dựa trên bằng chứng mới. Đây là tinh thần gần với việc xen kẽ reasoning và action trong ReAct [2] và retrieval với reasoning trong IRCoT [3].

2. Retrieval theo state hiện tại

Query ở iteration mới nên được tạo từ câu hỏi gốc cộng với các thực thể hoặc quan hệ đã được xác nhận. Không nên chỉ đưa toàn bộ lịch sử vào LLM rồi yêu cầu nó “tìm tiếp”, vì cách đó dễ tích lũy nhiễu và làm query trôi dần khỏi mục tiêu ban đầu.

3. Đánh giá bằng chứng trước khi cập nhật state

Không nên coi mọi document trả về từ retriever là fact. Một evidence grader có thể đánh giá riêng ít nhất bốn thuộc tính: tài liệu có liên quan đến subgoal không, có thực sự hỗ trợ claim không, đã bao phủ đủ subgoal chưa và có mâu thuẫn với bằng chứng trước đó không. Self-RAG cho thấy retrieval và critique có thể được tích hợp vào chính quá trình generation thay vì chấp nhận passage một cách vô điều kiện [5].

Điều kiện dừng: phần thường bị bỏ quên của Agentic RAG

Một vòng lặp agent không có termination policy rõ ràng rất dễ biến thành chuỗi retrieval tốn chi phí nhưng không tạo thêm thông tin. Không nên giao toàn bộ quyết định dừng cho một prompt kiểu “hãy cho biết khi nào bạn đã đủ thông tin”; state machine cần có các điều kiện cứng độc lập với LLM.

Một policy thực dụng có thể dừng khi bất kỳ điều kiện nào sau đây xảy ra:

• Solved: mọi subgoal bắt buộc đã có bằng chứng hỗ trợ.
• Max steps: số iteration đạt giới hạn.
• Budget exhausted: vượt ngân sách token, latency, API hoặc retrieval.
• Repeated query: planner tạo lại truy vấn đã dùng mà không có state mới.
• No progress: một số vòng liên tiếp không thêm document mới hoặc không giải quyết thêm subgoal.
• Insufficient evidence: hệ thống không thể tìm bằng chứng đủ mạnh và nên trả về trạng thái không chắc chắn thay vì tiếp tục suy đoán.

Nếu đã phân rã câu hỏi thành m subgoal rõ ràng, có thể sử dụng một thước đo coverage đơn giản:

Coverage = số subgoal đã có bằng chứng / tổng số subgoal bắt buộc

Đây là metric kỹ thuật minh họa, không phải metric tiêu chuẩn của Agentic RAG. Trong production, “đã có bằng chứng” cần một định nghĩa cụ thể theo ứng dụng, ví dụ ít nhất một nguồn có độ tin cậy cao hoặc hai nguồn độc lập cho một claim quan trọng.

Ngăn query drift

Query drift xảy ra khi mỗi lần rewrite lại dựa quá nhiều vào output trước đó khiến agent dần giải một câu hỏi khác. Cách phòng thủ đơn giản là mọi planner call đều nhận original_question, current subgoal và tập fact đã được chấp nhận; dữ liệu chưa được kiểm chứng không được nâng thành fact trong state.

State cũng nên giữ provenance ở mức document ID hoặc URL. Nếu câu trả lời cuối không thể ánh xạ từng claim quan trọng về bằng chứng cụ thể, pipeline đã mất một lợi thế lớn của RAG: khả năng kiểm tra nguồn tri thức bên ngoài.

Ví dụ Python: xây state loop tối giản có thể chạy

Ví dụ dưới đây sử dụng một knowledge base giả lập để tập trung vào cơ chế state loop. Nó không phải implementation của ReAct, IRCoT hay một framework Agentic RAG cụ thể. Trong hệ thống thật, các hàm next_query, retrieve và enough_evidence có thể lần lượt được thay bằng LLM planner, search engine và evidence grader.

import re
from dataclasses import dataclass, field

DOCUMENTS = { "d1": "Project Aurora được phát triển bởi Lab Delta.", "d2": "Lab Delta được sáng lập bởi Minh Tran vào năm 2019.", "d3": "Project Borealis được phát triển bởi Lab Sigma.",
}

@dataclass class Evidence:
doc_id: str
text: str
query: str

@dataclass class AgentState:
question: str
evidence: list[Evidence] = field(default_factory=list)
seen_queries: set[str] = field(default_factory=set)
step: int = 0
max_steps: int = 4
status: str = "running"
answer: str | None = None

def tokens(text: str) -> set[str]: return set(re.findall(r"\w+", text.lower()))

def retrieve(query: str, k: int = 1) -> list[tuple[str, str]]:
q = tokens(query)
scored = []

```
for doc_id, text in DOCUMENTS.items():
    score = len(q & tokens(text))
    if score > 0:
        scored.append((score, doc_id, text))

scored.sort(reverse=True)
return [
    (doc_id, text)
    for _, doc_id, text in scored[:k]
]
```

def next_query(state: AgentState) -> str | None:
joined = " ".join(e.text for e in state.evidence).lower()

```
if not state.evidence:
    return "Project Aurora được phát triển bởi tổ chức nào?"

if "lab delta" in joined and "sáng lập" not in joined:
    return "Ai sáng lập Lab Delta?"

return None
```

def add_evidence(state: AgentState, query: str) -> None:
existing = {e.doc_id for e in state.evidence}

```
for doc_id, text in retrieve(query):
    if doc_id not in existing:
        state.evidence.append(Evidence(doc_id, text, query))
        existing.add(doc_id)
```

def enough_evidence(state: AgentState) -> bool:
text = " ".join(e.text for e in state.evidence).lower()

```
return (
    "project aurora" in text
    and "lab delta" in text
    and "sáng lập" in text
)
```

def synthesize(state: AgentState) -> str:
text = " ".join(e.text for e in state.evidence)
match = re.search( r"Lab Delta được sáng lập bởi (.+?) vào năm",
text,
)

```
return match.group(1) if match else "Không đủ bằng chứng."
```

def run_agent(question: str) -> AgentState:
state = AgentState(question=question)

```
while state.status == "running":
    # Điều kiện dừng cứng
    if state.step >= state.max_steps:
        state.status = "stopped"
        break

    query = next_query(state)

    if query is None:
        state.answer = (
            synthesize(state)
            if enough_evidence(state)
            else None
        )
        state.status = "done" if state.answer else "stopped"
        break

    # Không cho agent lặp lại cùng một query
    if query in state.seen_queries:
        state.status = "stopped"
        break

    state.seen_queries.add(query)
    add_evidence(state, query)
    state.step += 1

    if enough_evidence(state):
        state.answer = synthesize(state)
        state.status = "done"

return state
```

result = run_agent( "Ai sáng lập tổ chức đã phát triển Project Aurora?"
)

print(result.status) print(result.answer) print(result.step)

for item in result.evidence: print(item.doc_id, item.text) 

Kết quả của ví dụ là:

done
Minh Tran
2
d1 Project Aurora được phát triển bởi Lab Delta.
d2 Lab Delta được sáng lập bởi Minh Tran vào năm 2019.

Agent cần hai retrieval hop. Bước đầu tiên phát hiện thực thể trung gian Lab Delta; state giữ bằng chứng đó, planner dùng nó để tạo query thứ hai, rồi hệ thống mới có đủ dữ kiện để trả lời. Đây chính là khác biệt quan trọng giữa vòng lặp có trạng thái và việc gửi cùng câu hỏi gốc vào retriever nhiều lần.

Từ ví dụ toy đến hệ thống production

Trong hệ thống thực, mỗi hàm trong ví dụ nên trở thành một node hoặc component có hợp đồng đầu vào/đầu ra rõ ràng. Một thiết kế dễ vận hành thường tốt hơn một “agent toàn năng” nơi cùng một LLM vừa lập kế hoạch, retrieval, tự đánh giá, nhớ lịch sử và quyết định termination trong một prompt duy nhất.

Tách planner khỏi evidence grader

Planner trả lời câu hỏi: cần làm gì tiếp theo?. Evidence grader trả lời câu hỏi khác: kết quả vừa nhận có đủ liên quan và hỗ trợ claim không?. Tách hai vai trò giúp log và đánh giá lỗi dễ hơn. Nếu cùng một model mắc sai ở planner và tự xác nhận sai bằng chứng của chính nó, vòng lặp có thể củng cố lỗi qua nhiều iteration.

Checkpoint state sau mỗi tool call

Một truy vấn nhiều bước có thể gọi vector database, SQL, API hoặc web search. Nếu request thứ tư timeout, không nên bắt đầu lại từ bước đầu. Persist state sau các hành động tốn chi phí giúp workflow có thể resume và tạo audit trail.

Dedupe ở cả query và evidence

Hai query khác câu chữ vẫn có thể mang cùng intent. Trong production nên chuẩn hóa query, theo dõi document ID đã thấy và cân nhắc semantic similarity giữa các query gần nhau. Nếu agent liên tục nhận lại cùng tài liệu nhưng không giải quyết thêm subgoal, đó là dấu hiệu rõ của no progress.

Không phải query nào cũng cần agent loop

Vòng lặp nhiều bước tạo thêm latency và số lần gọi model. Adaptive-RAG nghiên cứu việc chọn giữa không retrieval, single-step retrieval và iterative retrieval dựa trên độ phức tạp của câu hỏi [6]. Trong hệ thống thực tế, một complexity router trước agent loop thường hợp lý hơn việc ép mọi request chạy qua pipeline nhiều bước.

Trường hợp	Chiến lược phù hợp	Lý do
Kiến thức đã có trong prompt	Không retrieval	Retrieval chỉ tăng chi phí và nguy cơ đưa thêm nhiễu.
Câu hỏi factoid một bước	RAG một lượt	Một query thường đủ tìm bằng chứng cần thiết.
Multi-hop QA	Stateful Agentic RAG	Query tiếp theo phụ thuộc vào thực thể hoặc fact vừa tìm được.
Nghiên cứu mở, chưa rõ số bước	Agent loop + budget + no-progress detection	Cần thích nghi nhưng phải kiểm soát termination.

Những lỗi thiết kế dễ khiến vòng lặp Agentic RAG thất bại

Lỗi thứ nhất là biến context window thành state. Nếu mỗi vòng chỉ nối toàn bộ conversation, tài liệu và output cũ vào prompt mới, hệ thống có lịch sử nhưng chưa chắc có state. State đúng nghĩa phải cho phép code trả lời được các câu hỏi cụ thể như “subgoal nào chưa xong?”, “query nào đã thử?” và “claim này đến từ document nào?”.

Lỗi thứ hai là để retriever quyết định sự thật. Retriever chỉ xếp hạng mức liên quan; một passage đứng đầu không đồng nghĩa nội dung của nó đúng hoặc hỗ trợ claim. Retrieval score và evidence support nên được xem là hai biến khác nhau.

Lỗi thứ ba là rewrite query không có neo. Query mới phải liên hệ được với original question và một subgoal cụ thể. Nếu agent dùng chính câu trả lời chưa kiểm chứng của mình để sinh query tiếp theo, một lỗi nhỏ ở hop đầu có thể kéo toàn bộ trajectory sang nhánh sai.

Lỗi thứ tư là chỉ giới hạn max_steps. Max steps ngăn vòng lặp vô hạn nhưng không ngăn agent phí năm bước để chạy lại cùng một intent. Cần theo dõi tiến triển thực: số evidence mới, số subgoal được giải quyết và mức độ thay đổi của query.

Lỗi thứ năm là luôn kích hoạt agent. Các chiến lược adaptive retrieval tồn tại chính vì câu hỏi có độ phức tạp khác nhau [6]. Một router tốt có thể giúp phần lớn câu hỏi đơn giản đi qua đường xử lý ngắn, chỉ chuyển những truy vấn thực sự cần decomposition sang vòng lặp nhiều bước.

Nguyên tắc thực dụng: LLM nên quyết định những gì cần khả năng ngôn ngữ và suy luận mềm; code xác định nên kiểm soát budget, state schema, deduplication, provenance, retry, timeout và termination. Đưa mọi quyết định vào LLM làm agent linh hoạt hơn trên giấy nhưng thường khiến hệ thống khó dự đoán và khó debug hơn.

Kết luận

Giá trị cốt lõi của vòng lặp có trạng thái trong Agentic RAG không nằm ở việc gọi retriever nhiều lần, mà ở khả năng dùng kết quả của bước trước để xác định chính xác bước tiếp theo. State cần tường minh, bằng chứng cần được kiểm tra trước khi chấp nhận, còn termination phải được kiểm soát bằng cả điều kiện ngữ nghĩa lẫn giới hạn cứng.

Với câu hỏi đơn giản, RAG một lượt vẫn là lựa chọn hợp lý. Stateful Agentic RAG phát huy giá trị khi bài toán thực sự có quan hệ nhiều hop, retrieval phụ thuộc vào thông tin trung gian hoặc số bước giải quyết không thể xác định hoàn toàn từ truy vấn ban đầu.

Tài liệu tham khảo

1. [1] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” Advances in Neural Information Processing Systems, vol. 33, 2020. NeurIPS Proceedings.
2. [2] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing Reasoning and Acting in Language Models,” in International Conference on Learning Representations, 2023. OpenReview.
3. [3] H. Trivedi, N. Balasubramanian, T. Khot, and A. Sabharwal, “Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions,” in Proc. 61st Annual Meeting of the Association for Computational Linguistics, pp. 10014–10037, 2023, doi: 10.18653/v1/2023.acl-long.557. ACL Anthology.
4. [4] Z. Jiang et al., “Active Retrieval Augmented Generation,” in Proc. 2023 Conference on Empirical Methods in Natural Language Processing, pp. 7969–7992, 2023, doi: 10.18653/v1/2023.emnlp-main.495. ACL Anthology.
5. [5] A. Asai, Z. Wu, Y. Wang, A. Sil, and H. Hajishirzi, “Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection,” in International Conference on Learning Representations, 2024. OpenReview.
6. [6] S. Jeong, J. Baek, S. Cho, S. J. Hwang, and J. C. Park, “Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity,” in Proc. 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, pp. 7036–7050, 2024, doi: 10.18653/v1/2024.naacl-long.389. ACL Anthology.