Vì sao độ phức tạp của RAG chỉ nên được thêm vào khi thực sự cần thiết?

Trong vài năm qua, các kiến trúc RAG (Retrieval-Augmented Generation) đã phát triển vượt xa mô hình "truy xuất-tạo sinh" ban đầu, với sự xuất hiện của hàng loạt kỹ thuật như dense retrieval, lexical retrieval, query rewriting, rank fusion, reranking, và thậm chí là agentic orchestration. Tuy nhiên, sự phức tạp này thường được thêm vào một cách mặc định, trước khi bộ phận truy xuất nền tảng được đánh giá độc lập. Bài viết này lập luận rằng độ phức tạp của RAG chỉ nên được giới thiệu để đáp ứng các lỗi thất bại truy xuất được đo lường, chứ không phải là một lựa chọn kiến trúc mặc định.

Các nghiên cứu gần đây cho thấy các phương pháp truy xuất truyền thống vẫn rất cạnh tranh: lexical retrieval hoạt động tốt trong các lĩnh vực chuyên môn, hybrid retrieval với reranking cung cấp một baseline mạnh mẽ, và thậm chí các hệ thống agentic hoạt động tốt hơn khi được xây dựng trên nền tảng truy xuất mạnh hơn. Điều này không có nghĩa là agentic RAG là không cần thiết, mà là chất lượng truy xuất và khả năng suy luận của agent giải quyết các phần khác nhau của vấn đề: khi bằng chứng có thể được tìm thấy thông qua một bước truy xuất được xác định rõ ràng, mối quan tâm chính thường là chất lượng tìm kiếm; khi truy xuất mang tính lặp, đa bước, hoặc phụ thuộc vào bằng chứng trung gian, agentic retrieval trở nên hữu ích hơn nhiều.

Sự phức tạp gia tăng trong kiến trúc RAG và vấn đề tiềm ẩn

Một mô hình ngày càng phổ biến trong các hệ thống RAG hiện đại là: khi một vấn đề truy xuất xuất hiện, trước khi xác định liệu bản thân việc truy xuất có hoạt động chính xác hay không, kiến trúc sẽ tự động tích hợp thêm query rewriting, routing, nhiều lần truy xuất, reflection, corrective retrieval, một agent quyết định xem có cần thêm bằng chứng hay không, một mô hình reranking, và đôi khi là một mô hình khác để xác minh câu trả lời cuối cùng.

Kiến trúc kết quả trông có vẻ tinh vi, nhưng hệ thống vẫn có thể thất bại vì một lý do đơn giản hơn nhiều: bằng chứng liên quan bị xếp hạng ngoài tập hợp ứng viên và không bao giờ được đưa vào ngữ cảnh của mô hình. Sự khác biệt này rất quan trọng vì truy xuất và suy luận đại diện cho các khả năng hệ thống riêng biệt.

Nếu lỗi thống trị là "bằng chứng cần thiết đã không được truy xuất", thì việc thêm suy luận sau khi truy xuất khó có thể khắc phục được nguyên nhân gốc rễ. Thay vào đó, nó có thể làm tăng độ trễ, lượng token tiêu thụ, tính không xác định (nondeterminism) và số lượng thành phần cần đánh giá.

Đây không phải là một lập luận chống lại agentic RAG. Có những tác vụ tìm kiếm thông tin mà việc lập kế hoạch, phân rã, lựa chọn nguồn không đồng nhất và truy xuất lặp là cần thiết. Lập luận ở đây hẹp hơn: sự phức tạp của kiến trúc nên tương ứng với một lỗi thất bại đã được chứng minh. Agency chỉ có ý nghĩa khi truy xuất thông thường không đủ về mặt cấu trúc. Tuy nhiên, khi bằng chứng đã tồn tại trong một đơn vị có thể truy xuất được nhưng không vào được cửa sổ ngữ cảnh, thì khả năng cao vấn đề chính nằm ở hệ thống tìm kiếm và truy xuất.

Vai trò của truy xuất và tạo sinh trong hệ thống RAG

Truy xuất và tạo sinh là hai thành phần hệ thống riêng biệt

