Ngày 7 · Data Foundations — Embedding & Vector Store

Ý chínhGiảng viên mở bằng một tình huống cụ thể: agent chăm sóc khách hàng dùng đúng model mạnh nhưng vẫn trả lời sai chính sách hoàn tiền, vì dữ liệu nó đọc là bản chính sách cũ. Câu hỏi được giữ xuyên suốt ngày học: làm sao agent tìm được đúng thứ trong kho tài liệu của bạn, giữa hàng trăm file? Giảng viên giới thiệu năm đầu ra của ngày — phân loại dữ liệu, chia nhỏ tài liệu, biến nghĩa thành vector, lưu và lọc được bằng vector store, và nối được dữ liệu riêng vào agent — và nói rõ ngày học không lặp lại phần token hay context đã học trước đó, mà đi tiếp vào cách tổ chức dữ liệu đứng sau context đó.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và vì sao dữ liệu thường quyết định chất lượng câu trả lời hơn là đổi model.

Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.

Ý chínhPhần lớn lỗi của một agent không nằm ở model mà nằm ở dữ liệu nó được phép đọc: model mạnh vẫn trả lời sai nếu tài liệu đưa vào là bản cũ, thiếu, hoặc sai định dạng. Khảo sát ngành cho thấy tỷ lệ tổ chức áp dụng AI tạo sinh tăng rất nhanh trong hai năm liền kề, và câu hỏi trọng tâm khi triển khai đã chuyển từ "dùng model nào" sang "agent được phép biết gì". Nếu dữ liệu sai, cũ, lộn xộn, hoặc không được tìm đúng lúc, câu trả lời sẽ yếu dù model đứng sau nó mạnh đến đâu. Đây là lý do một ngày học riêng cho nền tảng dữ liệu đứng trước khi học retrieval và RAG đầy đủ.

Kỹ năngHọc viên giải thích được vì sao chất lượng dữ liệu thường quyết định trải nghiệm hơn việc đổi sang model mạnh hơn.

Hình thứcVideo 5 phút, mở bằng tình huống agent trả lời sai, đóng bằng biểu đồ tỷ lệ áp dụng AI tạo sinh hai năm liền kề.

Ý chínhCó ba cách đưa dữ liệu vào model cho cùng một câu hỏi: dán thẳng nội dung vào ngữ cảnh, tìm và nạp đúng đoạn liên quan bằng RAG, hoặc huấn luyện lại trọng số bằng fine-tuning. Ba cách phù hợp với ba tình huống khác nhau: ngữ cảnh trực tiếp hợp với tài liệu ngắn và ít đổi; RAG hợp với kho lớn cần trích đúng nguồn và cập nhật thường xuyên; fine-tuning hợp khi cần model học giọng điệu hoặc định dạng riêng chứ không phải để nạp thêm sự thật mới. Nhầm lẫn phổ biến là dùng fine-tuning để nạp kiến thức mới — fine-tuning dạy model cách nói, còn RAG cung cấp điều cần nói; khi sự thật thay đổi thường xuyên, RAG luôn là lựa chọn đúng hơn. Học viên thử cả ba cách trên cùng một câu hỏi và quan sát điểm mạnh, điểm yếu của từng cách hiện ra trực tiếp.

Kỹ năngHọc viên chọn được cách đưa dữ liệu phù hợp cho một tình huống cụ thể và giải thích được vì sao fine-tuning không thay thế được RAG khi sự thật hay đổi.

Hình thứcTương tác mô phỏng 4 phút, dự đoán rồi quan sát: học viên dự đoán cách nào phù hợp với ba tình huống cấu hình sẵn trước khi xem kết quả — độ chính xác, khả năng trích nguồn, công sức thiết lập của từng cách. Phương án thay thế: bảng so sánh ba cách kèm ví dụ.

Ý chínhMột agent thường cần ba loại dữ liệu khác nhau, và mỗi loại nên đi theo một đường xử lý riêng. Knowledge data — chính sách, quy trình, câu hỏi thường gặp, tài liệu nội bộ — phù hợp để tìm kiếm theo ngữ nghĩa vì nội dung ổn định và cần trích đúng nguồn. Operational data — trạng thái đơn hàng, hồ sơ trong cơ sở dữ liệu, số liệu giao dịch — cần truy vấn có kiểm soát thay vì tìm kiếm tự do, vì dữ liệu đổi liên tục và câu trả lời phải chính xác tuyệt đối chứ không phải "gần đúng về nghĩa". Contextual data — lịch sử phiên, hồ sơ người dùng, ngôn ngữ đang trò chuyện — nên được đưa thẳng vào ngữ cảnh ở đúng thời điểm chứ không cần tìm kiếm hay lưu trữ lâu dài. Gộp cả ba loại vào một vector store rồi tìm kiếm ngữ nghĩa cho tất cả là nhầm lẫn phổ biến, vì loại thứ hai cần độ chính xác mà tìm kiếm ngữ nghĩa không đảm bảo được.

