Hola, I’m Hieu, a Software Engineer

Quy trình thường thấy là: mở bảng xếp hạng, sắp theo điểm trung bình, lấy mô hình đứng đầu vừa túi tiền, rồi đi tiếp. Nó cho ra lựa chọn bảo vệ được khoảng một nửa số lần, và ở nửa còn lại, nó hỏng một cách đắt đỏ — vì đổi mô hình embedding nghĩa là nhúng lại toàn bộ và dựng lại mọi chỉ mục. Đây là những câu hỏi dự báo kết quả tốt hơn thứ hạng. Nó có chạy tốt trên văn bản của bạn không? Điểm trung bình trên benchmark là một hỗn hợp có trọng số của nhiều tác vụ, mà phần lớn không phải tác vụ của bạn. Một mô hình dẫn đầu tổng thể có thể tụt hậu tệ hại ở đúng cái bạn cần — điều khoản pháp lý, mã hàng, ticket hỗ trợ khách hàng tiếng Việt, hay mã nguồn. Bài đánh giá thật sự quan trọng chỉ mất một buổi chiều: Thu 50-100 truy vấn thật từ log của bạn (hoặc tự viết, nếu chưa có lưu lượng). Với mỗi truy vấn, đánh dấu những tài liệu trong kho đáng lẽ phải được truy hồi. Việc gán nhãn này chính là phần công việc thật. Nhúng kho tài liệu bằng từng mô hình ứng viên, chạy các truy vấn, đo r...

Một hệ thống truy hồi trả lời đúng câu “thời hạn hoàn tiền của chúng ta là bao lâu?” nhưng thất bại với câu “thời hạn hoàn tiền có khác với khách doanh nghiệp không?” thường không có vấn đề về mô hình. Nó có một đoạn chứa chính sách chung và một đoạn khác, không bao giờ được truy hồi, chứa ngoại lệ. Việc chia đoạn quyết định một đơn vị truy hồi là gì . Làm sai và không lượng rerank, kỹ thuật prompt hay nâng cấp mô hình nào cứu lại được thông tin bạn đã cắt rời. Chia theo kích thước cố định là mốc so sánh, không phải chiến lược Cách mặc định ai cũng bắt đầu — cắt mỗi N ký tự với M ký tự chồng lấn — đáng được hiểu chính xác, vì đó là thứ bạn sẽ đem ra so sánh. def fixed_chunks (text, size = 1000 , overlap = 200 ): chunks, start = [], 0 while start < len (text): chunks.append(text[start:start + size]) start += size - overlap return chunks Nó làm đúng chỗ nào: đoạn đều nhau, chi phí đoán được, không giả định gì về định dạng tài liệu. Nó là...

Quy trình thường thấy là: mở bảng xếp hạng, sắp theo điểm trung bình, lấy mô hình đứng đầu vừa túi tiền, rồi đi tiếp. Nó cho ra lựa chọn bảo vệ được khoảng một nửa số lần, và ở nửa còn lại, nó hỏng một cách đắt đỏ — vì đổi mô hình embedding nghĩa là nhúng lại toàn bộ và dựng lại mọi chỉ mục. Đây là những câu hỏi dự báo kết quả tốt hơn thứ hạng. Nó có chạy tốt trên văn bản của bạn không? Điểm trung bình trên benchmark là một hỗn hợp có trọng số của nhiều tác vụ, mà phần lớn không phải tác vụ của bạn. Một mô hình dẫn đầu tổng thể có thể tụt hậu tệ hại ở đúng cái bạn cần — điều khoản pháp lý, mã hàng, ticket hỗ trợ khách hàng tiếng Việt, hay mã nguồn. Bài đánh giá thật sự quan trọng chỉ mất một buổi chiều: Thu 50-100 truy vấn thật từ log của bạn (hoặc tự viết, nếu chưa có lưu lượng). Với mỗi truy vấn, đánh dấu những tài liệu trong kho đáng lẽ phải được truy hồi. Việc gán nhãn này chính là phần công việc thật. Nhúng kho tài liệu bằng từng mô hình ứng viên, chạy các truy vấn, đo r...

Một hệ thống truy hồi trả lời đúng câu “thời hạn hoàn tiền của chúng ta là bao lâu?” nhưng thất bại với câu “thời hạn hoàn tiền có khác với khách doanh nghiệp không?” thường không có vấn đề về mô hình. Nó có một đoạn chứa chính sách chung và một đoạn khác, không bao giờ được truy hồi, chứa ngoại lệ. Việc chia đoạn quyết định một đơn vị truy hồi là gì . Làm sai và không lượng rerank, kỹ thuật prompt hay nâng cấp mô hình nào cứu lại được thông tin bạn đã cắt rời. Chia theo kích thước cố định là mốc so sánh, không phải chiến lược Cách mặc định ai cũng bắt đầu — cắt mỗi N ký tự với M ký tự chồng lấn — đáng được hiểu chính xác, vì đó là thứ bạn sẽ đem ra so sánh. def fixed_chunks (text, size = 1000 , overlap = 200 ): chunks, start = [], 0 while start < len (text): chunks.append(text[start:start + size]) start += size - overlap return chunks Nó làm đúng chỗ nào: đoạn đều nhau, chi phí đoán được, không giả định gì về định dạng tài liệu. Nó là...