RAG và Context Engineering (Kỹ thuật ngữ cảnh)

Mô hình ngôn ngữ lớn (LLM) thường tạo ra những văn bản nghe có vẻ tự tin nhưng thực tế lại sai. RAG (Retrieval-Augmented Generation) khắc phục điều này bằng cách cung cấp cho LLM dữ liệu thực tế của bạn trước khi nó phản hồi.

🔄 Tóm tắt nhanh: Trong Bài học 3, bạn đã học về đầu ra có cấu trúc - nhận được JSON đáng tin cậy từ LLM. Nhưng nội dung của JSON đó chỉ tốt khi kiến ​​thức của mô hình tốt. RAG giúp mô hình dựa trên dữ liệu của bạn để nó trả lời bằng sự thật, chứ không phải dữ liệu huấn luyện.

Cách thức hoạt động của RAG

Quy trình gồm ba giai đoạn:

1. Lập chỉ mục: Chia tài liệu của bạn thành các đoạn, tạo ra những embedding (thể hiện bằng vector) và lưu trữ chúng trong cơ sở dữ liệu vector.

2. Truy xuất: Khi người dùng đặt câu hỏi, chuyển đổi câu hỏi thành embedding, tìm kiếm trong cơ sở dữ liệu vector các đoạn tương tự và trả về những kết quả phù hợp nhất.

3. Tạo: Gửi các đoạn đã truy xuất làm ngữ cảnh cho LLM cùng với câu hỏi của người dùng. LLM trả lời dựa trên ngữ cảnh được cung cấp, chứ không phải dữ liệu huấn luyện của nó.

Câu hỏi của người dùng → Nhúng → Tìm kiếm trong cơ sở dữ liệu vector → Top K khối
                                              ↓
                       Prompt hệ thông + Các khối + Câu hỏi → LLM → Câu trả lời

Chia nhỏ tài liệu: Nền tảng

Cách bạn chia tài liệu quyết định chất lượng truy xuất. Chia nhỏ sai cách và RAG của bạn sẽ bị hỏng ngay từ đầu.

Khuyến nghị về kích thước đoạn văn:

  • 200-500 từ mỗi đoạn (điểm tối ưu được nghiên cứu chứng minh)
  • Quá nhỏ (< 100 từ): Các đoạn thiếu ngữ cảnh, câu trả lời không đầy đủ
  • Quá lớn (> 1000 từ): Các đoạn chứa quá nhiều chủ đề, độ chính xác truy xuất giảm

Chồng chéo: Thêm 20-30% chồng chéo giữa các đoạn liên tiếp. Nếu đoạn 1 gồm các từ 1-400, đoạn 2 bắt đầu từ từ 300, chứ không phải từ 401. Điều này ngăn ngừa mất thông tin ở phần ranh giới phân chia.

Chiến lược chia nhỏ tài liệu:

Chiến lượcCách hoạt độngTốt nhất để
Kích thước cố địnhTách mỗi N từ/tokenThiết lập nhanh, kích thước đồng nhất
Ngữ nghĩaChia đoạn văn/phầnDuy trì sự mạch lạc của ý tưởng
Đệ quyChia theo tiêu đề, sau đó theo đoạn văn, rồi theo câuTài liệu có cấu trúc (tài liệu hướng dẫn, cẩm nang)
Nhận biết tài liệuTuân thủ cấu trúc tài liệu (tiêu đề, code block)Tài liệu kỹ thuật

Đối với hầu hết các trường hợp sử dụng của nhà phát triển, việc chia nhỏ đệ quy với tiêu đề phần làm ranh giới chính là hiệu quả nhất. Không bao giờ nên chia nhỏ các code block giữa chừng.

Kiểm tra nhanh: Tài liệu codebase của bạn có một phần mang tên "Authentication" dài 2.000 từ. Bạn nên chia nhỏ nó như thế nào?

Câu trả lời: Sử dụng phương pháp chia nhỏ dựa trên tiêu đề. Chia nhỏ tại các tiêu đề phụ H2/H3 trong phần Authentication - "OAuth Flow" trở thành một khối, "API Key Management" trở thành một khối khác, "Session Handling" trở thành khối thứ ba. Mỗi chủ đề phụ vẫn được giữ nguyên. Bao gồm tiêu đề cha "Authentication" làm siêu dữ liệu trên mỗi khối để hệ thống truy xuất biết chúng có liên quan.

Truy xuất: Tìm ngữ cảnh phù hợp

Truy xuất cơ bản: Nhúng câu hỏi của người dùng, tìm K khối tương tự nhất bằng độ tương đồng cosine. Phương pháp này hiệu quả với các câu hỏi trực tiếp nhưng gặp khó khăn với:

  • Các câu hỏi được diễn đạt lại (người dùng nói "làm thế nào để đăng nhập" nhưng tài liệu lại nói "xác thực")
  • Các câu hỏi đa bước (câu trả lời yêu cầu kết nối thông tin từ nhiều phần khác nhau)
  • Phủ định ("cái gì KHÔNG hỗ trợ SSO")