Kỹ năngHọc viên phân loại được một nhu cầu dữ liệu cụ thể vào một trong ba loại và chọn đúng đường xử lý — tìm kiếm, truy vấn có kiểm soát, hoặc đưa thẳng vào ngữ cảnh.

Hình thứcTương tác mô phỏng 4 phút, dự đoán rồi quan sát trên dữ liệu cấu hình sẵn: học viên dự đoán loại dữ liệu và đường xử lý cho tám tình huống của một cửa hàng trực tuyến, rồi xem hệ thống chỉ ra đúng hay sai kèm lý do. Phương án thay thế: bảng phân loại kèm ví dụ mẫu.

Ý chínhDữ liệu đưa vào agent thường đi qua bốn tầng chất lượng tăng dần: raw là dữ liệu thô ngay sau khi thu thập, còn lỗi định dạng và nhiễu; cleaned đã bỏ phần rác, chuẩn hoá ký tự; structured đã được chia theo phần rõ ràng và gắn nguồn; enriched đã được gắn thêm nhãn — chủ đề, mức truy cập, độ tin cậy — để lọc và định tuyến chính xác hơn khi tìm kiếm. Sai lầm phổ biến là đưa thẳng dữ liệu ở tầng raw vào tìm kiếm ngữ nghĩa rồi kỳ vọng bước tìm kiếm sẽ tự sửa mọi vấn đề — thực tế thì lỗi ở tầng dưới sẽ lan thẳng vào câu trả lời cuối. Đầu tư vào việc nâng tầng dữ liệu thường mang lại cải thiện rõ hơn là đổi thuật toán tìm kiếm.

Kỹ năngHọc viên gọi tên đúng bốn tầng chất lượng dữ liệu và chỉ ra được lỗi cụ thể xảy ra ở tầng nào khi thấy một ví dụ dữ liệu xấu.

Hình thứcVideo 5 phút, tháp bốn tầng hiện dần từ dưới lên, mỗi tầng kèm một ví dụ cụ thể.

Ý chínhTrước khi đưa bất kỳ nguồn nào vào hệ thống, 4 câu hỏi quản trị cần được trả lời: ai sở hữu và chịu trách nhiệm cập nhật dữ liệu này; ai được phép truy cập, và dữ liệu nào cần giới hạn theo phòng ban; chu kỳ làm mới là bao lâu để tránh dùng nội dung đã lỗi thời; và thông tin định danh cá nhân có cần được che trước khi đưa vào hệ thống tìm kiếm hay không. Nguyên tắc ngược với thói quen phổ biến "nạp hết vào rồi tính sau": mỗi nguồn dữ liệu nên có câu trả lời cho cả 4 câu hỏi trước khi được đưa vào, không phải sau khi xảy ra sự cố.

Kỹ năngHọc viên liệt kê được 4 câu hỏi quản trị cần trả lời trước khi đưa một nguồn dữ liệu vào hệ thống.

Hình thứcVideo 4 phút, 4 câu hỏi hiện thành danh sách kiểm tra kèm một ví dụ áp dụng đầy đủ.

Ý chính3 câu kiểm tra: khi nào chọn RAG thay vì fine-tuning, ba loại dữ liệu và đường xử lý tương ứng, 4 câu hỏi quản trị dữ liệu.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay, có giải thích khi sai.

Ý chínhChunking là chia một tài liệu dài thành các đoạn nhỏ hơn để mỗi đoạn được biến thành vector và lưu trữ riêng. Ba lý do bắt buộc phải chunk: model biến văn bản thành vector có giới hạn độ dài đầu vào; nếu để nguyên một file thành một vector thì tìm kiếm chỉ trả về đúng cả file chứ không trả về đúng đoạn cần; và đưa quá nhiều nội dung không liên quan vào ngữ cảnh làm câu trả lời kém chính xác hơn, không phải tốt hơn. Khi cắt, thường giữ lại một phần cuối của đoạn trước làm phần đầu đoạn sau — gọi là overlap — để không mất ngữ cảnh ngay tại điểm cắt; overlap càng nhiều thì càng tốn dung lượng lưu trữ, nên mức phổ biến chỉ khoảng 10 đến 15% độ dài đoạn.

Kỹ năngHọc viên giải thích được ba lý do phải chunk và mô tả được vì sao overlap giúp giữ ngữ cảnh tại điểm cắt.