Một hệ thống RAG thực hiện hai hoạt động riêng biệt về mặt khái niệm: Truy xuất (xác định thông tin có khả năng chứa dữ liệu cần thiết để trả lời truy vấn) và Tạo sinh (diễn giải thông tin đã truy xuất và xây dựng phản hồi phù hợp). Các hoạt động này thường được đánh giá cùng nhau vì câu trả lời được tạo ra là đầu ra mà người dùng nhìn thấy. Tuy nhiên, từ góc độ thiết kế hệ thống, các lỗi thất bại của chúng nên được tách riêng.

Hãy xem xét một truy vấn đối với bộ sưu tập các thỏa thuận thương mại: "Điều khoản chấm dứt nào được áp dụng nếu nhà cung cấp liên tục vi phạm SLA?" Giả sử trình truy xuất trả về: một đoạn mô tả nghĩa vụ chung của nhà cung cấp, một điều khoản thanh toán, một vài đoạn chứa cụm từ "service level" và một định nghĩa về vi phạm hợp đồng. Tuy nhiên, điều khoản chấm dứt thực tế lại bị xếp hạng ngoài tập hợp top-k được truy xuất.

Một mô hình ngôn ngữ đủ mạnh vẫn có thể tạo ra một câu trả lời hợp lý dựa trên các mẫu hợp đồng chung. Nó thậm chí có vẻ đúng. Nhưng hệ thống vẫn thất bại ở khâu truy xuất. Không có thay đổi nào đối với prompt tạo sinh có thể khôi phục được bằng chứng chưa bao giờ được đưa vào ngữ cảnh của mô hình.

Điều này dẫn đến một câu hỏi chẩn đoán cơ bản cho hệ thống RAG: Bằng chứng cần thiết để trả lời truy vấn có nằm trong tập hợp ứng viên đã truy xuất hay không? Câu hỏi đó thường phải được trả lời trước khi sửa đổi lớp suy luận hoặc tạo sinh. Độ chính xác của câu trả lời cuối cùng (end-to-end) một mình không thể xác định được thành phần nào gây ra kết quả sai.

Lexical Retrieval vẫn là một baseline cạnh tranh mạnh mẽ

Việc áp dụng rộng rãi truy xuất dựa trên embedding đôi khi tạo ra giả định ngầm rằng tương tự ngữ nghĩa là sự kế thừa hoàn toàn cho tìm kiếm từ vựng. Bằng chứng thực nghiệm không thực sự ủng hộ cách diễn giải đó. BM25 vẫn là một cơ chế truy xuất có tính cạnh tranh cao, đặc biệt trong các lĩnh vực mà các kết quả khớp chính xác từ vựng mang nhiều thông tin quan trọng.

Sự khác biệt giữa tìm kiếm từ vựng và tìm kiếm ngữ nghĩa rất quan trọng. Tìm kiếm từ vựng đặc biệt hiệu quả khi truy vấn chứa các định danh hoặc thuật ngữ mà việc khớp chính xác là quan trọng, chẳng hạn như mã lỗi, định danh hợp đồng, trích dẫn pháp lý, số sản phẩm, tên hàm, mã chứng khoán, từ viết tắt, thuật ngữ y tế, trường cơ sở dữ liệu, hoặc tên và ngày tháng chính xác.

Ví dụ, một mô hình embedding có thể suy luận chính xác rằng "TS-999" đề cập đến một lỗi kỹ thuật, nhưng vẫn xếp hạng một đoạn văn tương tự về mặt ngữ nghĩa lên trên tài liệu duy nhất chứa định danh chính xác "TS-999". BM25 có xu hướng ngược lại: bằng chứng từ vựng chính xác được ưu tiên mạnh mẽ.

Điều này càng quan trọng hơn trong các kho tài liệu chuyên môn, nơi thuật ngữ và định danh thường có giá trị hơn sự tương đồng ngữ nghĩa rộng. Một benchmark vào năm 2026 bao gồm 23.088 câu hỏi tài chính và 7.318 tài liệu hỗn hợp văn bản-bảng đã so sánh mười chiến lược truy xuất, bao gồm sparse retrieval, dense retrieval, hybrid fusion, reranking, query expansion, contextual retrieval và adaptive retrieval. Trong bối cảnh đó, BM25 đã vượt qua phương pháp dense retrieval hiện đại nhất được đánh giá.

Kết luận phù hợp không phải là truy xuất từ vựng nói chung vượt trội hơn embedding. Mà là truy xuất từ vựng và ngữ nghĩa giải quyết các lỗi truy xuất khác nhau.

