Cắt tài liệu thành chunk, và cái giá của mỗi cách cắt
Cắt tài liệu thành chunk, và cái giá của mỗi cách cắt
Quyết định thực tế nhất khi dựng một hệ truy hồi, và cũng là quyết định hầu như ai cũng chọn bừa. Trang này cho bạn chọn rồi trả giá ngay tại chỗ.
Trước khi một mô hình đọc được tài liệu của bạn, tài liệu phải bị cắt nhỏ. Lý do rất tầm thường: cửa sổ ngữ cảnh có hạn, và bộ truy hồi cần những khối đủ nhỏ để phân biệt được khối nào liên quan tới câu hỏi. Nên mọi hệ RAG đều bắt đầu bằng hai con số ai đó gõ vội vào tệp cấu hình, chunk_size với chunk_overlap, rồi không ai đụng lại nữa.
Hai con số đó quyết định câu hỏi nào bạn trả lời được và câu hỏi nào thì không. Chỗ khó chịu là chúng hỏng im lặng: bộ truy hồi vẫn trả về một khối trông rất hợp lý, mô hình vẫn viết ra một câu trôi chảy, chỉ có điều dữ kiện cần thiết đã bị bỏ lại bên kia ranh giới và không ai báo cho bạn biết. Sim dưới đây dựng đúng cảnh đó bằng một sổ tay thiết bị ngắn và một câu hỏi bình thường.
dảinhiệtđộxv40| chunk | dải | nhiệt | độ | xv40 | đủ đáp án |
|---|---|---|---|---|---|
| #0 | ✗ | ✗ | ✗ | ✓ | 1/4 |
| #1 | ✗ | ✗ | ✗ | ✓ | 1/4 |
| #2 | ✓ | ✓ | ✓ | ✗ | 3/4 |
| #3 | ✗ | ✗ | ✗ | ✗ | 0/4 |
| #4 | ✗ | ✗ | ✗ | ✗ | 0/4 |
Trạng thái mở sẵn đang nói gì
Tài liệu mặc định có 267 token và 13 câu. Ở chế độ cắt cứng, kích thước 60, chồng lấn 0, nó bị chia thành 5 chunk ở các mốc token 0, 60, 120, 180 và 240. Không có gì lặp lại, nên tổng token sau khi cắt vẫn đúng 267 và hệ số phình bằng 1,00. Nhìn qua thì cấu hình này gọn gàng, không tốn một byte thừa nào.
Bây giờ đọc bảng cuối sim. Truy vấn là dải nhiệt độ của XV40. Sim bỏ hư từ của và giữ lại bốn từ khoá dải, nhiệt, độ, xv40. Và kết quả là không chunk nào chứa đủ cả bốn. Chunk khá nhất mới gom được 3 trên 4.
Nguyên nhân nhìn thấy được ngay trên dải token tô màu. Câu chứa đáp án là một câu dài bình thường của văn bản kỹ thuật:
Thiết bị XV40, theo bảng thông số kỹ thuật in ở trang cuối cuốn sổ tay này, hoạt động ổn định trong dải nhiệt độ từ âm mười tới năm mươi độ C, và ngoài khoảng đó thì kết quả đo có thể sai lệch mà máy không hề báo lỗi.
Tên thiết bị XV40 nằm ở token 112. Cụm dải nhiệt độ bắt đầu ở token 134. Mốc cắt thứ ba rơi vào token 120, tức là ngay giữa hai chỗ đó. Chunk số 1 giữ đoạn 60 tới 119 nên nó có tên thiết bị mà không có khoảng nhiệt độ. Chunk số 2 giữ đoạn 120 tới 179 nên nó có khoảng nhiệt độ mà không biết đang nói về thiết bị nào. Cả hai đều là mảnh vụn, và mảnh nào được truy hồi thì mô hình cũng chỉ đọc được một nửa dữ kiện.
Không có gì được dàn dựng để mốc 120 rơi đúng chỗ đó. Nó rơi vào đấy vì tài liệu này dài chừng ấy và kích thước chunk là chừng ấy. Đó chính là điều đáng sợ: bạn không thể nhìn hai con số trong tệp cấu hình mà đoán ra chúng sẽ chẻ đôi câu nào.
Lối thoát thứ nhất, chồng lấn, và hoá đơn của nó
Bấm nút Thử chồng lấn 20. Bảng lật ngay: 1 chunk chứa đủ cả bốn từ khoá, chunk số 2 giữ đoạn 80 tới 139, ôm trọn cả XV40 lẫn dải nhiệt độ.
Cái giá hiện ra ở hai ô kế bên. Số chunk tăng từ 5 lên 7, và tổng token sau khi cắt tăng từ 267 lên 387, tức hệ số phình 1,45. Bạn vừa nhân số ô trong kho vector lên gấp rưỡi. Trên dải token tô màu, các ô viền vàng đứt nét chính là những token bị từ hai chunk trở lên cùng giữ, và mỗi ô như vậy là một lần bạn trả tiền nhúng, tiền lưu trữ và tiền quét thêm cho đúng một chữ. Ở chồng lấn 20 thì đúng là hai, nhưng con số đó lớn theo chồng lấn: kéo thanh chồng lấn lên 50 thì có token nằm trong sáu chunk một lúc, và bạn trả tiền sáu lần cho nó. Rê chuột lên một ô để xem con số của riêng nó.
Ở tài liệu này thì thậm chí không cần tới 20. Kéo thanh chồng lấn về 5, tức nấc nhỏ nhất thanh trượt cho phép, bảng đã lật rồi, mà hệ số phình chỉ 1,07. Nhưng đừng mang con số 5 đó đi đâu cả. Nó đúng vì trên tài liệu cụ thể này, cách cắt với chồng lấn 5 tình cờ đặt một mốc ở token 110, và 110 thì sớm hơn 112 vừa đủ. Đổi một chữ trong tài liệu là số đó đổi theo. Thứ duy nhất đúng chung là quan hệ đánh đổi: chồng lấn càng lớn thì khả năng bắc cầu qua ranh giới càng cao và hoá đơn càng dày.
Lối thoát thứ hai, cắt theo câu, và hoá đơn khác của nó
Bấm Thử cắt theo câu. Chế độ này không cắt ở token thứ 60 nữa mà gom trọn từng câu vào chunk, thêm câu chừng nào còn chưa vượt kích thước đặt ra. Kết quả trên tài liệu mặc định trông như một bữa trưa miễn phí: vẫn 5 chunk, hệ số phình 1,00, ô câu không chunk nào chứa trọn về 0, và bảng đáp án vẫn có 1 chunk đủ. Không lặp một token nào mà vẫn vá được chỗ hỏng.
Bữa trưa đó không miễn phí, chỉ là hoá đơn nằm chỗ khác. Chuyển ô tài liệu sang preset Câu dài ngắn lệch nhau rồi giữ nguyên chế độ cắt theo câu, kích thước 60. Chiều dài bốn chunk lần lượt là 19, 72, 18 và 49 token. Một chunk dài 72 token dù bạn xin 60, vì cắt theo câu không được phép xé một câu ra, mà cái câu quy định đó dài hơn kích thước bạn đặt. Sim hiện thẳng cảnh báo về chunk quá khổ khi việc này xảy ra. Cùng tài liệu ấy, cắt cứng cho ba chunk 60, 60 và 38 token, đều đặn hơn hẳn, nhưng đổi lại 2 câu bị chẻ đôi.
Chunk dài ngắn lệch nhau không phải chuyện thẩm mỹ. Điểm tương đồng của bộ truy hồi phụ thuộc vào độ dài khối: một khối 18 token và một khối 72 token không cạnh tranh công bằng với nhau, và cửa sổ ngữ cảnh thì phải chừa chỗ cho khối xấu nhất chứ không phải khối trung bình.
Đẩy tiếp tới ca cực đoan bằng preset Một câu duy nhất: 44 token, không có dấu chấm nào ở giữa. Cắt theo câu không tìm được chỗ nào để cắt nên trả về đúng một chunk 44 token, kể cả khi bạn kéo kích thước xuống 10. Bộ tách câu ở đây cũng chỉ dựa vào dấu chấm, chấm hỏi, chấm than, chấm lửng và chấm phẩy, nên một chữ viết tắt hay một số thập phân sẽ đánh lừa nó, đúng như nó đánh lừa các bộ tách câu trong hệ thống thật.
Cái bất biến khiến những con số trên đáng tin
Có một tính chất phải luôn đúng dù bạn vặn thế nào: ghép các chunk lại theo thứ tự, bỏ đi phần chồng lấn, thì phải dựng lại đúng tài liệu gốc, không thiếu không thừa một token nào. Nếu nó gãy thì hoặc có token rơi vào khoảng trống giữa hai chunk và biến mất khỏi kho, hoặc có token bị nhân bản mà hệ số phình không hề đếm. Cả hai đều là loại lỗi không lộ ra trên màn hình.
Cổng kiểm của trang này cài phép dựng lại đó bằng mã riêng, chỉ đọc chỉ số đầu và chỉ số cuối của từng chunk, rồi quét qua hai chế độ cắt, mười hai tài liệu và toàn bộ tổ hợp kích thước với chồng lấn, tổng cộng 3432 cấu hình. Nhưng phép dựng lại chỉ chứng minh engine nhất quán với chính nó, chưa chứng minh nó tính đúng: một bộ cắt bỏ sót chunk thứ hai rồi khai báo trung thực phần còn lại vẫn dựng lại được tài liệu. Nên chế độ cắt cứng còn bị đối chiếu với một bản cài đặt thứ hai viết độc lập ngay trong file kiểm, ở cả 1716 cấu hình cắt cứng.
Ca có thể treo trình duyệt cũng được khoá, và đáng kể lại vì cách khoá cũ sai. Chồng lấn bằng hoặc lớn hơn kích thước chunk thì bước nhảy bằng 0, vòng lặp không tiến. Engine chặn bằng cách kẹp giá trị, kéo chồng lấn xuống dưới kích thước rồi bật cờ để giao diện nói ra chứ không lặng lẽ đổi cấu hình của bạn. Chỗ sai nằm ở cổng: nó bấm giờ sau lời gọi, mà một vòng lặp không tiến thì không bao giờ chạy tới dòng đọc đồng hồ, nên cổng không đỏ, cổng treo. Giờ phép thử đó chạy trong một tiến trình con có hạn giờ do tiến trình cha áp, và chạy trước mọi thứ khác.
Bốn chỗ trang này nói ít hơn thực tế
Phải nói rõ, không thì bạn mang mấy con số trên đi dùng nhầm chỗ.
- Cách đếm token ở đây không phải cách mô hình đếm. Sim cắt theo khoảng trắng và dấu câu, nên với tiếng Việt mỗi âm tiết thành một token. Bộ tách của mô hình thật chia nhỏ hơn, thường cho số lớn hơn khá nhiều. Chỗ ranh giới rơi vào thì đổi, nhưng lập luận thì không đổi.
- Phép thử "chunk có chứa đủ đáp án không" ở đây là phép thử theo từ khoá. Chunk phải chứa đủ mọi từ khoá của truy vấn thì mới được tính là đủ. Đó đúng là thứ một bộ truy hồi theo từ vựng cần, còn bộ truy hồi theo vector thì mờ hơn: nó có thể lấy đúng chunk chứa
dải nhiệt độmà không cần chữXV40nào. Nhưng mô hình đọc chunk đó vẫn không biết con số ấy nói về thiết bị nào, nên vấn đề không biến mất, nó chỉ khó phát hiện hơn. - Chồng lấn theo câu lùi từng câu một, không lùi từng token. Vì vậy phần lặp lại hiếm khi đúng bằng con số bạn xin, nó chỉ không vượt quá con số đó. Đây là một quy ước cài đặt, không phải chân lý.
- Một chunk lọt hẳn vào trong chunk liền trước thì bị bỏ. Cách lùi theo câu thỉnh thoảng sinh ra loại chunk đó, giữ lại thì chỉ tốn chỗ mà không thêm chữ nào. Sim báo mỗi khi có, và đây cũng là lựa chọn của tôi chứ không phải luật chung.
Còn một chuyện nữa, và nó không có cách sửa: không có kích thước nào đúng cho mọi tài liệu. Kéo thanh kích thước từ 10 tới 160 với chồng lấn 0 rồi nhìn ô câu bị chẻ đôi. Nó có xu hướng giảm khi chunk to ra, nhưng không giảm đều và có chỗ tăng ngược: ở kích thước 55 nó là 2, nhích lên 60 nó vọt lên 4, rồi ở 110 nó xuống 1 và ở 115 lại lên 2. Chunk to hơn không bảo đảm ít câu bị chẻ hơn, vì cái quyết định là các mốc cắt rơi vào đâu so với dấu chấm, chứ không phải khoảng cách giữa chúng. Trong khi đó, với chồng lấn bằng 0 thì mọi kích thước đều cho hệ số phình đúng 1,00, tức là không kích thước nào rẻ hơn kích thước nào. Bạn chỉ đang chọn xem sẽ chẻ đôi câu nào mà thôi.
Cắt tài liệu không phải bước chuẩn bị vô hại, nó là bước quyết định câu hỏi nào hệ của bạn trả lời được. Ở cấu hình mặc định của sim, một câu hỏi hoàn toàn bình thường không có lời đáp chỉ vì mốc cắt ở token 120 rơi vào giữa tên thiết bị và con số. Chồng lấn vá được chỗ đó nhưng nhân kho vector lên 1,45 lần. Cắt theo câu cũng vá được mà không lặp token nào, đổi lại chunk dài ngắn lệch nhau, có khi 72 token khi bạn chỉ xin 60. Cách duy nhất để biết cấu hình của bạn hỏng ở đâu là lấy đúng những câu hỏi người dùng thật sẽ hỏi rồi kiểm xem có chunk nào chứa trọn câu trả lời hay không, đúng như bảng cuối sim này làm.
- 1Ở trạng thái mở sẵn, chunk số 2 gom được 3 trên 4 từ khoá mà bảng vẫn ghi không chunk nào đủ đáp án. Vì sao?
- 2Bấm Thử chồng lấn 20 thì có 1 chunk đủ đáp án, nhưng ô câu không chunk nào chứa trọn vẫn ghi 1. Hai con số đó mâu thuẫn nhau à?
- 3Trên tài liệu mặc định, cắt theo câu cho hệ số phình 1,00 và không câu nào bị chẻ. Vậy vì sao không dùng nó cho mọi thứ?