Hình thứcVideo 6 phút. Một tài liệu dài hiện dần bị cắt thành ba đoạn có phần chồng lấn ở mép, kèm hình minh hoạ giới hạn đầu vào của embedding model.

Ý chínhCùng một câu hỏi thường gặp, ba cách chunk cho ba kết quả khác nhau. Chunk quá to gộp nhiều chủ đề vào cùng một vector: tìm kiếm vẫn trúng đoạn chứa câu trả lời, nhưng model phải đọc thêm nhiều nội dung không liên quan lẫn vào, làm câu trả lời bị nhiễu. Chunk quá nhỏ tách rời câu hỏi khỏi câu trả lời: tìm kiếm trả về đúng câu nhưng thiếu ngữ cảnh nên model không biết áp dụng cho việc gì. Chunk hợp lý giữ trọn một ý trong một đoạn, đủ ngắn để không lẫn chủ đề khác, đủ dài để không mất ngữ cảnh — học viên quan sát trực tiếp câu trả lời của model thay đổi ra sao khi cùng một câu hỏi được tìm trên ba cách chunk khác nhau.

Kỹ năngHọc viên nhận ra được chunk quá to gây nhiễu và chunk quá nhỏ gây mất ngữ cảnh khi so sánh trực tiếp câu trả lời trên cùng một câu hỏi.

Hình thứcỞ nhà: video 5 phút dựng lại cùng một tài liệu bị chia theo ba cách. Trên lớp: tương tác cặp tương phản 3 phút, học viên chọn một câu hỏi, xem kết quả tìm kiếm và câu trả lời trên cả ba cách chunk cấu hình sẵn, đặt cạnh nhau để so sánh. Phương án thay thế: bảng ba cột so sánh kết quả có sẵn.

Ý chínhCác chiến lược chunking chia thành ba nhóm theo mức phức tạp tăng dần. Nhóm nền tảng cắt theo số lượng cố định, theo ranh giới tự nhiên như đoạn và câu, hoặc theo heading khi tài liệu có cấu trúc rõ — đây là điểm bắt đầu hợp lý cho phần lớn trường hợp. Nhóm ngữ nghĩa cắt dựa trên nội dung thay vì đếm ký tự: theo dõi độ tương đồng giữa các câu liền kề và cắt khi chủ đề đổi, hoặc lưu từng câu kèm vài câu xung quanh để vừa chính xác vừa đủ ngữ cảnh — tốn thêm bước tính toán khi nạp dữ liệu nhưng thường tăng độ chính xác trên tài liệu dài, ít cấu trúc. Nhóm chuyên biệt xử lý các trường hợp đặc thù: lưu đoạn nhỏ để tìm nhưng trả về đoạn lớn hơn chứa nó, chia theo nhiều tầng cho kho tài liệu rất lớn, hoặc giữ nguyên cấu trúc bảng và mã nguồn khi cắt. Không có kích thước chunk nào đúng cho mọi trường hợp — lựa chọn tốt là lựa chọn được đo bằng kết quả tìm kiếm thật, không phải một con số nghe có vẻ hợp lý.

Kỹ năngHọc viên gọi tên được ba nhóm chiến lược chunking và nêu được một tình huống nên dùng nhóm ngữ nghĩa thay vì nhóm nền tảng.

Hình thứcVideo 6 phút, bảng ba nhóm hiện dần kèm ví dụ cho từng chiến lược. Kèm bảng chiến lược chunking một trang, liệt kê cách cắt, điểm mạnh, điểm yếu của từng chiến lược, để học viên dùng khi làm lab.

Ý chínhThay vì chọn chiến lược theo cảm tính, có một trình tự quyết định dựa trên triệu chứng quan sát được. Nếu tài liệu có heading hoặc cấu trúc rõ, bắt đầu bằng cắt theo heading; nếu văn bản chảy dài không có cấu trúc, thử cắt theo ranh giới tự nhiên trước, rồi mới thử nhóm ngữ nghĩa nếu chưa đủ tốt. Nếu tìm kiếm đã trúng đúng đoạn nhưng model vẫn thiếu ngữ cảnh để trả lời, chuyển sang lưu đoạn nhỏ nhưng trả về đoạn lớn hơn chứa nó; nếu tìm kiếm trúng nhưng model bị nhiễu bởi nội dung thừa, chuyển sang chunk nhỏ hơn. Nguyên tắc chung: bắt đầu bằng chiến lược đơn giản nhất chạy được, dựng một bộ câu hỏi kiểm tra, rồi mới nâng cấp dựa trên kết quả đo được — không nhảy thẳng vào chiến lược phức tạp chỉ vì nó nghe hiện đại hơn.

