Đăng Ký Học SEO

RAG Là Gì? Cơ Chế Bên Dưới Google AI Overviews Và Perplexity

RAG (Retrieval-Augmented Generation) là kỹ thuật cho LLM truy xuất tài liệu bên ngoài trước khi tạo câu trả lời, giúp giảm ảo giác AI. RAG chạy ba bước mỗi lần hỏi: Retrieval, Augmentation, Generation. Google AI Overviews truy xuất từ chỉ mục có sẵn, còn Perplexity crawl web theo thời gian thực. Vì vậy trang phải được index và viết answer-first.

RAG (Retrieval-Augmented Generation, Tạo sinh dựa trên truy xuất tăng cường) là kỹ thuật kết hợp hai năng lực: tìm kiếm tài liệu từ nguồn bên ngoài và tạo câu trả lời bằng mô hình ngôn ngữ lớn (LLM). Thay vì chỉ dựa vào dữ liệu đã học trong quá trình huấn luyện, hệ thống RAG chủ động truy xuất tài liệu liên quan trước, rồi mới tổng hợp câu trả lời từ chính các tài liệu đó. Đây là cơ chế kỹ thuật vận hành bên dưới Google AI Overviews, Perplexity và nhiều hệ thống AI search hiện đại.

"Tạo sinh dựa trên truy xuất tăng cường (tiếng Anh: retrieval-augmented generation hoặc RAG) là một kỹ thuật cho phép các mô hình ngôn ngữ lớn (LLM) truy xuất và kết hợp thông tin mới. Với RAG, các LLM không trả lời truy vấn của người dùng chỉ dựa trên dữ liệu huấn luyện mà còn tham chiếu thêm các nguồn tài liệu bên ngoài."

Retrieval-Augmented Generation nghĩa đen là gì?

Nếu tách từng thành phần: Retrieval là truy xuất thông tin từ nguồn bên ngoài; Augmented là tăng cường, bổ sung ngữ cảnh cho mô hình; Generation là quá trình tạo ra văn bản trả lời. Ba bước này chạy tuần tự mỗi lần người dùng đặt câu hỏi, không phải một lần trong quá trình huấn luyện mô hình.

RAG ra đời từ khi nào?

RAG được giới thiệu năm 2020 bởi nhóm nghiên cứu tại Meta AI Research (trước là Facebook AI Research) qua bài báo "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" công bố tại hội nghị NeurIPS. Từ đó, RAG trở thành kiến trúc chuẩn cho các hệ thống AI cần trả lời câu hỏi dựa trên nguồn dữ liệu cập nhật, không bị giới hạn bởi ngày cắt dữ liệu huấn luyện (knowledge cutoff).

Trước RAG, LLM chỉ biết những gì được học trong lúc huấn luyện. Khi người dùng hỏi thông tin mới hơn ngày cắt dữ liệu, mô hình thường tự bịa đặt, hiện tượng gọi là ảo giác AI (AI hallucination). RAG giải quyết vấn đề này bằng cách cung cấp tài liệu thực tế ngay lúc trả lời, giúp mô hình bám vào sự kiện có thật thay vì suy đoán.

Ba bước vận hành cốt lõi của RAG

Một hệ thống RAG vận hành qua 3 bước bắt buộc mỗi khi nhận truy vấn: tìm kiếm tài liệu liên quan (Retrieval), tích hợp tài liệu vào ngữ cảnh (Augmentation), và tạo câu trả lời (Generation). Hiểu đúng 3 bước này là nền tảng để SEOer biết nội dung cần được cấu trúc như thế nào mới lọt vào pipeline RAG.

Bước 1, Retrieval: Tìm kiếm tài liệu từ kho nguồn

Khi nhận câu hỏi của người dùng, hệ thống RAG không trả lời ngay. Thay vào đó, nó chuyển câu hỏi thành một vector số học (embedding), rồi tìm kiếm trong kho dữ liệu đã lập chỉ mục để tìm ra các đoạn tài liệu (chunks) có nghĩa gần nhất. Đây là bước quyết định nguồn nào được đưa vào cửa sổ ngữ cảnh (context window) của mô hình.

Bước 2, Augmentation: Tăng cường ngữ cảnh cho mô hình

Các đoạn tài liệu được chọn ở bước 1 sẽ được ghép vào prompt gốc của người dùng trước khi gửi đến mô hình ngôn ngữ. Mô hình lúc này nhìn thấy cả câu hỏi lẫn tài liệu tham chiếu, từ đó "biết" phải lấy thông tin từ đâu khi trả lời. Google gọi bước này là "grounding": neo câu trả lời vào nguồn thực.

Bước 3, Generation: Tạo câu trả lời có dẫn nguồn

Mô hình ngôn ngữ tổng hợp câu trả lời dựa trên cả câu hỏi và tài liệu đã được cung cấp. Trong Google AI Overviews và Perplexity, mô hình đồng thời trích xuất các URL nguồn để hiển thị bên cạnh câu trả lời, giúp người dùng kiểm chứng và đọc sâu hơn.

  1. Retrieval: Câu hỏi → embedding → tìm kiếm vector → chọn top-K đoạn tài liệu phù hợp nhất.
  2. Augmentation: Ghép tài liệu vào prompt → gửi cụm [câu hỏi + tài liệu] đến LLM.
  3. Generation: LLM tạo câu trả lời dựa trên tài liệu được cung cấp → trả về kèm trích dẫn nguồn.

Google AI Overviews dùng RAG như thế nào?

Google AI Overviews dùng RAG theo cơ chế "grounding", neo câu trả lời AI vào nội dung từ chỉ mục tìm kiếm hiện có của Google, không phải từ một cơ sở dữ liệu riêng biệt. Điều đó có nghĩa là nếu trang của bạn không được index, nó không bao giờ lọt vào pipeline RAG của Google.

RAG của Google hoạt động trên chỉ mục tìm kiếm hiện có