Các kỹ thuật truy xuất được cải tiến:

Tăng cường truy vấn: Tạo 3-5 câu trả lời diễn đạt lại câu hỏi của người dùng và truy xuất cho mỗi câu trả lời. Các cách diễn đạt khác nhau tương ứng với những từ vựng khác nhau trong tài liệu của bạn.

# Tạo các biến thể truy vấn
queries = generate_variants(user_question)
# ["How do I authenticate?", "Login process", "Auth setup guide",
#  "Getting started with authentication"]

# Truy xuất cho mỗi truy vấn, loại bỏ các kết quả trùng lặp
all_chunks = []
for query in queries:
    all_chunks.extend(retrieve(query, top_k=3))
unique_chunks = deduplicate(all_chunks)

Xếp hạng lại: Sau khi truy xuất ban đầu, sử dụng mô hình xếp hạng lại để chấm điểm lại các khối theo mức độ liên quan đến câu hỏi gốc. Điều này cải thiện đáng kể độ chính xác.

Lọc siêu dữ liệu: Gắn thẻ các khối bằng siêu dữ liệu (tài liệu nguồn, phần, ngày, danh mục) và lọc trước khi tìm kiếm ngữ nghĩa. "Câu hỏi về thanh toán" → chỉ tìm kiếm các khối liên quan đến thanh toán.

Lắp ráp ngữ cảnh

Bạn đã truy xuất được 5 khối liên quan. Bây giờ hãy lắp ráp chúng vào cửa sổ ngữ cảnh của LLM.

Quy tắc lắp ráp:

  1. Liên quan nhất trước. Hiệu ứng "biến mất ở giữa chừng" có nghĩa là LLM ít chú ý đến nội dung ở giữa. Hãy đặt những đoạn thông tin quan trọng nhất ở đầu.
  2. Bao gồm tài liệu tham khảo nguồn. Gắn thẻ nguồn cho mỗi đoạn thông tin: "[Từ: Hướng dẫn Xác thực, Mục 3.2]". Điều này giúp LLM trích dẫn nguồn và giúp bạn gỡ lỗi khi truy xuất.
  3. Tuân thủ giới hạn token. Mỗi mô hình có một cửa sổ ngữ cảnh. Hãy chừa chỗ cho prompt hệ thống, câu hỏi của người dùng và việc tạo đầu ra. Cửa sổ ngữ cảnh 128K không có nghĩa là bạn nên điền đầy 127K bằng các đoạn thông tin.
  4. Thêm hướng dẫn truy xuất. Hãy nói với LLM: "Chỉ trả lời dựa trên ngữ cảnh được cung cấp. Nếu ngữ cảnh không chứa câu trả lời, hãy nói 'Tôi không có thông tin về điều đó'."

Kiểm tra nhanh: RAG của bạn truy xuất 10 đoạn thông tin với tổng cộng 8.000 token. Cửa sổ ngữ cảnh của bạn là 128K. Bạn có nên gửi cả 10 đoạn không?

Câu trả lời: Có lẽ là không. Càng nhiều đoạn thông tin càng nhiều nhiễu. Chỉ gửi 3-5 đoạn thông tin liên quan nhất. Các đoạn thông tin bổ sung sẽ làm loãng tín hiệu và tăng chi phí mà không cải thiện chất lượng tương xứng. Chất lượng ngữ cảnh quan trọng hơn số lượng.

Kỹ thuật ngữ cảnh (Context Engineering) vượt qua ngoài RAG

RAG là một cách để tập hợp ngữ cảnh. Lĩnh vực rộng hơn — kỹ thuật ngữ cảnh — bao gồm:

  • Lịch sử hội thoại: Bao gồm các tin nhắn trước đó có liên quan (không phải tất cả)
  • Profile người dùng: Chèn thông tin cụ thể của người dùng (sở thích, lịch sử)
  • Kết quả công cụ: Kết quả từ các lệnh gọi hàm trước đó trong cuộc hội thoại
  • Hướng dẫn động: Điều chỉnh prompt hệ thống dựa trên nhiệm vụ hiện tại

Kỹ năng nằm ở việc quyết định ngữ cảnh nào mà mô hình cần để trả lời tốt - và loại trừ mọi thứ khác.