Kỹ năngHọc viên chọn được chiến lược chunking phù hợp cho một tài liệu cụ thể bằng cách đi theo trình tự quyết định thay vì đoán.

Hình thứcVideo 4 phút, trình tự quyết định hiện thành sơ đồ nhánh theo từng câu hỏi.

Ý chính3 câu kiểm tra: hậu quả của chunk quá to so với quá nhỏ, khi nào dùng nhóm ngữ nghĩa, cách đọc trình tự quyết định chọn chiến lược.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhCon người nhận ra hai câu, hai ảnh, hoặc một câu và một ảnh có cùng ý nghĩa gần như ngay lập tức, nhưng máy không làm được điều đó trực tiếp trên văn bản hay hình ảnh thô. Embedding model là một hàm biến dữ liệu thô — văn bản, hình ảnh, âm thanh — thành một vector số có cùng số chiều, đưa mọi loại dữ liệu vào chung một không gian toán học. Sau khi có vector, đo khoảng cách giữa hai vector chính là đo độ giống nhau về nghĩa: câu "chính sách hoàn tiền" và câu "refund policy" viết bằng hai ngôn ngữ khác nhau vẫn cho ra hai vector nằm gần nhau, vì embedding học nghĩa chứ không so khớp từng chữ. Đây là nền tảng cho tìm kiếm theo ngữ nghĩa, gom nhóm, và phát hiện trùng lặp nội dung.

Kỹ năngHọc viên giải thích được embedding model làm gì và vì sao nó cho phép so sánh nghĩa giữa hai ngôn ngữ hoặc hai định dạng khác nhau.

Hình thứcVideo 5 phút, một câu và một ảnh cùng nội dung cùng đi qua embedding model rồi hội tụ gần nhau trong không gian vector.

Ý chínhCó hai cách phổ biến để đo khoảng cách giữa hai vector. Cosine đo góc giữa hai vector, bỏ qua độ dài: giá trị bằng 1 khi cùng hướng, bằng 0 khi vuông góc, và giảm dần khi hướng lệch nhau — vì mẫu số chia cho tích hai độ dài nên độ dài của vector bị triệt tiêu. Euclidean đo khoảng cách đường thẳng giữa hai điểm, có tính đến cả độ dài lẫn hướng, nên phù hợp khi độ lớn của vector cũng mang thông tin thật, ví dụ toạ độ hoặc số đo cảm biến. Với embedding văn bản, câu hỏi ngắn và một trang tài liệu dài cùng chủ đề vẫn có thể có cosine cao dù độ dài rất khác nhau — đây là lý do cosine thường được chọn mặc định cho tìm kiếm ngữ nghĩa, còn Euclidean phù hợp hơn khi gom nhóm dữ liệu có đơn vị đo giống nhau.

Kỹ năngHọc viên dự đoán được điểm cosine giữa hai câu trước khi tính, và giải thích được vì sao cosine phù hợp với tìm kiếm ngữ nghĩa hơn Euclidean.

Hình thứcỞ nhà: video 6 phút, hai vector hiện trên mặt phẳng, góc và khoảng cách được đo song song để so sánh trực tiếp. Trên lớp: tương tác dự đoán rồi quan sát 3 phút — học viên đoán điểm cosine giữa các cặp câu cấu hình sẵn trước khi xem điểm thật. Phương án thay thế: bảng ví dụ điểm số có sẵn kèm giải thích.

Ý chínhTheo công thức, hai vector ngược hướng hoàn toàn cho cosine bằng −1, và trực giác toán học thường dẫn tới suy đoán rằng hai câu trái nghĩa hoàn toàn — ví dụ một câu khen và một câu chê cùng sản phẩm — sẽ có cosine gần −1. Trong embedding văn bản thật, điều này hiếm khi xảy ra: hai câu cùng chủ đề nhưng trái sắc thái vẫn thường có cosine dương, vì embedding phần lớn phân bố trong một vùng hẹp của không gian thay vì trải đều ra mọi hướng. Cosine đo được câu hỏi có cùng chủ đề hay không, không đo được câu đó mang sắc thái tích cực hay tiêu cực — nhầm hai điều này là nhầm lẫn phổ biến khi mới học embedding. Học viên dự đoán điểm cosine cho một cặp câu trái nghĩa trước, rồi so với điểm thật để thấy khoảng cách giữa trực giác toán học và hành vi thật của embedding.

Kỹ năngHọc viên phân biệt được cosine đo chủ đề chứ không đo sắc thái, và không còn kỳ vọng câu trái nghĩa cho cosine gần −1.