Theo tài liệu chính thức từ Google Search Central, Google AI Overviews và AI Mode đều "bắt nguồn từ hệ thống xếp hạng và chất lượng tìm kiếm cốt lõi". Nghĩa là RAG của Google không crawl web theo thời gian thực mà truy xuất từ chỉ mục đã tồn tại. Trang bị noindex, bị lỗi kỹ thuật hoặc bị penalize sẽ không được đưa vào pipeline.

Query fan-out, Google mở rộng truy vấn trước khi truy xuất

Google áp dụng một kỹ thuật gọi là query fan-out: từ một câu hỏi của người dùng, hệ thống sinh ra nhiều truy vấn con liên quan, mỗi truy vấn con kéo một tập tài liệu khác nhau từ chỉ mục. Các tập tài liệu này được hợp nhất và lọc trước khi đưa vào bước augmentation. Đây là lý do một trang có thể được trích dẫn cho câu hỏi không hoàn toàn khớp từ khóa với tiêu đề bài.

Điều kiện để nội dung vào pipeline RAG của Google

Phần này nêu điều kiện để nội dung lọt vào pipeline. Điều kiện đầu là trang phải được Googlebot crawl và index thành công. Điều kiện sau là nội dung phải hiện ra trong Rendered HTML, tức phần DOM sau khi JavaScript đã chạy, không được nằm ẩn trong tab hay accordion chưa mở. Ẩn khỏi bot là tự loại mình.

  • Trang phải được Googlebot crawl và index thành công.
  • Nội dung phải hiển thị trong Rendered HTML (DOM sau khi JavaScript chạy), không bị ẩn trong tab hay accordion chưa mở.
  • Câu trả lời phải rõ ràng, trực tiếp và đặt ở vị trí đầu trong mỗi section (answer-first).
  • Trang không vi phạm chính sách chống spam của Google.
  • Nội dung có E-E-A-T rõ ràng: tác giả có chuyên môn, trang có thực thể (entity) được xác thực.

Perplexity dùng RAG như thế nào?

Perplexity áp dụng RAG theo cơ chế real-time: mỗi câu hỏi kích hoạt một phiên crawl mới ngay lúc đó, tìm kiếm kết quả từ web trực tiếp thay vì từ chỉ mục tĩnh. Đây là điểm khác biệt lớn nhất giữa Perplexity và Google AI Overviews từ góc độ SEO.

Real-time RAG khác RAG tĩnh ở điểm nào?

RAG tĩnh (như trong Google AI Overviews) lấy tài liệu từ chỉ mục đã được xây dựng trước. RAG thời gian thực (real-time RAG) của Perplexity kích hoạt PerplexityBot đi crawl web ngay lúc người dùng đặt câu hỏi, mang về kết quả mới nhất rồi mới thực hiện augmentation và generation. Điều này giúp Perplexity trả lời được các câu hỏi về sự kiện mới hơn, nhưng phụ thuộc vào tốc độ và khả năng truy cập trang của bạn.

PerplexityBot và quy trình crawl

PerplexityBot là bot riêng của Perplexity AI. Nó crawl web theo yêu cầu, không theo lịch cố định như Googlebot. Nếu trang của bạn chặn PerplexityBot trong file robots.txt, nội dung sẽ không được đưa vào RAG pipeline của Perplexity. Tốc độ tải trang và khả năng render HTML sạch ảnh hưởng trực tiếp đến chất lượng tài liệu Perplexity nhận được.

So sánh cơ chế RAG giữa Google AI Overviews và Perplexity

Bảng này đặt hai hệ thống cạnh nhau theo từng tiêu chí. Về nguồn dữ liệu truy xuất, Google AI Overviews lấy từ chỉ mục tìm kiếm của Google, tức nguồn tĩnh, còn Perplexity lấy trực tiếp từ web theo thời gian thực. Về bot crawl, một bên là Googlebot, bên kia là PerplexityBot. Khác cơ chế thì khác cách tối ưu.

Tiêu chíGoogle AI OverviewsPerplexity
Nguồn dữ liệu truy xuấtChỉ mục tìm kiếm Google (tĩnh)Web trực tiếp theo thời gian thực
Bot crawlGooglebotPerplexityBot
Tốc độ cập nhật nguồnPhụ thuộc vào lịch crawl của GoogleGần như tức thì theo từng truy vấn
Điều kiện tối ưuIndex, E-E-A-T, answer-first, schemaCrawlable, tốc độ tải nhanh, nội dung rõ
Kỹ thuật mở rộng truy vấnQuery fan-outMulti-source search aggregation
Hiển thị nguồn trích dẫnCó (thẻ nguồn bên cạnh AI Overview)Có (số thứ tự trích dẫn nội tuyến)

RAG khác gì so với LLM không có RAG?

LLM không có RAG chỉ dựa vào kiến thức được nén trong các tham số khi huấn luyện, nên không biết sự kiện mới hơn ngày cắt dữ liệu và dễ bịa đặt thông tin, gọi là ảo giác AI (AI hallucination). RAG khắc phục vấn đề này bằng cách cấp tài liệu thực tế vào ngữ cảnh trước khi mô hình trả lời.

Hạn chế của LLM thuần (Pure LLM)

Một mô hình ngôn ngữ thuần túy học toàn bộ kiến thức từ dữ liệu huấn luyện và nén thông tin đó vào hàng tỷ tham số. Khi được hỏi điều gì đó nằm ngoài dữ liệu huấn luyện, mô hình không nói "tôi không biết" mà thường tự tạo ra câu trả lời có vẻ hợp lý nhưng thực tế sai. Đây là nguồn gốc của hiện tượng ảo giác AI.

Ảo giác AI (AI Hallucination) và cách RAG kiểm soát

Ảo giác AI xảy ra khi mô hình tạo ra thông tin không có cơ sở thực tế, thường vì nó suy diễn từ pattern trong dữ liệu huấn luyện thay vì từ sự kiện cụ thể. RAG giảm ảo giác bằng cách ràng buộc mô hình vào tài liệu cụ thể: thay vì "nghĩ", mô hình được yêu cầu "đọc từ tài liệu này và tóm tắt". Tuy nhiên, RAG không loại bỏ hoàn toàn ảo giác, mô hình vẫn có thể diễn giải sai tài liệu được cung cấp.