Những điểm chính cần ghi nhớ

  • RAG dựa trên phản hồi của LLM trong dữ liệu của bạn - giảm ảo giác bằng cách cung cấp ngữ cảnh thực tế
  • Chia tài liệu thành các đoạn 200 - 500 từ với độ trùng lặp 20-30%; Tôn trọng cấu trúc tài liệu (không chia nhỏ các code block)
  • Cải thiện khả năng truy xuất bằng cách tăng cường truy vấn (nhiều cách diễn đạt khác nhau) và xếp hạng lại (chấm điểm lại theo mức độ liên quan)
  • Tập hợp ngữ cảnh với các đoạn văn bản liên quan nhất trước tiên - LLM ít chú ý đến nội dung ở giữa
  • Chất lượng ngữ cảnh quan trọng hơn số lượng - 3 đoạn văn bản có mức độ liên quan cao hơn 10 đoạn văn bản tầm thường
  • Yêu cầu LLM CHỈ trả lời từ ngữ cảnh được cung cấp để ngăn chặn trường hợp dự phòng ảo giác
  • Câu 1:

    Bạn có một cuốn cẩm nang kỹ thuật 500 trang. Quy trình RAG của bạn trả về kết quả trung bình mặc dù có các embedding tốt. Một đồng nghiệp đề xuất GraphRAG. Nó sẽ bổ sung thêm điều gì?

    GIẢI THÍCH:

    RAG tiêu chuẩn truy xuất các khối dữ liệu dựa trên sự tương đồng về ngữ nghĩa - tốt cho các kết quả khớp trực tiếp, nhưng yếu đối với những mối quan hệ. GraphRAG bổ sung một đồ thị tri thức ánh xạ các kết nối: lỗi này liên quan đến cấu hình đó, API này gọi dịch vụ đó, tham số này ảnh hưởng đến hành vi đó. Đối với tài liệu kỹ thuật lớn, GraphRAG cải thiện đáng kể độ chính xác truy xuất vì hầu hết các câu hỏi liên quan đến những mối quan hệ, không chỉ là khớp từ khóa.

  • Câu 2:

    Bạn chia tài liệu của mình thành các đoạn 100 từ cho RAG. LLM liên tục đưa ra câu trả lời không đầy đủ vì ngữ cảnh liên quan trải rộng trên hai đoạn văn. Làm thế nào để khắc phục điều này?

    GIẢI THÍCH:

    Ranh giới giữa các đoạn văn thường chia cắt ngữ cảnh quan trọng. Một câu về các tham số của hàm có thể kết thúc trong một đoạn văn trong khi kiểu trả về nằm ở đoạn văn tiếp theo. Các đoạn văn chồng chéo (chồng chéo 20-30%) đảm bảo rằng nội dung ranh giới xuất hiện trong cả hai đoạn văn. Nghiên cứu khuyến nghị các đoạn văn 200-500 từ có sự chồng chéo. Quá nhỏ (100 từ) sẽ mất ngữ cảnh; quá lớn (2000 từ) sẽ thêm nhiễu và tốn nhiều token hơn. Mỗi đoạn văn bao gồm sự chồng chéo 20-30% với các đoạn văn lân cận. Một đoạn văn kết thúc giữa đoạn văn sẽ tiếp tục sang đoạn văn tiếp theo, bảo toàn ngữ cảnh mà nếu không nội dung sẽ bị mất ở phần ranh giới phân chia.

  • Câu 3:

    Quy trình RAG của bạn truy xuất 5 đoạn văn bản liên quan nhưng mô hình LLM lại bỏ qua đoạn quan trọng nhất và trả lời dựa trên kiến ​​thức chung. Vấn đề có thể là gì?

    GIẢI THÍCH:

    Hiệu ứng 'mất tích giữa chừng' đã được ghi nhận rõ ràng: Mô hình LLM chú ý mạnh hơn đến phần đầu và cuối cửa sổ ngữ cảnh của chúng. Nếu đoạn văn bản liên quan nhất của bạn nằm giữa 4 đoạn văn bản ít liên quan hơn, mô hình có thể bỏ sót nó. Hai cách khắc phục: sắp xếp các đoạn văn bản được truy xuất theo điểm liên quan (tốt nhất trước), hoặc hướng dẫn rõ ràng mô hình 'ưu tiên thông tin từ các nguồn được cung cấp đầu tiên'. Chúng chú ý nhiều hơn đến nội dung ở đầu và cuối ngữ cảnh. Đặt các đoạn văn bản liên quan nhất lên trước, hoặc sử dụng bộ xếp hạng lại để sắp xếp theo mức độ liên quan trước khi lắp ráp.

Thứ Hai, 04/05/2026 13:52
51 👨
Xác thực tài khoản!

Theo Nghị định 147/2024/ND-CP, bạn cần xác thực tài khoản trước khi sử dụng tính năng này. Chúng tôi sẽ gửi mã xác thực qua SMS hoặc Zalo tới số điện thoại mà bạn nhập dưới đây:

Số điện thoại chưa đúng định dạng!
Số điện thoại này đã được xác thực!
Bạn có thể dùng Sđt này đăng nhập tại đây!
Lỗi gửi SMS, liên hệ Admin
0 Bình luận
Sắp xếp theo
    ❖ Kỹ thuật thiết kế Prompt