Hình thứcTương tác dự đoán rồi quan sát 4 phút: học viên đoán điểm cosine cho một cặp câu trái sắc thái cấu hình sẵn, sau đó xem điểm thật và một hình minh hoạ vùng phân bố hẹp của embedding. Phương án thay thế: video 3 phút trình bày cùng ví dụ.

Ý chínhNgoài tìm kiếm theo ngữ nghĩa, embedding còn dùng để gom nhóm nội dung theo chủ đề, phát hiện các đoạn nội dung trùng lặp lưu ở nhiều nơi, và gợi ý nội dung liên quan dựa trên điều người dùng vừa tương tác. Khi chọn embedding model, không có model nào tốt nhất cho mọi trường hợp — cần cân nhắc số chiều của vector, chất lượng trên tác vụ tìm kiếm, và ngôn ngữ dữ liệu. Một khi đã embed toàn bộ dữ liệu bằng một model, việc đổi sang model khác đòi hỏi nhúng lại toàn bộ từ đầu, vì hai model khác nhau dù cho ra vector cùng số chiều vẫn không nằm chung một không gian — có cùng số chiều không có nghĩa là có thể so sánh trực tiếp với nhau. Vì vậy nên chọn một model ổn định ngay từ đầu thay vì đổi liên tục theo mỗi bảng xếp hạng mới.

Kỹ năngHọc viên liệt kê được ba ứng dụng của embedding ngoài tìm kiếm, và giải thích được vì sao đổi embedding model buộc phải nhúng lại toàn bộ dữ liệu.

Hình thứcVideo 5 phút, ba ứng dụng hiện lần lượt kèm ví dụ, rồi minh hoạ hai model cùng số chiều nhưng vector không cùng không gian.

Ý chính3 câu kiểm tra: khi nào dùng cosine thay vì Euclidean, cosine đo chủ đề hay đo sắc thái, vì sao đổi embedding model phải nhúng lại toàn bộ dữ liệu.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhMỗi bản ghi trong vector store gồm bốn thành phần: một mã định danh; đoạn văn bản gốc để đưa vào ngữ cảnh khi trả lời; embedding vector để dùng cho tìm kiếm; và metadata dạng khoá-giá trị để lọc. Vector dùng để tìm, đoạn văn bản gốc dùng để đưa vào prompt cho model — hai thứ khác chức năng nhưng được lưu cùng nhau trong một bản ghi. Kết quả trả về khi truy vấn là danh sách bản ghi gần nhất, không phải chính vector đã lưu; đây là chỗ dễ nhầm giữa thứ được lưu và thứ được trả về.

Kỹ năngHọc viên gọi tên được bốn thành phần của một bản ghi trong vector store và phân biệt được vector dùng để tìm với đoạn văn bản dùng để trả lời.

Hình thứcVideo 4 phút, một bản ghi thật hiện dần từng trường. Kèm mẫu record vector store một trang, liệt kê bốn trường và ví dụ giá trị, để học viên dùng khi làm lab.

Ý chínhMetadata đi kèm mỗi đoạn văn bản cho phép lọc trước hoặc sau khi tìm kiếm ngữ nghĩa: nguồn và tên file để truy vết và hiển thị xuất xứ; danh mục để giới hạn phạm vi tìm trước khi so sánh vector; thời điểm cập nhật để tránh dùng nội dung đã cũ; mức truy cập để giới hạn ai được thấy đoạn nào. Tìm kiếm tốt là kết hợp độ tương đồng ngữ nghĩa với việc lọc metadata, không phải chỉ dựa vào điểm số: lọc đúng danh mục trước khi so sánh vector giúp thu hẹp phạm vi tìm và giảm khả năng trả về đoạn đúng chủ đề nhưng sai ngữ cảnh. Nhầm lẫn phổ biến là xem nhẹ metadata lúc khối lượng dữ liệu còn nhỏ, rồi gặp khó khi dữ liệu tăng lên và không còn cách nào lọc đúng phạm vi cần tìm.

Kỹ năngHọc viên liệt kê được các trường metadata thường dùng và giải thích được vì sao lọc metadata cần đi kèm tìm kiếm ngữ nghĩa.

Hình thứcVideo 5 phút, bảng các trường metadata hiện dần kèm tác dụng của từng trường.