Bảng so sánh LLM thuần và LLM có RAG

Bảng này đặt hai kiểu mô hình cạnh nhau. Về nguồn thông tin, LLM thuần chỉ dựa vào tham số học được từ dữ liệu huấn luyện, còn LLM có RAG thì truy xuất thêm tài liệu bên ngoài theo thời gian thực. Về độ cập nhật, bên thuần bị giới hạn ở mốc huấn luyện. Có RAG là có đường ra thế giới thật.

Tiêu chíLLM thuần (không có RAG)LLM có RAG
Nguồn thông tinTham số từ dữ liệu huấn luyệnTài liệu bên ngoài được truy xuất theo thời gian thực
Thông tin cập nhậtBị giới hạn bởi ngày cắt dữ liệuLấy được thông tin mới nhất nếu nguồn được cập nhật
Ảo giác AICao, mô hình tự suy đoán khi không có dữ liệuThấp hơn, mô hình bám vào tài liệu được cung cấp
Khả năng trích dẫn nguồnKhông thể trích dẫn nguồn cụ thểTrích dẫn được URL nguồn đã truy xuất
Chi phí tính toánThấp hơn (chỉ inference)Cao hơn (retrieval + augmentation + inference)
Tính minh bạchThấp, không rõ thông tin từ đâuCao hơn, người dùng thấy nguồn trích dẫn

Kiến trúc kỹ thuật bên trong một hệ thống RAG

Một hệ thống RAG đầy đủ gồm ít nhất ba thành phần kỹ thuật chính: cơ sở dữ liệu vector (vector database) để lưu trữ và tìm kiếm tài liệu, module embedding để chuyển văn bản thành vector số học, và cơ chế chunking để chia tài liệu thành các đoạn nhỏ có thể truy xuất độc lập. SEOer không cần lập trình được các thành phần này, nhưng cần hiểu để biết nội dung của mình bị "nhìn" như thế nào từ phía kỹ thuật.

Vector database là gì trong ngữ cảnh RAG?

Vector database là cơ sở dữ liệu chuyên biệt lưu trữ văn bản dưới dạng vector số học nhiều chiều. Thay vì tìm kiếm theo từ khóa chính xác (exact keyword match), vector database tìm các vector có khoảng cách gần nhau trong không gian nhiều chiều, tức là tìm theo nghĩa, không theo chữ. Đây là lý do tại sao RAG có thể trả lời câu hỏi dù người dùng dùng từ ngữ khác với từ có trong tài liệu gốc.

Embedding, cách văn bản biến thành số

Embedding là quá trình dùng mô hình chuyển một đoạn văn bản thành một vector (mảng số thực). Hai đoạn văn bản có nghĩa gần nhau sẽ tạo ra hai vector gần nhau trong không gian nhiều chiều, dù dùng từ ngữ khác nhau. Ví dụ: "cách tối ưu SEO" và "làm thế nào để website lên top" sẽ có vector gần nhau sau khi embedding. Chất lượng embedding quyết định mức độ chính xác của bước Retrieval.

Chunking, chiến lược chia nhỏ tài liệu

Trước khi đưa vào vector database, tài liệu phải được chia thành các đoạn nhỏ gọi là chunks. Mỗi chunk thường gồm 100 đến 500 từ, đủ nhỏ để vector embedding chính xác, đủ lớn để mang đủ ngữ cảnh. Một bài viết dài sẽ được chia thành nhiều chunks, mỗi chunk được lập chỉ mục độc lập. Điều này giải thích vì sao một đoạn cụ thể trong bài viết của bạn có thể được trích dẫn dù phần còn lại của bài không liên quan đến câu hỏi.

Retrieval, cơ chế chọn nguồn trong RAG

Bước Retrieval quyết định nguồn nào được đưa vào câu trả lời AI. Hệ thống dùng các phương pháp tìm kiếm ngữ nghĩa để chọn ra top-K đoạn tài liệu phù hợp nhất với câu hỏi, rồi gửi các đoạn đó vào bước Augmentation.

Dense retrieval và Sparse retrieval

Có hai phương pháp tìm kiếm chính trong RAG. Sparse retrieval dùng kỹ thuật như BM25, tìm kiếm theo tần suất từ xuất hiện, nhanh nhưng không hiểu ngữ nghĩa sâu. Dense retrieval dùng embedding vector, hiểu ngữ nghĩa tốt hơn nhưng tốn tài nguyên tính toán hơn. Hầu hết hệ thống RAG hiện đại kết hợp cả hai trong một pipeline hybrid, lấy điểm mạnh của từng phương pháp.

Similarity search và cosine distance

Sau khi câu hỏi của người dùng được chuyển thành embedding vector, hệ thống tính cosine similarity: độ tương đồng góc giữa hai vector, giữa vector của câu hỏi và tất cả vector tài liệu trong database. Các đoạn tài liệu có cosine similarity cao nhất được chọn. Đây là lý do nội dung viết rõ ràng, tập trung chủ đề, không lan man sẽ tạo ra embedding chính xác hơn và có xác suất được chọn cao hơn.

Re-ranking, bước lọc lần hai trước khi augmentation

Sau khi Retrieval chọn được top-K tài liệu (thường 10 đến 20 chunks), nhiều hệ thống RAG áp dụng thêm bước re-ranking: dùng một mô hình thứ hai nhỏ hơn để chấm điểm lại mức độ liên quan thực sự của từng chunk. Chỉ top 3 đến 5 chunks có điểm cao nhất sau re-ranking mới được đưa vào cửa sổ ngữ cảnh của LLM. Đây là lý do chất lượng nội dung quan trọng hơn số lượng từ khóa nhồi nhat.

Các loại RAG phổ biến hiện nay

