Bỏ qua tới nội dung chính
Quay lại tin tức

Cách quyết định kích thước khối dữ liệu (Chunk Size) trong mọi dự án: Hướng dẫn phỏng vấn đầy đủ

Medium Towards AI· Kusum Singh· 12/8/2026general

Hướng dẫn này bao gồm khuôn khổ ra quyết định mà các nhà phỏng vấn mong đợi bạn giải thích, cùng với các đánh đổi thực tế và phương pháp giải quyết vấn đề. 🎯 **Tuyên bố mở đầu phỏng vấn (30 giây đầu tiên)** Điều nhà phỏng vấn muốn nghe: "Kích thước đoạn (chunk size) KHÔNG phải là một con số cố định - đó là một quyết định thiết kế dựa trên nhiều yếu tố: loại tài liệu, độ chính xác của truy xuất, ngân sách token, cửa sổ ngữ cảnh của LLM và yêu cầu về độ trễ. Tôi sử dụng một phương pháp tiếp cận có hệ thống: phân tích các ràng buộc → mô hình hóa các yêu cầu → kiểm tra bằng các chỉ số → lặp lại." 📋 **KHUÔN KHỔ CÓ HỆ THỐNG (Cấu trúc câu trả lời cốt lõi)** Bước 1: Hiểu các ràng buộc của dự án