Ý chínhBa tham số kiểm soát kết quả tìm kiếm trả về những gì: top-k quyết định lấy bao nhiêu đoạn gần nhất, ít cho câu hỏi đơn giản và nhiều hơn khi cần tổng hợp từ nhiều nguồn; ngưỡng điểm loại bỏ những đoạn có độ tương đồng thấp hơn một mức nhất định, để chỉ giữ lại đoạn thật sự liên quan; và lọc theo metadata giới hạn phạm vi tìm trước khi so sánh vector, ví dụ chỉ tìm trong tài liệu của một phòng ban. Ba tham số này thường phối hợp theo trình tự: lọc phạm vi trước, tìm kiếm ngữ nghĩa sau, rồi mới áp ngưỡng điểm lên kết quả. Một ngưỡng điểm cụ thể không mang ý nghĩa cố định — cùng một ngưỡng có thể quá chặt với chunk dài và quá lỏng với chunk ngắn, nên ngưỡng cần được chọn theo dữ liệu thật chứ không theo một con số nghe hợp lý.

Kỹ năngHọc viên phân biệt được vai trò của top-k, ngưỡng điểm, và lọc metadata, và giải thích được vì sao một ngưỡng điểm cố định không phù hợp với mọi bộ dữ liệu.

Hình thứcVideo 5 phút, ba tham số minh hoạ trên cùng một truy vấn, kết quả thay đổi khi từng tham số được điều chỉnh.

Ý chínhTìm kiếm ngữ nghĩa mạnh với văn bản tự nhiên nhưng thất bại với dữ liệu có cấu trúc chặt: một mã đơn hàng hoặc mã hợp đồng nhìn giống một chuỗi ký tự vô nghĩa đối với embedding, nên tìm gần đúng theo nghĩa không giúp ích — loại dữ liệu này cần tra đúng bằng khoá, không cần vector hoá. Một câu hỏi về chính sách đổi trả thì ngược lại: có ngữ nghĩa rõ, diễn đạt theo nhiều cách khác nhau vẫn cần tìm đúng nội dung, nên phù hợp với vector store. Bài học chung là dữ liệu có cấu trúc rõ ràng và câu trả lời đòi hỏi chính xác tuyệt đối nên đi qua tra cứu trực tiếp hoặc truy vấn có kiểm soát; dữ liệu diễn đạt bằng ngôn ngữ tự nhiên và cần khớp theo nghĩa mới nên vào vector store. Học viên xem cùng một vector store được hỏi bằng một câu dạng mã và một câu dạng ngôn ngữ tự nhiên, và quan sát kết quả khác nhau ra sao.

Kỹ năngHọc viên phân biệt được dữ liệu nên đưa vào vector store với dữ liệu nên tra cứu trực tiếp, dựa trên việc dữ liệu có cấu trúc chặt hay diễn đạt tự nhiên.

Hình thứcỞ nhà: video 4 phút đối chiếu một câu hỏi dạng mã và một câu hỏi ngôn ngữ tự nhiên trên cùng một vector store. Trên lớp: tương tác cặp tương phản 3 phút, học viên thử thêm các câu hỏi khác cấu hình sẵn và dự đoán kết quả trước khi xem điểm số thật. Phương án thay thế: bảng đối chiếu kết quả có sẵn.

Ý chínhViệc chọn vector store nên bắt đầu từ vài câu hỏi thực dụng: quy mô dữ liệu dự kiến, mức độ cần lọc metadata phức tạp, có cần kết hợp tìm kiếm từ khoá với tìm kiếm ngữ nghĩa hay không, và đội ngũ có ai vận hành hạ tầng hay không. Với quy mô học tập hoặc thử nghiệm nhỏ, một công cụ chạy ngay trong tiến trình ứng dụng là đủ; với hệ thống đã có sẵn cơ sở dữ liệu quan hệ, thêm phần mở rộng vector vào cơ sở dữ liệu đó thường đơn giản hơn dựng một hệ thống riêng. Đổi vector store về sau là việc tương đối dễ vì phần lớn có cùng thao tác cơ bản — thêm, tìm, lọc; đổi embedding model mới là việc nặng vì bắt buộc phải nhúng lại toàn bộ dữ liệu. Vì vậy không nên dành quá nhiều công sức chọn vector store ngay từ giai đoạn đầu.

Kỹ năngHọc viên nêu được 4 câu hỏi cần trả lời trước khi chọn vector store và giải thích được vì sao đổi vector store dễ hơn đổi embedding model.

Hình thứcVideo 5 phút, 4 câu hỏi hiện thành danh sách kiểm tra kèm ví dụ lựa chọn tương ứng.

Ý chính4 câu kiểm tra: bốn thành phần của một bản ghi, vai trò của lọc metadata, dữ liệu nào không nên vào vector store, vì sao đổi vector store dễ hơn đổi embedding model.