RAG không phải một kiến trúc đồng nhất. Từ khi ra đời năm 2020, RAG đã phát triển qua nhiều thế hệ với mức độ phức tạp và độ chính xác tăng dần. SEOer cần biết điều này vì mỗi loại RAG có yêu cầu về định dạng nội dung khác nhau.

Naive RAG, RAG thế hệ đầu

Naive RAG (RAG cơ bản) theo đúng ba bước tuyến tính: index tài liệu, truy xuất theo embedding, rồi tạo câu trả lời. Đây là kiến trúc đơn giản nhất, phù hợp cho dữ liệu nội bộ ổn định, ít cập nhật. Giới hạn lớn nhất là chất lượng truy xuất thấp nếu câu hỏi phức tạp hoặc cần tổng hợp nhiều nguồn.

Advanced RAG, RAG nâng cao

Advanced RAG bổ sung các bước xử lý trước và sau quá trình truy xuất: query rewriting (viết lại câu hỏi để tìm kiếm tốt hơn), hybrid search (kết hợp dense và sparse retrieval), và re-ranking sau retrieval. Đây là kiến trúc mà Perplexity và nhiều sản phẩm AI search thương mại đang dùng.

Modular RAG, RAG theo module có thể tùy biến

Modular RAG cho phép thay thế từng thành phần riêng biệt, retriever, augmenter, generator, bằng module phù hợp với từng bài toán cụ thể. Một số hệ thống Modular RAG tích hợp thêm khả năng sinh truy vấn (query generation) và kiểm chứng sự thật (fact verification) trước khi trả về câu trả lời cuối. Google AI Mode và các mô hình Gemini mới nhất đang tiến dần đến kiến trúc này.

Tiêu chíNaive RAGAdvanced RAGModular RAG
Độ phức tạpThấpTrung bìnhCao
Chất lượng truy xuấtTrung bìnhCaoRất cao
Xử lý câu hỏi phức tạpYếuTốtRất tốt
Ví dụ ứng dụngChatbot nội bộ, FAQ botPerplexity, Bing CopilotGoogle AI Mode, Gemini Advanced
Yêu cầu với nội dung đầu vàoSạch, rõ cấu trúcAnswer-first, entity rõCấu trúc semantic đầy đủ, schema

Tại sao SEOer cần hiểu cơ chế RAG?

SEOer cần hiểu cơ chế RAG vì nó nói rõ vì sao một trang thứ 5 vẫn được AI trích dẫn còn trang số 1 lại không ai nhắc. RAG chọn nguồn theo chất lượng tài liệu, cấu trúc rõ, entity rõ và câu trả lời trực tiếp, chứ không theo thứ hạng. Xếp hạng cao chỉ đưa trang vào tập ứng viên ở bước Retrieval; bước re-ranking mới cân đo từng chunk. Một trang ở vị trí 6 mà viết answer-first sạch vẫn có thể qua mặt trang số 1 viết dài dòng.

Nghề SEO đánh giá nhau bằng dự án đã chạy chứ không bằng số giờ đã học. Đào Tạo SEO xây chương trình quanh dự án thật.

SEOer cần hiểu RAG vì đây là lý do khiến một trang xếp hạng thứ 5 vẫn được AI (SI - Super Intelligence) trích dẫn trong khi trang xếp hạng số 1 lại không được nhắc tên. RAG chọn nguồn theo chất lượng tài liệu, cấu trúc rõ, entity rõ, câu trả lời trực tiếp, không chọn theo thứ hạng.

"SEO cho AI không phải là 'dùng AI viết bài', mà là làm cho AI có lý do để chọn bạn trong câu trả lời."

RAG quyết định ai được trích dẫn, không phải thứ hạng

Trong SEO truyền thống, xếp hạng cao đồng nghĩa với lượt click cao. Trong AI search, xếp hạng cao chỉ giúp trang lọt vào tập ứng viên ban đầu của bước Retrieval. Sau đó, bước re-ranking chọn theo chất lượng chunk: câu trả lời có rõ không, entity có xác định không, ngữ cảnh có đủ không. Một trang ở vị trí 6 nhưng có cấu trúc answer-first sạch hoàn toàn có thể vượt qua trang số 1 viết theo dạng dài dòng.

Nội dung dễ "chunk" là nội dung dễ vào RAG pipeline

Chunking tốt đòi hỏi mỗi đoạn văn phải mang đủ ý nghĩa khi đứng độc lập. Bài viết có cấu trúc H2/H3 rõ ràng, mỗi section mở đầu bằng câu trả lời trực tiếp (answer-first), sẽ tạo ra các chunk ngữ nghĩa hoàn chỉnh khi bị cắt theo heading. Ngược lại, bài viết dài dòng, phải đọc toàn bộ mới hiểu, sẽ tạo ra các chunk không có ý nghĩa khi tách ra.

Entity rõ ràng giúp RAG nhận diện và tin nguồn của bạn

Trong bước Retrieval và re-ranking, hệ thống RAG ưu tiên các tài liệu có thực thể (entity) được xác định rõ ràng vì entity giúp mô hình giảm suy đoán. Trang không có entity page, không có schema, tên tổ chức viết không nhất quán, tác giả không rõ ràng, sẽ tạo ra tín hiệu mơ hồ trong bước augmentation và có xác suất bị loại cao hơn.

GEO và RAG, mối quan hệ kỹ thuật không thể tách rời

GEO (Generative Engine Optimization) là tập hợp kỹ thuật tối ưu giúp nội dung của bạn đi qua được cả ba bước của RAG pipeline: được truy xuất (Retrieval), được tin cậy đủ để đưa vào ngữ cảnh (Augmentation), và được trích dẫn trong câu trả lời cuối (Generation). Hiểu RAG là hiểu tại sao từng kỹ thuật GEO lại hoạt động.

GEO hoạt động ở tầng đầu vào của RAG