Hybrid Retrieval và kiến trúc xếp hạng hai giai đoạn

Điểm mạnh của truy xuất từ vựng không loại bỏ nhu cầu về tìm kiếm ngữ nghĩa. Nó làm nổi bật một hạn chế khác: các phương pháp từ vựng hoạt động tốt nhất khi truy vấn và nguồn chia sẻ đủ từ vựng để khớp một cách đáng tin cậy. Dense retrieval trở nên có giá trị khi sự chồng chéo từ vựng yếu.

Ví dụ, người dùng có thể hỏi: "Trong trường hợp nào nhân viên có thể tự nguyện từ chức?" trong khi chính sách nội bộ chỉ đề cập đến "việc chấm dứt do nhân viên khởi xướng". Truy xuất từ vựng có thể gặp khó khăn vì cách diễn đạt khác nhau. Dense embedding có thể nắm bắt mối quan hệ ngữ nghĩa này và thu hồi tài liệu liên quan.

Đây là lúc hybrid retrieval trở nên hữu ích. Thay vì chọn giữa tìm kiếm từ vựng và ngữ nghĩa, hệ thống có thể sử dụng cả hai để tạo ứng viên và sau đó kết hợp thứ hạng của chúng. Một cách tiếp cận phổ biến để kết hợp xếp hạng là Reciprocal Rank Fusion (RRF), kết hợp kết quả dựa trên thứ hạng tương đối thay vì so sánh trực tiếp điểm số vốn không tương xứng.

Tập hợp ứng viên thu được sau đó có thể được đánh giá bởi một cross-encoder hoặc trình rerank khác. Sự khác biệt giữa việc tạo ứng viên và reranking rất quan trọng. Giai đoạn truy xuất đầu tiên chủ yếu chịu trách nhiệm về recall (độ thu hồi), thu hồi một tập hợp ứng viên đủ rộng để tài liệu liên quan khó bị loại bỏ. Trình rerank hoạt động trên một tập hợp nhỏ hơn đáng kể và do đó có thể dành nhiều tính toán hơn để ước tính mức độ liên quan.

Kiến trúc hybrid retrieval hai giai đoạn gồm tạo ứng viên từ vựng và ngữ nghĩa, kết hợp xếp hạng, và reranking

Bằng chứng gần đây ủng hộ cách tiếp cận này. Benchmark tài chính năm 2026 được đề cập ở trên cho thấy kiến trúc tốt nhất không phải là chỉ dùng BM25. Một kiến trúc hai giai đoạn kết hợp hybrid retrieval và neural reranking đạt Recall@5 là 0,816 và MRR@3 là 0,605, vượt trội hơn hẳn các phương pháp một giai đoạn được đánh giá.

Anthropic cũng báo cáo một mô hình tương tự trong các thí nghiệm Contextual Retrieval của họ. Kết hợp contextual embeddings với contextual BM25 giảm 49% các lỗi truy xuất top-20 so với baseline, trong khi việc thêm reranking tăng mức giảm lên 67%. Những kết quả này ủng hộ một kết luận tương đối thông thường: các cơ chế truy xuất thường bổ sung cho nhau chứ không loại trừ lẫn nhau. Thành phần mới nhất không nhất thiết là sự thay thế cho thành phần cũ hơn. Trong nhiều trường hợp, kiến trúc mạnh nhất đến từ việc kết hợp các thế mạnh tương ứng của chúng.

Biểu diễn tài liệu là một ràng buộc đối với truy xuất

Chúng ta đã nói về các phương pháp truy xuất. Tuy nhiên, chất lượng truy xuất được xác định một phần trước khi một truy vấn truy xuất được đưa ra. Việc phân tích cú pháp, phân đoạn tài liệu, lan truyền siêu dữ liệu, xử lý bảng và xây dựng chunk (khối văn bản) xác định các đơn vị mà truy xuất hoạt động trên đó.

Hãy xem xét một tài liệu nguồn có cấu trúc như sau:

Mục 7 — Chấm dứt Khách hàng có thể chấm dứt thỏa thuận nếu tính khả dụng của dịch vụ giảm xuống dưới 99,5% trong ba tháng liên tiếp. Phải có thông báo trong vòng 30 ngày...

Một bộ chia tách token cố định có thể tạo ra:

Chunk 41: Mục 7 — Chấm dứt / Khách hàng có thể chấm dứt thỏa thuận nếu tính khả dụng của dịch vụ

và:

Chunk 42: giảm xuống dưới 99,5% trong ba tháng liên tiếp. / Phải có thông báo trong vòng 30 ngày...

Chunk 42 vẫn chứa điều kiện thực tế quan trọng nhưng nó đã mất thông tin cần thiết để xác định điều kiện đó đề cập đến cái gì. Một khi cấu trúc đó bị loại bỏ trong quá trình chunking, mô hình embedding không thể tái tạo lại nó một cách đáng tin cậy.

Các lỗi tương tự xảy ra khi: các tiêu đề bị tách khỏi phần nội dung, tiêu đề bảng bị xóa khỏi giá trị bảng, tiêu đề tài liệu biến mất khỏi chunk, mối quan hệ cha-con bị loại bỏ, dấu thời gian hoặc kỳ báo cáo bị xóa, siêu dữ liệu kiểm soát truy cập không được truyền tải, hoặc bố cục PDF bị làm phẳng không chính xác.

Điều này làm cho việc chunking không chỉ là một vấn đề quản lý token. Nó còn là một vấn đề biểu diễn thông tin. Các thí nghiệm Contextual Retrieval của Anthropic giải quyết trực tiếp vấn đề này bằng cách thêm ngữ cảnh ngắn có nguồn gốc từ tài liệu vào mỗi chunk trước khi lập chỉ mục. Trong các thí nghiệm được báo cáo, contextual embeddings giảm lỗi truy xuất top-20 từ 5,7% xuống 3,7%. Kết hợp contextual embeddings và contextual BM25 giảm xuống còn 2,9%, và thêm reranking giảm xuống còn 1,9%.

Hàm ý rộng hơn quan trọng hơn kỹ thuật cụ thể: chất lượng truy xuất bắt đầu từ khâu tiếp nhận dữ liệu, không phải từ thời điểm truy vấn. Một kiến trúc phức tạp ở thời điểm truy vấn không thể bù đắp hoàn toàn cho thông tin đã bị suy giảm về mặt cấu trúc trong quá trình lập chỉ mục.

Vai trò phù hợp của Agentic Retrieval

Có những nhu cầu thông tin mà truy xuất tĩnh thực sự không đủ, và đây là lúc agentic retrieval trở nên hữu ích. Hãy xem xét một truy vấn phân tích tài chính: "Công ty nào có biên lợi nhuận hoạt động cao hơn trong năm 2025, Công ty A hay Công ty B, và mỗi công ty xác định nguyên nhân chính của sự thay đổi so với năm trước là gì?"

Không một đoạn văn riêng lẻ nào nhất thiết chứa câu trả lời hoàn chỉnh. Hệ thống có thể cần:xác định kỳ báo cáo phù hợp cho Công ty A, truy xuất biên lợi nhuận hoạt động của Công ty A, truy xuất bình luận của ban quản lý giải thích sự thay đổi, lặp lại quy trình cho Công ty B, đối chiếu sự khác biệt về thuật ngữ hoặc kỳ báo cáo, và so sánh bằng chứng thu được.

Hạn chế ở đây không chỉ đơn giản là chất lượng truy xuất kém. Bản thân nhu cầu thông tin đòi hỏi nhiều bước truy xuất phụ thuộc lẫn nhau. Một lớp suy luận có thể chuyển đổi yêu cầu ban đầu thành nhiều hoạt động truy xuất: Q1 (biên lợi nhuận Công ty A 2025), Q2 (giải thích thay đổi biên lợi nhuận của A), Q3 (biên lợi nhuận Công ty B 2025), Q4 (giải thích thay đổi biên lợi nhuận của B). Bằng chứng thu được sau đó có thể được hợp nhất và xếp hạng lại trước khi tạo sinh.

Phân rã câu hỏi có sự hỗ trợ thực nghiệm cho loại vấn đề này. Một nghiên cứu năm 2025 đánh giá một pipeline phân rã và reranking dựa trên LLM trên MultiHop-RAG và HotpotQA và báo cáo cải thiện 36,7% về MRR@10 và 11,6% về F1 câu trả lời so với các baseline RAG tiêu chuẩn. Đây là một cách sử dụng hợp lý của suy luận bổ sung vì lỗi bắt nguồn từ cấu trúc của nhu cầu thông tin.