Kỹ năngHọc viên tự kiểm tra trước khi sang module tiếp theo.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhCùng một nội dung, định dạng khác nhau tốn số lượng token khác nhau và giữ cấu trúc khác nhau khi model đọc. Markdown giữ được heading, danh sách, bảng đơn giản, và định dạng nhấn mạnh mà không cần các thẻ đóng mở dài dòng, nên thường là lựa chọn mặc định. HTML giữ được cấu trúc phức tạp hơn — bảng lồng bảng, bố cục nhiều cột — nhưng tốn nhiều token hơn cho các thẻ và thuộc tính; văn bản thuần phù hợp với nội dung không có cấu trúc như thư điện tử hay đoạn hội thoại; định dạng dạng khoá-giá trị phù hợp khi đầu ra cần được một chương trình khác đọc lại. Không có định dạng nào tốt nhất tuyệt đối — chọn theo việc nội dung nguồn cần giữ cấu trúc gì và ai sẽ đọc kết quả.

Kỹ năngHọc viên chọn được định dạng phù hợp cho một loại nội dung cụ thể và giải thích được đánh đổi giữa Markdown và HTML.

Hình thứcVideo 4 phút, bảng bốn định dạng hiện dần kèm ví dụ cùng nội dung ở hai định dạng để so sánh trực tiếp.

Ý chínhĐưa một nguồn dữ liệu vào hệ thống tìm kiếm đi qua ba khối lớn. Khối kiểm soát đầu vào nhận diện đúng định dạng file, mở và xác thực nội dung, chọn công cụ trích xuất phù hợp — không tin vào phần mở rộng file vì một file có đuôi văn bản vẫn có thể chứa nội dung khác hẳn. Khối xử lý trích xuất, làm sạch phần rác, chuẩn hoá, rồi chuyển sang định dạng có cấu trúc. Khối lập chỉ mục chia nhỏ, biến thành vector, rồi lưu cùng metadata. Lỗi tìm kiếm thường không sinh ra ở khối lập chỉ mục mà sinh ra ở hai khối trước — chọn sai nguồn hoặc bỏ qua bước làm sạch — nhưng chỉ lộ ra khi có người đặt câu hỏi, nên khi gỡ lỗi nên đi ngược từ khối cuối về khối đầu.

Kỹ năngHọc viên mô tả được ba khối của pipeline nạp dữ liệu và biết bắt đầu gỡ lỗi từ khối nào khi tìm kiếm cho kết quả kém.

Hình thứcVideo 5 phút, ba khối hiện nối tiếp nhau, mỗi khối kèm một lỗi thường gặp minh hoạ.

Ý chínhHai khái niệm hay bị gộp làm một nhưng phục vụ mục đích khác nhau. Retrieval tìm ngữ cảnh liên quan cho câu hỏi hiện tại, đọc từ một kho tri thức dùng chung, và trọng tâm là độ liên quan và có căn cứ. Memory lưu trạng thái, sở thích, và lịch sử của riêng một người dùng, đọc từ hồ sơ hoặc lịch sử tương tác, và trọng tâm là tính liên tục qua các lần trò chuyện. Trong một phiên trò chuyện, phần ngắn hạn nằm ngay trong cửa sổ ngữ cảnh và dùng để giữ mạch hội thoại hiện tại, còn phần dài hạn nằm ngoài cửa sổ ngữ cảnh và phải được tìm lại mỗi khi cần — cửa sổ ngữ cảnh không tự động là bộ nhớ dài hạn. Nhiều hệ thống dùng cả hai cùng lúc: retrieval để biết sự thật chung, memory để biết người dùng này là ai và đã làm gì trước đó.

Kỹ năngHọc viên phân biệt được retrieval với memory theo mục đích và nguồn dữ liệu, và giải thích được vì sao cửa sổ ngữ cảnh không phải là bộ nhớ dài hạn.

Hình thứcVideo 5 phút, hai cột retrieval và memory hiện song song kèm một ví dụ cho mỗi bên.

Ý chínhToàn bộ nội dung của ngày ghép lại thành một pipeline có hai pha tách biệt. Pha nạp dữ liệu chạy một lần khi có tài liệu mới hoặc khi tài liệu cũ thay đổi: xử lý, chia nhỏ, biến thành vector, rồi lưu. Pha truy xuất chạy mỗi khi có câu hỏi: câu hỏi được biến thành vector bằng đúng embedding model đã dùng lúc nạp, tìm kiếm trong vector store, rồi kết quả được đưa vào ngữ cảnh cho model trả lời. Tách hai pha này rõ ràng giúp việc gỡ lỗi dễ hơn: nếu kết quả sai, câu hỏi đầu tiên luôn là lỗi nằm ở pha nạp — dữ liệu không có hoặc chunk sai — hay ở pha truy xuất — tìm sai hoặc lọc sai.