Hướng dẫn này trình bày khuôn khổ ra quyết định mà các nhà tuyển dụng mong đợi bạn giải thích, cùng với các đánh đổi thực tế và phương pháp giải quyết vấn đề. 🎯 **Tuyên bố mở đầu phỏng vấn (30 giây đầu tiên)** Điều nhà tuyển dụng muốn nghe: "Kích thước đoạn (chunk size) KHÔNG phải là một con số cố định – đó là một quyết định thiết kế dựa trên nhiều yếu tố: loại tài liệu, độ chính xác truy xuất, ngân sách token, cửa sổ ngữ cảnh của LLM và yêu cầu về độ trễ. Tôi sử dụng một phương pháp tiếp cận có hệ thống: phân tích các ràng buộc → mô hình hóa các yêu cầu → kiểm tra bằng các chỉ số → lặp lại." 📋 **KHUNG HỆ THỐNG (Cấu trúc câu trả lời cốt lõi)** **Bước 1: Hiểu các ràng buộc của dự án** **A. Loại tài liệu & Lĩnh vực** Câu hỏi phỏng vấn: “Kích thước đoạn sẽ khác nhau như thế nào đối với tài liệu pháp lý so với bài báo tin tức?” Mẫu câu trả lời: Tài liệu pháp lý (1.000-2.000 từ): - Lý do: Một điều khoản hoặc phần là một đơn vị ý nghĩa không thể chia cắt. - Rủi ro: Việc cắt giữa chừng một điều khoản sẽ tạo ra sự mơ hồ trong truy xuất. - Ví dụ: Các điều khoản hợp đồng phải hoàn chỉnh để đảm bảo tính chính xác. Bài báo tin tức (400-800 từ): - Lý do: Độc giả mong đợi thông tin ở cấp độ đoạn văn. - Lợi ích: Các đoạn nhỏ hơn cho phép truy xuất chủ đề chính xác. - Đánh đổi: Có thể cần sự chồng chéo để kết nối các ý tưởng. **B. Yêu cầu về trường hợp sử dụng** Hãy tự hỏi những câu hỏi này: 1. YÊU CẦU ĐỘ CHÍNH XÁC □ Cần độ chính xác cao? → Các đoạn NHỎ HƠN (400-600 từ) Ví dụ: Khám phá pháp lý, chẩn đoán y tế. □ Độ chính xác vừa phải? → Các đoạn TRUNG BÌNH (700-1.200 từ) Ví dụ: Hỗ trợ kỹ thuật, hệ thống FAQ. □ Ngữ cảnh rộng có chấp nhận được? → Các đoạn LỚN HƠN (1.500-2.500 từ) Ví dụ: Hỏi đáp kiến thức tổng quát. 2. LOẠI TRUY XUẤT □ Cần khớp chính xác? → Các đoạn NHỎ HƠN Ví dụ: "Tìm điều khoản cụ thể này." □ Khớp ngữ nghĩa? → Các đoạn TRUNG BÌNH Ví dụ: "Tìm thông tin về việc hoàn tiền." □ Khớp chủ đề? → Các đoạn LỚN HƠN Ví dụ: "Giải thích các kiến thức cơ bản về học máy (machine learning)." 3. YÊU CẦU VỀ ĐỘ TRỄ □ Thời gian thực (< 500ms)? → Các đoạn NHỎ HƠN (Nhúng nhanh hơn, tìm kiếm nhanh hơn) □ Dưới một giây (< 2s)? → Các đoạn TRUNG BÌNH □ Có thể chấp nhận độ trễ? → Các đoạn LỚN HƠN (Nhiều ngữ cảnh hơn đồng nghĩa với câu trả lời tốt hơn) 4. ĐỘ NHẠY CẢM VỀ CHI PHÍ □ Ngân sách eo hẹp? → Các đoạn NHỎ HƠN (Ít phép nhúng (embedding) cần tính toán hơn) □ Có thể chi tiêu? → Các đoạn LỚN HƠN (Nhiều phép nhúng hơn = độ chính xác tốt hơn) Ví dụ trả lời phỏng vấn: "Đối với một chatbot trả lời các yêu cầu hỗ trợ khách hàng, tôi sẽ phân tích: - Độ chính xác: Trung bình-cao (độ chính xác quan trọng). - Truy xuất: Ngữ nghĩa (người dùng đặt câu hỏi theo nhiều cách khác nhau). - Độ trễ: < 2 giây (chấp nhận được cho trò chuyện). - Chi phí: Ngân sách vừa phải. Điều này gợi ý các đoạn 600-1.000 từ với độ chồng chéo 15%." **Bước 2: Các ràng buộc về mô hình & cơ sở hạ tầng** **A. Cửa sổ ngữ cảnh của LLM** # Phép tính chính mà nhà tuyển dụng mong đợi: NGÂN_SÁCH_NGỮ_CẢNH = CỬA_SỔ_NGỮ_CẢNH_LLM * 0,6 # Dự trữ 60% để đảm bảo an toàn # Ví dụ với Claude 3 Sonnet (200K token) tổng_token = 200.000 ngân_sách_an_toàn = tổng_token * 0,6 # 120.000 token dự_trữ_cho_lời_nhắc = 20.000 token dự_trữ_cho_phản_hồi = 10.000 token khả_dụng_cho_ngữ_cảnh = 90.000 token # Bây giờ tính ngược từ các đoạn: token_trên_1000_ký_tự = 250 # Ước tính sơ bộ ký_tự_khả_dụng = 90.000 / 250 * 1.000 # ~360.000 ký tự # Nếu kích_thước_đoạn = 2.000 ký tự, chúng ta có thể chứa bao nhiêu đoạn? số_đoạn_tối_đa = 360.000 / 2.000 # ~180 đoạn # Nhưng thông thường chỉ sử dụng 5 đến 10 đoạn hàng đầu ngân_sách_hợp_lý = 10 * 2.000 # 20.000 ký tự = 5.000 token Trả lời phỏng vấn: "Với cửa sổ 200K token của Claude, tôi sẽ phân bổ: - 60% cho ngữ cảnh (120K token). - 15% cho lời nhắc (30K token). - 15% cho phản hồi (30K token). - 10% vùng đệm an toàn (20K token). Nếu mỗi đoạn 2.000 ký tự tương đương khoảng 500 token, tôi có thể chứa an toàn 10-15 đoạn. Tính ngược lại: 15 đoạn * 2.000 ký tự = 30.000 ký tự." B. Các hạn chế của mô hình nhúng # Hầu hết các mô hình nhúng đều có giới hạn đầu vào: EMBEDDING_LIMITS = { "OpenAI (text-embedding-3-large)": "8.191 token (~6.000 từ)", "Anthropic (own embeddings)": "thay đổi", "Cohere": "1.024 token (giới hạn an toàn)", "Local models (ONNX)": "thường là 512-2.048 token", } # Điều này giới hạn kích thước đoạn (chunk size) TRƯỚC khi nhúng: # Nếu mô hình nhúng chấp nhận tối đa 1.024 token: # Điều đó tương đương khoảng 750-1.000 từ hoặc 3.000-4.000 ký tự # Kích thước đoạn an toàn < giới hạn nhúng CHUNK_SIZE = min(2.000_ký_tự, giới_hạn_mô_hình_nhúng) Câu hỏi phỏng vấn: Khả năng của mô hình nhúng ảnh hưởng đến quyết định kích thước đoạn của bạn như thế nào? Trả lời: "Các mô hình nhúng có giới hạn token. Ví dụ, mô hình của Cohere xử lý an toàn 1.024 token. Vì 1 token ≈ 4 ký tự: - 1.024 token ≈ tối đa 4.000 ký tự Ngay cả khi tôi muốn các đoạn 2.000 ký tự cho trường hợp sử dụng của mình, tôi phải xác minh mô hình nhúng có thể xử lý được hay không. Nếu không thể, tôi sẽ: 1. Sử dụng một mô hình nhúng có khả năng hơn (mô hình 8K của OpenAI) 2. Giảm kích thước đoạn (1.500-2.000 ký tự) 3. Chia các đoạn: nhúng các đoạn nhỏ hơn, nhưng truy xuất với đoạn cha để có ngữ cảnh đầy đủ Mô hình nhúng thường là yếu tố giới hạn." Bước 3: Phân tích các chỉ số hiệu suất A. Các chỉ số chính cần đánh giá class ChunksizeMetrics: """ Những gì nhà tuyển dụng mong đợi bạn đo lường: """ def __init__(self): self.metrics = { # Chất lượng truy xuất "Precision@K": "Trong K kết quả hàng đầu, có bao nhiêu kết quả liên quan?", "Recall@K": "Trong tất cả các tài liệu liên quan, có bao nhiêu tài liệu nằm trong K kết quả hàng đầu?", "NDCG@K": "Normalized Discounted Cumulative Gain (chất lượng xếp hạng)", "MRR": "Mean Reciprocal Rank (vị trí của kết quả liên quan đầu tiên)", # Chi phí & Hiệu suất "Embedding_Time": "Số giây để nhúng tất cả các đoạn", "Search_Latency": "Số giây để tìm K kết quả hàng đầu", "Storage_Size": "Dung lượng GB cần thiết để lưu trữ tất cả các nhúng", "Cost_Per_Query": "Chi phí $ (cuộc gọi API cho các nhúng)", # Chất lượng câu trả lời "Hallucination_Rate": "% thông tin bịa đặt trong câu trả lời", "Citation_Accuracy": "% trích dẫn dẫn đến nguồn chính xác", "Context_Coverage": "% thông tin liên quan trong ngữ cảnh", "Token_Efficiency": "Thông tin hữu ích trên mỗi token trong ngữ cảnh" } B. Cách trình bày các chỉ số trong phỏng vấn Câu hỏi phỏng vấn: Bạn sẽ đánh giá kích thước đoạn của mình là tối ưu như thế nào? Trả lời: "Tôi sẽ chạy các thử nghiệm với 3 kích thước đoạn: nhỏ (400 từ), trung bình (800 từ), lớn (1.500 từ). Đối với mỗi kích thước, tôi đo lường: 1. RETRIEVAL (Truy xuất)

Nguồn tin: Medium Towards AI — Tác giả: Kusum Singh. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.