GEO không phải tối ưu cho bước Generation, đó là việc của LLM. GEO tối ưu cho bước Retrieval (để tài liệu được chọn) và bước Augmentation (để tài liệu được tin cậy đưa vào ngữ cảnh). Nếu bạn muốn tìm hiểu sâu hơn về cách triển khai GEO tối ưu để vào nguồn RAG, có thể đọc bài giải thích toàn bộ framework GEO thực chiến.

Answer-first structure phù hợp với cơ chế RAG như thế nào?

Viết answer-first (câu trả lời trực tiếp ngay đầu section) không chỉ là kỹ thuật content, đây là kỹ thuật RAG. Khi chunking theo heading, chunk đầu tiên của mỗi H2/H3 sẽ chứa câu trả lời hoàn chỉnh. Mô hình re-ranking nhận ra chunk này trả lời đúng truy vấn và cho điểm cao. Chunk dài dòng, không có câu trả lời ở đầu, nhận điểm thấp và bị loại dù bài viết tổng thể rất tốt.

Schema và entity giúp RAG "tin" nguồn của bạn

Nói cho đúng: schema không làm mô hình tin bạn hơn, và Google đã nói rõ dữ liệu có cấu trúc không bắt buộc cho tìm kiếm có AI. Thứ schema làm được là bớt chỗ để đoán. Khi trang khai rõ đây là bài viết của ai, thuộc tổ chức nào, nói về thực thể nào, thì hệ thống không phải suy ra những điều đó từ câu chữ, và phần suy ra chính là chỗ dễ sai nhất. Entity đi cùng hướng: một thuật ngữ có trang định nghĩa riêng và được các bài khác trỏ về đúng ngữ cảnh thì khó bị lẫn với thứ trùng tên. Cả hai đều là cách làm rõ dữ kiện, không phải cách tạo uy tín.

Checklist tối ưu nội dung để vào RAG pipeline

Tối ưu cho RAG không cần thêm file llms.txt hay kỹ thuật AI riêng biệt. Google đã xác nhận điều này trong tài liệu hướng dẫn năm 2025. Những gì cần làm đều là thực hành SEO và content tốt, được nâng lên mức độ kỹ thuật cao hơn.

Chuẩn hóa cấu trúc nội dung cho RAG

Phần này đưa các quy tắc chuẩn hóa cấu trúc. Quy tắc đầu là viết câu trả lời trực tiếp trong khoảng 40 đến 60 từ, đặt ngay dưới mỗi H2 hoặc H3. Quy tắc sau là dùng cấu trúc khái niệm là định nghĩa ngắn gọn, rồi mở rộng, rồi ví dụ. Viết theo khuôn này thì máy trích được nguyên đoạn.

  • Viết câu trả lời trực tiếp trong 40 đến 60 từ ngay dưới mỗi H2/H3 (answer-first).
  • Dùng cấu trúc: [Khái niệm] là [định nghĩa ngắn gọn] + [mở rộng] + [ví dụ].
  • Đảm bảo mỗi section có thể đứng độc lập và trả lời được một câu hỏi cụ thể.
  • Tránh bắt đầu section bằng câu dẫn dắt như "Để trả lời câu hỏi này, chúng ta cần xem xét...".
  • Dùng bảng cho thông tin so sánh, danh sách có thứ tự cho quy trình, danh sách không thứ tự cho tập hợp điều kiện.

Chuẩn hóa entity và schema

Phần này nói về chuẩn hóa entity và schema. Việc đầu là khai báo tên tổ chức, tên tác giả và chủ đề cho nhất quán trên toàn site. Việc sau là triển khai Organization schema ở trang chủ, cùng Article hoặc BlogPosting schema ở từng bài viết. Việc kế là dùng FAQPage schema đúng chỗ. Nhất quán thì máy mới ghép đúng.

  1. Khai báo tên tổ chức, tác giả, chủ đề nhất quán trên toàn site.
  2. Triển khai Organization schema tại homepage, Article/BlogPosting schema tại bài viết.
  3. Dùng FAQPage schema cho section FAQ nếu câu hỏi và trả lời hiển thị thực trong DOM.
  4. Validate schema với Rich Results Test của Google trước khi publish.
  5. Đảm bảo rendered HTML (kiểm tra bằng Google Search Console, URL Inspection, Rendered HTML) chứa toàn bộ nội dung quan trọng, không bị ẩn trong tab hay JavaScript động.

Kiểm tra và đo lường sau tối ưu

Sau khi triển khai, dùng công cụ đo lường AI Overviews để theo dõi impression, click, và tỷ lệ được trích dẫn. Kiểm tra trực tiếp trong Google AI Overviews, Perplexity, và Bing Copilot bằng cách gõ chính câu hỏi bạn muốn xếp hạng và xem nguồn nào được trích. Đây là cách nhanh nhất để biết RAG pipeline đang ưu tiên nguồn nào và bạn cần cải thiện điểm nào.

Tầng RAGKỹ thuật cần làmCông cụ kiểm traƯu tiên
Retrieval (được chọn vào tập ứng viên)Index đúng, crawlable, không bị chặn robots.txtGoogle Search Console, CoverageCao nhất
Retrieval (xếp hạng trong tập ứng viên)Answer-first, nội dung rõ chủ đề, heading có từ khóaGoogle Search Console, PerformanceCao
Re-ranking (lọt top sau lần lọc thứ hai)Entity rõ, E-E-A-T, schema hợp lệRich Results Test, schema validatorCao
Augmentation (được đưa vào ngữ cảnh)Rendered HTML sạch, không JS-only contentGSC, URL Inspection, Rendered HTMLTrung bình-cao
Generation (được trích dẫn trong câu trả lời)Chunk có nghĩa độc lập, câu trả lời ngắn gọn đúng intentKiểm tra trực tiếp trên AI Overviews / PerplexityTrung bình

Hạn chế và rủi ro của RAG cần biết