Các trường hợp hợp lý khác cho agentic retrieval bao gồm:

• Lựa chọn nguồn không đồng nhất: Hệ thống có thể cần xác định xem thông tin được yêu cầu thuộc về cơ sở dữ liệu quan hệ, chỉ mục tài liệu, đồ thị tri thức, API nội bộ, kho mã nguồn hay nguồn tìm kiếm bên ngoài. Trong trường hợp này, hệ thống phải quyết định truy xuất từ đâu trước khi quyết định truy xuất cái gì.
• Truy xuất phụ thuộc bằng chứng: Truy vấn tiếp theo không thể được xây dựng cho đến khi một kết quả trung gian được quan sát thấy. Một pipeline cố định kém phù hợp hơn với loại tìm kiếm phân nhánh này vì đường dẫn truy xuất xuất hiện trong quá trình thực thi.
• Giải quyết sự mơ hồ: Tìm kiếm ban đầu có thể đưa ra nhiều cách diễn giải hợp lý về một truy vấn. Truy xuất bổ sung sau đó có thể cần thiết để giải quyết sự mơ hồ, thu hẹp không gian tìm kiếm hoặc xác định xem có cần làm rõ hay không.
• Tổng hợp bằng chứng đa bước: Một số câu hỏi chỉ có thể được trả lời bằng cách kết hợp các dữ kiện phân tán trên nhiều tài liệu hoặc hệ thống, trong đó một dữ kiện trung gian là cần thiết để xác định vị trí của dữ kiện tiếp theo.

Trong tất cả các trường hợp này, agency thêm vào một thứ mà một pipeline truy xuất cố định có thể không thể hiện rõ ràng: kiểm soát thích ứng đối với chính quá trình truy xuất.

Chất lượng truy xuất như một ràng buộc đối với suy luận Agentic

Một trong những kết quả thú vị gần đây cho thấy truy xuất mạnh hơn có thể làm cho các hệ thống agentic tốt hơn đáng kể. Một nghiên cứu về khả năng mở rộng (scaling study) vào năm 2026 đã so sánh truy xuất từ vựng, dense, đồ thị và agentic trên 28 kích thước kho tài liệu lồng nhau từ khoảng 1.000 đến 512.000 tài liệu.

BM25 chiếm phần chi phí thấp của đường cong Pareto ở mọi quy mô đo được và dẫn đầu về độ chính xác từ các kích thước kho tài liệu trung bình trở đi. Agent truy xuất hệ thống tệp thô (raw file-system agent) có tính cạnh tranh ở quy mô nhỏ nhưng suy giảm đáng kể khi kích thước kho tài liệu tăng lên, đồng thời tiêu thụ nhiều token ở thời điểm truy vấn hơn đáng kể.

Kết quả giàu thông tin nhất, tuy nhiên, xuất hiện khi cơ chế truy xuất bên dưới agent được thay đổi. Ở quy mô đầy đủ, một lớp truy xuất mạnh hơn đã cải thiện đáng kể hiệu suất của agent. Lớp truy xuất mạnh hơn không làm cho agent trở nên thừa. Nó làm cho agent tốt hơn đáng kể.

Kết quả này giúp tách biệt hai khả năng thường được thảo luận như thể chúng có thể hoán đổi cho nhau. Truy xuất xác định những bằng chứng nào có sẵn cho hệ thống; suy luận xác định cách sử dụng bằng chứng đó và điều gì nên xảy ra tiếp theo. Một nền tảng truy xuất yếu hạn chế bằng chứng có sẵn cho agent, trong khi nền tảng mạnh hơn cung cấp cho cùng một lớp suy luận một cơ sở tốt hơn cho các quyết định tiếp theo.

Mối quan hệ này được biểu diễn tốt hơn là "Chất lượng truy xuất + Suy luận thích ứng → Cải thiện tìm kiếm thông tin" thay vì "Suy luận agentic → Thay thế cho kỹ thuật truy xuất". Nghiên cứu cũng minh họa lý do tại sao các cuộc tranh luận được đóng khung như "BM25 so với agent" hoặc "RAG cổ điển so với RAG agentic" thường không hữu ích về mặt khái niệm vì chúng hoạt động ở các cấp độ khác nhau của kiến trúc.

Chi phí tính toán và vận hành của truy xuất thích ứng