Kỹ năngHọc viên vẽ được toàn bộ pipeline từ tài liệu đến câu trả lời và chỉ ra được một lỗi cụ thể thuộc pha nạp hay pha truy xuất.

Hình thứcVideo 6 phút, sơ đồ pipeline hiện dần theo hai pha, một ví dụ lỗi được truy ngược từ câu trả lời sai về đúng bước gây lỗi. Kèm sơ đồ pipeline một trang — tài liệu, chunk, vector, lưu trữ, truy vấn, đưa vào ngữ cảnh — để học viên dùng khi làm lab.

Ý chính3 câu kiểm tra: khác biệt giữa retrieval và memory, ba khối của pipeline nạp dữ liệu, hai pha của pipeline truy xuất.

Kỹ năngHọc viên tự kiểm tra trước khi vào lab.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng bốn điểm chính: dữ liệu thường quyết định chất lượng câu trả lời hơn là đổi model; chunking là quyết định thiết kế cần đo bằng kết quả thật, không phải một con số cố định; embedding biến nghĩa thành không gian có thể so sánh nhưng cosine đo chủ đề chứ không đo sắc thái; và vector store chỉ hoạt động tốt khi kết hợp tìm kiếm ngữ nghĩa với metadata, và chỉ nên chứa dữ liệu diễn đạt bằng ngôn ngữ tự nhiên. Giảng viên giới thiệu Ngày 8 sẽ nâng pipeline này thành một hệ thống RAG đầy đủ.

Kỹ năngHọc viên tóm tắt được bốn điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhCông thức đầy đủ của cosine similarity và Euclidean distance cho vector nhiều chiều, cách chuẩn hoá vector về độ dài một, và vì sao khi vector đã chuẩn hoá thì hai cách đo xếp hạng kết quả giống nhau. Mở rộng cho item 3.2.

Kỹ năngHọc viên đọc hiểu được công thức đầy đủ, đủ nền để tự cài đặt phép đo khi cần.

Hình thứcVideo 7 phút, công thức hiện dần từng bước kèm ví dụ số.

Ý chínhCách triển khai các chiến lược chunking chuyên biệt: lưu quan hệ giữa đoạn nhỏ và đoạn lớn chứa nó để tránh trùng lặp lưu trữ; chia nhiều tầng tóm tắt cho kho tài liệu rất lớn; dùng công cụ phân tích cú pháp để không bao giờ cắt giữa một hàm hay một lớp trong mã nguồn. Mở rộng cho item 2.3.

Kỹ năngHọc viên mô tả được cách triển khai một chiến lược chunking chuyên biệt cho một loại tài liệu cụ thể.

Hình thứcVideo 7 phút, ví dụ triển khai cho từng chiến lược chuyên biệt.

Ý chínhNhững yêu cầu vận hành khi một vector store phục vụ người dùng thật: chạy nhiều bản sao để không gián đoạn khi một bản gặp sự cố, đặt trong mạng riêng có kiểm soát truy cập, và có cơ chế sao lưu để khôi phục khi cần. Mở rộng cho item 4.5.

Kỹ năngHọc viên liệt kê được các yêu cầu vận hành cần chuẩn bị trước khi đưa vector store vào phục vụ người dùng thật.

Hình thứcVideo 6 phút, các yêu cầu vận hành hiện thành danh sách kèm lý do.

Ý chínhHoàn thành ba chiến lược chunking cùng phép đo cosine, xây dựng một vector store hỗ trợ tìm kiếm, lọc, và xoá, rồi kết nối kho tri thức đó với một agent theo mẫu RAG. Theo nhóm, thu thập một bộ tài liệu thật, thống nhất 5 câu hỏi kiểm tra kèm câu trả lời chuẩn, và mỗi thành viên thử một chiến lược chunking hoặc metadata riêng trước khi so sánh kết quả trong nhóm. Học viên tự đánh giá kết quả theo 5 góc nhìn: độ chính xác của truy xuất, mức độ trọn vẹn của chunk, mức hữu dụng của metadata, chất lượng căn cứ của câu trả lời, và mức phù hợp của chiến lược với chủ đề đã chọn.

Kỹ năngHọc viên xây dựng được một pipeline nối dữ liệu riêng vào agent, có script chạy được, và giải thích được kết quả so sánh giữa các chiến lược chunking.

Hình thứcLab 150 phút tại lớp với người hướng dẫn, theo repo có sẵn, gồm phần cá nhân hoàn thành mã nguồn và phần nhóm so sánh chiến lược trên cùng một bộ câu hỏi kiểm tra.