Hạn chế và rủi ro của RAG cần biết gồm 3 điểm. Một là truy xuất sai nguồn: nếu bước Retrieval bốc nhầm chunk, bước Generation sẽ dựng câu trả lời trên thông tin sai. Hai là mâu thuẫn giữa nhiều nguồn, lúc đó mô hình khó biết nguồn nào đúng và hay ghép lộn xộn. Ba là giới hạn số token của cửa sổ ngữ cảnh, tức context window, nên phần quan trọng phải nằm ngay đầu mỗi section. Ai viết rõ, có số liệu, có nguồn trích thì thường thắng.

Truy xuất sai nguồn dẫn đến câu trả lời sai ngữ cảnh

Nếu bước Retrieval chọn nhầm chunk không liên quan, bước Generation sẽ tạo ra câu trả lời dựa trên thông tin sai. Wikipedia tiếng Việt ghi nhận rằng "các hệ thống RAG có thể truy xuất các nguồn thông tin đúng sự thật nhưng lại gây hiểu lầm, dẫn đến sai sót trong việc diễn giải". Đây là lý do tại sao nội dung của bạn cần rõ ràng ngữ cảnh ngay từ đầu mỗi đoạn, không để mô hình phải suy đoán đoạn này thuộc chủ đề gì.

Thông tin mâu thuẫn giữa các nguồn

Khi hệ thống RAG truy xuất nhiều nguồn có thông tin mâu thuẫn nhau, mô hình gặp khó khăn trong việc xác định nguồn nào đúng. Kết quả thường là câu trả lời kết hợp thông tin từ nhiều nguồn theo cách không nhất quán. Trang của bạn có câu trả lời rõ ràng, có số liệu cụ thể, có nguồn trích dẫn tường minh sẽ thường thắng trong tình huống mâu thuẫn này.

Giới hạn về độ dài cửa sổ ngữ cảnh

Mỗi LLM có giới hạn về số lượng token có thể xử lý trong một lần (context window). Sau bước Retrieval và re-ranking, chỉ một số lượng nhất định chunk được đưa vào cửa sổ ngữ cảnh. Nếu bài viết của bạn quá dài, phần quan trọng nhất cần được đặt ở đầu section để đảm bảo nằm trong chunk có xác suất được chọn cao nhất.

RAG trong hệ sinh thái học GEO của Danh Nolan

Trong giáo trình Khóa học SEO Master của tôi, kiến thức về RAG được đặt làm nền tảng cho toàn bộ nội dung học về AI trích xuất, AEO và GEO. Hiểu RAG trước giúp học viên không học "mẹo vặt" mà hiểu bản chất tại sao từng kỹ thuật lại hiệu quả.

Vị trí của RAG trong lộ trình học GEO

Nếu bạn đang bắt đầu hành trình tối ưu cho AI search, thứ tự nên học là: (1) hiểu RAG là gì và vận hành ra sao (bài này), (2) hiểu GEO và AEO đặt ở tầng nào trong pipeline RAG, (3) triển khai kỹ thuật cụ thể theo checklist thực chiến. Nếu bỏ qua bước 1, bước 2 và 3 sẽ chỉ là checklist không có lý do.

Kết nối RAG với Decision Ladder Navigation

Trong hệ thống Decision Ladder Navigation (DLN) của tôi, mỗi trang web phục vụ một tầng trong hành trình ra quyết định của người dùng: từ Observation (nhận biết vấn đề) đến Action (hành động cụ thể). RAG của Google và Perplexity cũng đọc nội dung theo intent, nên trang được tối ưu theo DLN đúng tầng sẽ xuất hiện đúng lúc trong pipeline RAG, không phải ngẫu nhiên.

Học sâu về GEO và tối ưu RAG

Nếu bạn muốn hiểu toàn bộ framework tối ưu cho AI search từ nền tảng đến triển khai thực chiến, khóa học GEO của tôi được thiết kế để đi từ cơ chế kỹ thuật (như RAG) đến checklist áp dụng cụ thể cho từng loại trang. Bạn cũng có thể đọc thêm tại trang học SEO để nắm lộ trình tổng thể.

Câu hỏi thường gặp về RAG

Phần câu hỏi thường gặp về RAG gom các thắc mắc hay nghe nhất. RAG là viết tắt của Retrieval-Augmented Generation, dịch sang tiếng Việt là tạo sinh dựa trên truy xuất tăng cường. Google xác nhận AI Overviews và AI Mode đều chạy cơ chế này, Google gọi nó là grounding. Perplexity thì crawl web ngay lúc người dùng hỏi, nên dữ liệu mới hơn. Trang thứ 5 được trích còn trang số 1 thì không, vì RAG cân chất lượng chunk chứ không cân thứ hạng. Ảo giác vẫn còn, RAG chỉ giảm bớt.

RAG là viết tắt của gì?

RAG là viết tắt của Retrieval-Augmented Generation, dịch sang tiếng Việt là "Tạo sinh dựa trên truy xuất tăng cường". Đây là kỹ thuật kết hợp tìm kiếm tài liệu bên ngoài với mô hình ngôn ngữ lớn để tạo câu trả lời chính xác hơn, có dẫn nguồn.

Google AI Overviews có dùng RAG không?

Có. Google xác nhận Google AI Overviews và AI Mode đều dùng RAG, Google gọi cơ chế này là "grounding". Hệ thống truy xuất nội dung từ chỉ mục tìm kiếm hiện có của Google trước khi tạo câu trả lời tổng hợp.

Perplexity dùng RAG khác gì so với Google?

Perplexity dùng real-time RAG: crawl web trực tiếp ngay khi người dùng đặt câu hỏi thay vì lấy từ chỉ mục tĩnh. Điều này giúp Perplexity có thông tin mới hơn nhưng cũng phụ thuộc vào tốc độ và khả năng truy cập trang của bạn tại thời điểm crawl.

Tại sao trang xếp hạng thứ 5 lại được AI trích dẫn còn trang số 1 thì không?

