Chuyển đến nội dung chính

Bài đăng

Đang hiển thị bài đăng từ Tháng 5, 2026

Xây dựng RAG với Gemini

Cấu trúc cơ bản của hệ thống Retrieval-Augmented Generation (RAG): Kết nối dữ liệu riêng với mô hình ngôn ngữ lớn (LLM). RAG sử dụng Gemini là kiến trúc kết hợp một hệ thống truy xuất thông tin với mô hình Gemini để tạo câu trả lời có căn cứ trên dữ liệu riêng. Đây là cách phù hợp khi xây chatbot tài liệu, trợ lý nội bộ, hệ thống hỏi đáp trên tài liệu kỹ thuật hoặc ứng dụng cần làm việc với dữ liệu mà mô hình không thể biết sẵn. Điểm quan trọng là RAG không huấn luyện lại Gemini. Thay vào đó, hệ thống tìm các đoạn tài liệu liên quan đến câu hỏi rồi đưa chúng vào prompt như ngữ cảnh trước khi mô hình sinh câu trả lời. RAG thay đổi cách Gemini nhận thông tin như thế nào? Một mô hình ngôn ngữ lớn chỉ có thể trực tiếp sử dụng thông tin xuất hiện trong ngữ cảnh của yêu cầu hoặc kiến thức đã được học trong quá trình huấn luyện. Nếu hỏi về tài liệu nội bộ mới cập nhật, Gemini không tự động biết nội dung đó. RAG bổ sung một bước r...

TF-IDF thực sự đo gì? Tính đặc trưng và giới hạn

Tóm tắt nội dung TF-IDF không đo “độ quan trọng tuyệt đối” của một từ. Chính xác hơn, nó đo mức độ nổi bật của từ trong một tài liệu so với corpus dùng làm nền tham chiếu. Cùng một tài liệu và cùng một từ có thể nhận trọng số TF-IDF khác nhau khi corpus thay đổi. Đây vừa là sức mạnh, vừa là một nguồn sai lệch quan trọng. Từ hiếm không đồng nghĩa với từ hữu ích. Lỗi chính tả, mã sản phẩm hay token nhiễu cũng có thể nhận IDF rất cao. Điểm mạnh đặc biệt của TF-IDF là khả năng tạo ra một bản đồ tương phản của dữ liệu : đâu là vocabulary chung và đâu là những tín hiệu khiến từng tài liệu khác phần còn lại. Hai bài trước đã trả lời TF-IDF được tính như thế nào và vì sao tồn tại nhiều biến thể TF, IDF và normalization. Bài cuối đi vào câu hỏi quan trọng hơn: TF-IDF thực sự nhìn thấy điều gì trong dữ liệu? Cách gọi TF-IDF là “độ quan trọng của từ” tiện cho việc nhập môn nhưng dễ gây hiểu nhầm. TF-IDF không biết một từ có quan trọng về mặt ngữ nghĩa hay không. Nó thực hiện một ph...

Những lỗi kỹ thuật khi xây RAG

RAG có thể cho kết quả kém dù vector database, embedding model và LLM đều hoạt động đúng. Bài viết phân tích những lỗi kỹ thuật khó phát hiện nhất trong pipeline RAG, từ mất thông tin khi chunking đến retrieval nhiễu, context sai và evaluation đánh lừa, kèm các case study để xác định lỗi nằm ở đâu. Nhận diện và khắc phục các lỗi kỹ thuật trong kiến trúc Retrieval-Augmented Generation (RAG) Một hệ thống Retrieval-Augmented Generation (RAG) có thể chạy ổn về mặt phần mềm nhưng vẫn trả lời sai một cách rất thuyết phục. Nguyên nhân thường không nằm ở một model duy nhất mà xuất hiện tại ranh giới giữa ingestion, chunking, retrieval, reranking, context construction và generation. Điều nguy hiểm là nhiều lỗi RAG không tạo exception hay log đỏ. Pipeline vẫn trả về document, LLM vẫn sinh câu trả lời hợp ngữ pháp, latency vẫn bình thường. Vì vậy, kỹ sư cần chẩn đoán RAG như một hệ thống nhiều tầng thay vì nhìn output cuối rồi kết luận rằng “LLM hallucinate”. Lỗi đầu ti...

Context Engineering trong RAG: Lọc, nén và sắp xếp

Trong một hệ thống Retrieval-Augmented Generation (RAG) , lấy được tài liệu liên quan mới chỉ là một nửa công việc. Nếu đưa nguyên toàn bộ kết quả retrieval vào prompt, mô hình vẫn có thể bị phân tán bởi đoạn dư thừa, thông tin lặp hoặc bằng chứng quan trọng nằm ở vị trí khó chú ý. Context Engineering trong RAG là bước biến tập tài liệu truy xuất thành ngữ cảnh phù hợp nhất trước khi gửi cho Large Language Model (LLM). Thay vì hỏi “retriever tìm được gì?”, bước này tập trung vào câu hỏi thực tế hơn: “LLM nên nhìn thấy chính xác những gì và theo thứ tự nào?”. Context Engineering nằm ở đâu trong pipeline RAG? Một pipeline RAG đơn giản thường có dạng: Query → Retrieval → Context Processing → Prompt → LLM → Answer Retrieval chịu trách nhiệm tìm các chunk có khả năng chứa câu trả lời. Context processing tiếp tục xử lý tập chunk đó bằng cách loại nhiễu, rút gọn nội dung, điều chỉnh thứ tự và chọn lượng thông tin vừa với giới hạn context window của mô hình. Ví dụ, với câu hỏi...

Query Transformation trong RAG: Rewrite, HyDE và Decomposition

Sau chunking, embedding, hybrid retrieval và reranking, một nguyên nhân quan trọng khiến RAG vẫn truy xuất kém nằm ngay ở query . Câu hỏi của người dùng được viết để giao tiếp tự nhiên, trong khi tài liệu trong index thường dùng thuật ngữ, cấu trúc và mức độ chi tiết khác. Query transformation là nhóm kỹ thuật biến đổi truy vấn trước hoặc trong quá trình retrieval nhằm tăng khả năng tìm được tài liệu relevant. Các kỹ thuật phổ biến gồm query rewriting, query expansion, query decomposition, multi-query retrieval và HyDE. Vì sao query gốc chưa chắc là query tốt để retrieval? Người dùng thường đặt câu hỏi theo cách thuận tiện cho họ chứ không theo vocabulary của document collection. Ví dụ, người dùng có thể hỏi: “Vì sao tài khoản của tôi cứ bị đá ra ngoài sau một lúc không dùng?” Trong tài liệu kỹ thuật, cùng vấn đề có thể được mô tả bằng các thuật ngữ như session timeout , idle timeout hoặc session expiration . Dense retrieval có thể xử lý một phần chênh lệch ngữ nghĩa nà...