Chúng ta đã lập luận rằng độ phức tạp truy xuất bổ sung có thể được biện minh khi nó giải quyết một hạn chế cụ thể. Tuy nhiên, sự phức tạp kiến trúc đó có chi phí vượt xa chi tiêu suy luận.

Một pipeline tương đối hạn chế có thể thực thi: truy xuất → xếp hạng lại → tạo sinh. Một kiến trúc thích ứng có thể thực thi: phân loại ý định → xây dựng kế hoạch tìm kiếm → tạo truy vấn con → truy xuất → kiểm tra bằng chứng → viết lại truy vấn → truy xuất lại → đánh giá mức độ đủ của bằng chứng → có thể truy xuất lại → tạo sinh → xác minh.

Kiến trúc sau giới thiệu các chi phí token và độ trễ rõ ràng. Quan trọng hơn, nó giới thiệu một bề mặt lỗi (failure surface) lớn hơn. Một phản hồi không chính xác có thể bắt nguồn từ: phân loại ý định, phân rã truy vấn, lựa chọn công cụ, viết lại truy vấn, truy xuất từ vựng, truy xuất dense, kết hợp, xếp hạng lại, đánh giá mức độ đủ của bằng chứng, tiêu chí dừng, tạo sinh hoặc xác minh.

Mỗi nhánh thích ứng cũng giới thiệu thêm tính không xác định. Do đó, vấn đề vận hành thay đổi từ "Mô hình có trả lời đúng không?" thành "Quỹ đạo nào tạo ra câu trả lời, và thành phần nào chịu trách nhiệm cho sự thất bại?"

Điều này có ý nghĩa trực tiếp đối với khả năng quan sát. Các hệ thống truy xuất agentic trong sản xuất ngày càng yêu cầu các trace (dấu vết) chứa: truy vấn người dùng, phân loại, truy vấn con được tạo, ứng viên truy xuất, điểm số truy xuất, điểm số reranker, lời gọi công cụ, bằng chứng trung gian, quyết định của agent và phản hồi cuối cùng. Nếu không có thông tin này, sự cải thiện về độ chính xác tổng thể có thể che giấu sự suy giảm ở nơi khác trong hệ thống. Do đó, một kiến trúc phức tạp hơn được biện minh không chỉ khi nó cải thiện điểm đánh giá, mà khi sự cải thiện đủ lớn để biện minh cho độ trễ, chi phí suy luận, gánh nặng vận hành và các lỗi thất bại bổ sung của nó.

Đánh giá độc lập truy xuất và tạo sinh trong hệ thống RAG

Đánh giá độc lập khâu truy xuất và khâu tạo sinh

Độ chính xác của câu trả lời cuối cùng (end-to-end) một mình là không đủ để chẩn đoán hệ thống RAG. Bốn kết quả rộng là có thể: truy xuất tốt/tạo sinh tốt, truy xuất tốt/tạo sinh kém, truy xuất kém/tạo sinh tốt (mô hình trả lời đúng dựa trên kiến thức tham số), và truy xuất kém/tạo sinh kém.

Trường hợp thứ ba đặc biệt nguy hiểm. Một mô hình có thể trả lời đúng một câu hỏi bằng cách sử dụng kiến thức tham số ngay cả khi hệ thống RAG không truy xuất được bằng chứng hỗ trợ. Đánh giá chỉ dựa trên câu trả lời có thể ghi nhận một thành công. Tuy nhiên, một hệ thống doanh nghiệp có căn cứ nên ghi nhận một thất bại.

Do đó, truy xuất nên được đánh giá độc lập bằng các chỉ số truy xuất thông tin thông thường:

• Recall@k: Đo lường bao nhiêu bằng chứng liên quan xuất hiện trong k kết quả đầu tiên được truy xuất. Đối với nhiều ứng dụng RAG, recall là một chỉ số quan trọng ở giai đoạn đầu vì bằng chứng bị loại bỏ trước khi tạo sinh không thể được thu hồi sau đó.
• Precision@k: Đo lường tỷ lệ các mục được truy xuất có liên quan. Recall cao đi kèm precision rất kém tạo ra một kiểu lỗi khác: bằng chứng cần thiết có mặt, nhưng nó bị bao quanh bởi đủ ngữ cảnh không liên quan để làm giảm hiệu suất của mô hình.
• **Mean