Vì RAG chọn nguồn theo chất lượng chunk, không theo thứ hạng. Trang có cấu trúc answer-first rõ ràng, entity được xác định, schema hợp lệ sẽ qua được bước re-ranking dù xếp hạng thấp hơn. Trang số 1 viết theo dạng dài dòng, không có câu trả lời rõ ở đầu section, sẽ bị loại ở bước re-ranking.

Chunking là gì và tại sao SEOer cần biết?

Chunking là quá trình hệ thống RAG chia tài liệu thành các đoạn nhỏ để lập chỉ mục riêng biệt. Mỗi chunk được embedding và truy xuất độc lập. SEOer cần biết để viết mỗi section có thể đứng một mình và trả lời được một câu hỏi cụ thể, không phụ thuộc vào việc đọc toàn bộ bài.

Làm cách nào để kiểm tra trang có đang được AI Overviews trích dẫn không?

Gõ câu hỏi mà trang của bạn nhắm đến trực tiếp trên Google (tài khoản không đăng nhập hoặc chế độ ẩn danh) và xem nguồn được liệt kê trong AI Overview. Dùng Google Search Console, Performance, Filters để lọc theo query và theo dõi impression, click từ phần AI Overview.

Ảo giác AI (AI Hallucination) là gì và RAG có loại bỏ được hoàn toàn không?

Ảo giác AI là hiện tượng mô hình ngôn ngữ tạo ra thông tin nghe có vẻ đúng nhưng thực tế sai hoặc bịa đặt. RAG giảm thiểu đáng kể ảo giác bằng cách ràng buộc mô hình vào tài liệu thực, nhưng không loại bỏ hoàn toàn vì mô hình vẫn có thể diễn giải sai tài liệu được cung cấp.

RAG có đòi hỏi nội dung website phải viết khác đi không?

Không cần viết khác hoàn toàn, nhưng cần viết có cấu trúc hơn. Cụ thể: câu trả lời trực tiếp đặt đầu section, tránh dẫn dắt vòng vo, mỗi heading bao quát đúng một chủ đề, dùng bảng và danh sách thay vì đoạn văn dài khi có thể. Đây là thực hành content tốt, không phải kỹ thuật AI đặc biệt.

File llms.txt có giúp nội dung được đưa vào RAG của Google không?

Không. Google đã xác nhận trong tài liệu hướng dẫn chính thức năm 2025 rằng site owner không cần tạo file llms.txt hay markup đặc biệt cho AI search. Google AI search vẫn đọc HTML chuẩn và chỉ mục hiện có.

Nếu website bị Google penalize thì có được RAG trích dẫn không?

Không. Vì Google AI Overviews lấy nguồn từ chỉ mục tìm kiếm, trang bị manual action hoặc vi phạm chính sách chống spam của Google sẽ bị loại khỏi chỉ mục và theo đó cũng không có mặt trong pipeline RAG.

GEO và AEO khác RAG ở điểm nào?

RAG là cơ chế kỹ thuật (công nghệ). GEO (Generative Engine Optimization) và AEO (Answer Engine Optimization) là các tập kỹ thuật tối ưu nội dung để hoạt động tốt hơn trong pipeline RAG. Nói đơn giản: RAG là "máy", GEO/AEO là "cách nạp liệu để máy chọn bạn".

Có cần học RAG nếu tôi chỉ làm SEO cho doanh nghiệp vừa và nhỏ không?

Có, ở mức hiểu khái niệm. Bạn không cần lập trình RAG, nhưng cần hiểu tại sao answer-first, entity, schema và cấu trúc heading lại ảnh hưởng đến khả năng được AI trích dẫn.

Hiểu RAG ở mức khái niệm giúp bạn ra quyết định content đúng hơn, không làm theo checklist mù quáng. Nếu muốn hệ thống hóa, xem chương trình đào tạo SEO của tôi.

Bước tiếp theo

Muốn tự làm được việc này trên website của bạn?

Khóa GEO thực chiến hướng dẫn làm SEO cho AI Overviews và ChatGPT, làm trực tiếp trên website thật.

Cách tối ưu nội dung để được RAG chọn và trích dẫn

Các bước giúp nội dung của bạn đi qua được cả ba tầng của RAG pipeline: được truy xuất, được đưa vào ngữ cảnh và được trích dẫn trong câu trả lời của Google AI Overviews hay Perplexity.

  1. Cho bot crawl và index trangKiểm tra trang được Googlebot crawl và index thành công, không bị noindex, không chặn PerplexityBot trong robots.txt, vì trang nằm ngoài chỉ mục sẽ không lọt vào pipeline RAG.
  2. Hiện nội dung trong Rendered HTMLĐặt nội dung quan trọng trong Rendered HTML, tức DOM sau khi JavaScript chạy, không ẩn trong tab hay accordion chưa mở, rồi kiểm tra bằng URL Inspection của Google Search Console.
  3. Viết câu trả lời ở đầu sectionĐặt câu trả lời trực tiếp 40 đến 60 từ ngay dưới mỗi H2 hoặc H3, theo khuôn khái niệm là định nghĩa ngắn gọn, rồi mở rộng, rồi ví dụ.
  4. Giữ mỗi section đứng độc lậpCho mỗi heading bao quát đúng một chủ đề và trả lời được một câu hỏi cụ thể, để chunk cắt theo heading vẫn mang đủ ý nghĩa khi tách riêng.
  5. Chuẩn hóa entity và schemaKhai báo tên tổ chức, tác giả, chủ đề nhất quán trên toàn site, triển khai Organization schema ở trang chủ, Article hoặc BlogPosting schema ở từng bài, rồi validate bằng Rich Results Test.
  6. Kiểm tra nguồn được AI tríchGõ chính câu hỏi bạn nhắm tới trên Google AI Overviews, Perplexity và Bing Copilot, xem nguồn nào được trích để biết RAG pipeline đang ưu tiên ai và cần cải thiện điểm nào.

Câu hỏi thường gặp về RAG

Giải đáp trực tiếp các câu hỏi thường gặp về RAG dựa trên dữ liệu triển khai thực tế, quy trình kiểm thử kỹ thuật và kinh nghiệm thực chiến trên website thật để tối ưu hiệu quả tìm kiếm.

Vì sao trang đã được index mà vẫn không được AI Overviews trích dẫn?

Index chỉ đưa trang vào tập ứng viên ở bước Retrieval. Sau đó bước re-ranking chấm lại từng chunk theo độ rõ của câu trả lời, entity và ngữ cảnh. Chunk dài dòng, không có câu trả lời ở đầu section, nhận điểm thấp và bị loại dù trang xếp hạng cao.

Nội dung nằm trong tab hay accordion có bị RAG bỏ qua không?

Có thể bị bỏ qua. Nội dung phải hiện ra trong Rendered HTML, tức DOM sau khi JavaScript đã chạy, không nằm ẩn trong tab hay accordion chưa mở. Bạn kiểm tra bằng Google Search Console, URL Inspection, Rendered HTML để chắc phần quan trọng có mặt.

Chặn PerplexityBot trong robots.txt ảnh hưởng gì tới việc được trích dẫn?

Nội dung sẽ không được đưa vào RAG pipeline của Perplexity. PerplexityBot crawl web theo yêu cầu ngay lúc người dùng đặt câu hỏi, nên trang bị chặn không có mặt trong tập tài liệu. Tốc độ tải trang và HTML sạch cũng ảnh hưởng trực tiếp tới chất lượng tài liệu Perplexity nhận được.

Khi nhiều nguồn mâu thuẫn, AI sẽ chọn câu trả lời của trang nào?

Mô hình khó xác định nguồn nào đúng và thường ghép thông tin từ nhiều nguồn theo cách không nhất quán. Trang có câu trả lời rõ ràng, có số liệu cụ thể và nguồn trích dẫn tường minh thường thắng trong tình huống mâu thuẫn đó.

Dense retrieval và sparse retrieval khác biệt ở điểm nào?

Sparse retrieval tìm theo tần suất từ xuất hiện, chạy lẹ nhưng không hiểu ngữ nghĩa sâu. Dense retrieval dùng embedding vector, hiểu ngữ nghĩa tốt hơn nhưng tốn tài nguyên tính toán hơn. Hầu hết hệ thống RAG hiện đại kết hợp cả hai trong một pipeline hybrid để lấy điểm mạnh của từng phương pháp.

Mỗi chunk trong hệ thống RAG thường dài bao nhiêu từ và vì sao?

Mỗi chunk thường gồm 100 đến 500 từ. Độ dài đó đủ nhỏ để vector embedding chính xác, đủ lớn để mang đủ ngữ cảnh. Một tài liệu dài được chia thành nhiều chunk, mỗi chunk lập chỉ mục độc lập, nên một đoạn cụ thể vẫn có thể được trích dẫn riêng.

Re-ranking giữ lại bao nhiêu chunk trước khi đưa vào LLM?

Sau khi Retrieval chọn top-K, thường 10 đến 20 chunks, bước re-ranking dùng một mô hình thứ hai nhỏ hơn để chấm lại mức độ liên quan thực sự của từng chunk. Chỉ top 3 đến 5 chunks có điểm cao nhất mới được đưa vào cửa sổ ngữ cảnh của LLM.

Naive RAG, Advanced RAG và Modular RAG khác biệt ra sao?

Naive RAG chạy ba bước tuyến tính, hợp với dữ liệu nội bộ ổn định. Advanced RAG thêm query rewriting, hybrid search và re-ranking, như Perplexity và Bing Copilot. Modular RAG cho phép thay từng thành phần retriever, augmenter, generator, hướng mà Google AI Mode và Gemini đang tiến dần tới. Độ phức tạp và chất lượng truy xuất tăng dần theo thứ tự đó.

RAG trong AI search là gì và vận hành qua những bước nào?

RAG (Retrieval-Augmented Generation) là kỹ thuật cho LLM truy xuất tài liệu bên ngoài trước khi tạo câu trả lời. Mỗi lần hỏi, RAG chạy ba bước: Retrieval tìm các chunk gần nghĩa nhất, Augmentation ghép chunk vào prompt, Generation tạo câu trả lời kèm URL nguồn. Google AI Overviews và Perplexity đều dùng RAG.

Nên bắt đầu tối ưu nội dung cho RAG từ đâu?

Tối ưu nội dung cho RAG nên bắt đầu từ tầng Retrieval: trang phải được index đúng, crawlable, không bị chặn robots.txt. Bước kế là viết answer-first, đặt câu trả lời trực tiếp 40 đến 60 từ ngay dưới mỗi H2 hoặc H3. Sau cùng mới chuẩn hóa entity, E-E-A-T và schema hợp lệ cho bước re-ranking.

Embedding trong RAG là gì và ảnh hưởng gì tới việc chọn nguồn?

Embedding trong RAG là quá trình dùng mô hình chuyển một đoạn văn bản thành vector, tức mảng số thực. Hai đoạn văn bản gần nghĩa sẽ tạo ra hai vector gần trong không gian nhiều chiều, dù dùng từ ngữ khác. Chất lượng embedding quyết định độ chính xác của bước Retrieval trong RAG.

Query fan-out trong Google AI Overviews là gì?

Query fan-out là kỹ thuật Google AI Overviews dùng để mở rộng truy vấn trước bước Retrieval. Từ một câu hỏi, hệ thống sinh nhiều truy vấn con, mỗi truy vấn con kéo một tập tài liệu riêng từ chỉ mục. Nhờ query fan-out, một trang có thể được trích dẫn dù tiêu đề không khớp từ khóa.

Menu

Thêm vào màn hình chính

  1. 1 Bấm nút Chia sẻ ở thanh công cụ Safari
  2. 2 Kéo xuống, chọn Thêm vào MH chính
  3. 3 Bấm Thêm ở góc trên bên phải

Ba bước này là của Safari. Nếu đang xem trong ứng dụng khác thì bấm mở bằng Safari trước đã.