Manticore Search bổ sung tính năng chia đoạn tự động: Cải thiện tìm kiếm vector cho tài liệu dài

Manticore Search vừa giới thiệu khả năng chia đoạn tài liệu (chunking) ngay trong định nghĩa bảng, giải quyết một vấn đề âm thầm nhưng nghiêm trọng: các tài liệu dài vượt quá cửa sổ đầu vào của mô hình embedding bị cắt cụt mà không hề báo lỗi. Bài viết này phân tích cách tính năng hoạt động, các chiến lược chia đoạn, và những con số đo lường thực tế.

Vấn đề: nửa tài liệu biến mất mà không ai hay biết

Hãy hình dung bạn xây dựng hệ thống tìm kiếm cho tài liệu nội bộ của nhóm — hướng dẫn vận hành, runbook, báo cáo sự cố. Bạn có một bảng với auto embeddings: bạn chèn văn bản, Manticore chạy mô hình và tự động điền cột vector. Bạn nạp một tài liệu dài 4.000 từ. Câu lệnh chèn thành công. Tìm kiếm hoạt động. Mọi thứ trông có vẻ ổn.

Nhưng mô hình bạn chọn chỉ có cửa sổ đầu vào 512 token, còn tài liệu đó dài khoảng 5.000 token. Mô hình chỉ đọc 380 từ đầu tiên và vứt bỏ 3.600 từ còn lại. Phần nội dung phía sau sẽ mãi mãi không thể truy xuất được, và không có bất kỳ cảnh báo nào cho bạn biết điều đó. Vector embedding cũng có thể không đại diện cho toàn bộ tài liệu.

Trước đây, bạn thường phải tự tách tài liệu thành nhiều phần, tạo embedding cho từng phần, rồi tìm cách gộp kết quả nếu muốn tìm kiếm theo tài liệu thay vì theo đoạn. Manticore giờ xử lý việc này ngay trong định nghĩa bảng: thêm chunk_strategy vào cột vector trong lệnh CREATE TABLE, và Manticore sẽ tự động chia tài liệu thành các đoạn, tạo embedding cho từng đoạn và tìm kiếm trên tất cả chúng.

DROP TABLE IF EXISTS docs;
CREATE TABLE docs (
    title text,
    content text,
    chunks float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
        model_name='Xenova/all-MiniLM-L6-v2' from='title,content'
        chunk_strategy='sentence' max_tokens='256' overlap_tokens='32'
);

Đó là toàn bộ tính năng. Không cần pipeline nạp dữ liệu, không cần thư viện tách văn bản, không cần bảng thứ hai cho các đoạn, không cần GROUP BY để gộp kết quả đoạn trở lại thành tài liệu.

Cấu trúc chia đoạn văn bản trong cơ sở dữ liệu vector

Tóm tắt nhanh

• Năm chiến lược: truncate (mặc định cũ), mean, fixed, recursive, sentence. Đặt qua chunk_strategy trên cột vector có hỗ trợ mô hình.
• truncate và mean tạo một vector cho mỗi tài liệu, dùng cột float_vector. fixed, recursive và sentence tạo nhiều vector, nên cần cột float_vector_array.
• Một tài liệu vẫn là một kết quả tìm kiếm duy nhất. Các đoạn cạnh tranh riêng lẻ, và Manticore trả về tài liệu một lần, với knn_dist() báo khoảng cách tới đoạn gần nhất. Tham số k đếm tài liệu, không đếm đoạn.
• Các tham số tinh chỉnh: max_tokens (kích thước đoạn), overlap_tokens (token chia sẻ giữa các đoạn liền kề), max_chunks (giới hạn số đoạn mỗi tài liệu).
• Đo trên tài liệu hướng dẫn Manticore (189 trang, ~298.000 từ): với nội dung nằm ngoài cửa sổ mô hình, recall@5 tăng từ 55,1% lên 83,3% và MRR từ 0,44 lên 0,70, đổi lại tốn khoảng 2,5× RAM và 4× thời gian nạp.
• Truy vấn không bao giờ bị chia đoạn. Truy vấn đủ ngắn để embedding nguyên vẹn; chỉ tài liệu lưu trữ mới bị tách.

Minh họa vấn đề bằng ví dụ nhỏ

Giả sử bạn có bốn tài liệu:

• Backup and restore runbook — khoảng 700 từ, tương đương 900 token. Nội dung về lịch backup, thời gian lưu trữ, diễn tập khôi phục, thông tin xác thực, quy hoạch dung lượng. Phần cuối giải thích cách luân chuyển chứng chỉ TLS dùng cho cổng replication.
• Monitoring and alerting guide — không liên quan.
• Getting started with the CLI — không liên quan.
• TLS and certificates for the HTTP API — một trang ngắn hoàn toàn nói về chứng chỉ, nhưng không hề nhắc đến luân chuyển hay replication.

Bạn tạo bảng với ba cột vector cùng nguồn văn bản — mỗi cột dùng một chiến lược. Một lệnh INSERT duy nhất điền cả ba, nên điều kiện so sánh là hoàn toàn giống nhau:

DROP TABLE IF EXISTS docs;
CREATE TABLE docs (
    title text,
    body text,
    v_truncate float_vector       knn_type='hnsw' hnsw_similarity='cosine'
        model_name='Xenova/all-MiniLM-L6-v2' from='title,body',
    v_mean     float_vector       knn_type='hnsw' hnsw_similarity='cosine'
        model_name='Xenova/all-MiniLM-L6-v2' from='title,body' chunk_strategy='mean',
    v_sentence float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
        model_name='Xenova/all-MiniLM-L6-v2' from='title,body'
        chunk_strategy='sentence' max_tokens='128' overlap_tokens='32'
);

Đặt cùng một câu hỏi mà câu trả lời nằm ở phần cuối của runbook, chạy một lần cho mỗi chiến lược:

SELECT title, knn_dist() FROM docs
WHERE knn(v_truncate, 4, 'how do I rotate the TLS certificate used for replication');

SELECT title, knn_dist() FROM docs
WHERE knn(v_mean, 4, 'how do I rotate the TLS certificate used for replication');

SELECT title, knn_dist() FROM docs
WHERE knn(v_sentence, 4, 'how do I rotate the TLS certificate used for replication');

Chiến lược	Kết quả 1	Kết quả 2
truncate (mặc định)	TLS and certificates for the HTTP API — 0.762	Backup and restore runbook — 0.936
mean	Backup and restore runbook — 0.656	TLS and certificates for the HTTP API — 0.762
sentence, 128 token, overlap 32	Backup and restore runbook — 0.254	TLS and certificates for the HTTP API — 0.700

Với truncate, tài liệu thực sự trả lời câu hỏi lại thua một tài liệu đánh lừa chỉ trông có vẻ nói về chứng chỉ. Vector duy nhất của runbook được tạo từ những trang đầu về lịch backup và diễn tập khôi phục, vì đó là tất cả những gì mô hình được phép đọc.

Với chia đoạn theo câu, runbook được lưu thành 9 vector thay vì 1. Một trong số đó chính là đoạn văn về luân chuyển chứng chỉ. Nó khớp với truy vấn gần như chính xác, nên tài liệu thắng với khoảng cách áp đảo: 0.254 so với 0.700.

Chi tiết về các chiến lược chia đoạn

Chiến lược	Số vector/tài liệu	Loại cột	Chức năng
truncate	1	float_vector	Embedding tối đa những gì vừa cửa sổ mô hình, bỏ phần còn lại. Chế độ duy nhất có ở phiên bản cũ, và vẫn là mặc định.
mean	1	float_vector	Chia toàn bộ tài liệu, embedding từng phần, lấy trung bình thành một vector.
fixed	N	float_vector_array	Cửa sổ cố định theo số token max_tokens.
recursive	N	float_vector_array	Chia theo thứ bậc dấu phân cách — đoạn, dòng, câu, khoảng trắng — giữ mỗi phần trong giới hạn max_tokens.
sentence	N	float_vector_array	Ranh giới câu (chuẩn Unicode UAX #29), gom đầy đủ câu đến khi chạm giới hạn token.

Điểm khác biệt quan trọng không nằm ở cách cắt văn bản, mà ở ý nghĩa của một kết quả khớp.

Với một vector cho mỗi tài liệu, tìm kiếm hỏi rằng: "tài liệu này, xét tổng thể, có giống với truy vấn không?" Một đoạn văn liên quan duy nhất sẽ bị pha loãng bởi mọi thứ xung quanh, và một tài liệu đề cập đến năm chủ đề khác nhau sẽ chẳng thực sự khớp với chủ đề nào.

Với một vector cho mỗi đoạn, tìm kiếm hỏi rằng: "tài liệu này có chứa nội dung gì giống với truy vấn không?" Mỗi đoạn cạnh tranh bằng giá trị riêng của nó, và Manticore trả về tài liệu một lần, chấm điểm theo đoạn tốt nhất.

truncate — giữ lại khi tài liệu của bạn ngắn

title text,
v float_vector knn_type='hnsw' hnsw_similarity='cosine'
    model_name='Xenova/all-MiniLM-L6-v2' from='title'

Đây là thứ bạn đang dùng; chunk_strategy='truncate' là mặc định và bạn không bao giờ phải viết ra. Đây là lựa chọn đúng — và nhanh nhất, nhỏ nhất — khi văn bản của bạn thực sự vừa cửa sổ mô hình: tiêu đề sản phẩm, mô tả ngắn, thẻ tag, tin nhắn chat, dòng log, câu truy vấn tìm kiếm, tiêu đề commit.

Vậy bao nhiêu là vừa? Nhiều hơn đa số người tưởng, và ít hơn họ hy vọng. all-MiniLM-L6-v2 nhận 512 token, tương đương khoảng 380 từ tiếng Anh. text-embedding-3-small nhận 8.192 token. Nếu tài liệu ở phân vị 95% của bạn nằm thoải mái dưới giới hạn, hãy dừng đọc và giữ truncate.

Khi nào thì có hại: mọi nội dung dạng dài. Trang hướng dẫn, bài viết cơ sở tri thức, hợp đồng, biên bản cuộc họp, chuỗi email, trang wiki, file README, báo cáo sự cố.

mean — một vector nhưng là cả tài liệu

v float_vector knn_type='hnsw' hnsw_similarity='cosine'
    model_name='Xenova/all-MiniLM-L6-v2' from='title,content'
    chunk_strategy='mean'

Manticore chia tài liệu, embedding từng đoạn, rồi lấy trung bình các vector đoạn thành một vector chuẩn hóa duy nhất. Chi phí lưu trữ và tìm kiếm giống hệt truncate — một vector mỗi tài liệu, một nút HNSW — nhưng không vứt bỏ bất cứ thứ gì.

Dùng khi bạn muốn phần đuôi tài liệu cũng được tính nhưng không kham nổi nhiều vector hơn; khi cột bắt buộc phải là float_vector (ví dụ bạn đang thêm cột bằng ALTER, mà các chiến lược đa vector không hỗ trợ); hoặc khi tài liệu của bạn chỉ nói về một chủ đề duy nhất, chỉ là dài.

Đừng dùng khi một tài liệu đề cập đến nhiều chủ đề không liên quan. Lấy trung bình điều khoản bồi thường với điều khoản thanh toán của một hợp đồng pháp lý sẽ tạo ra một vector nằm ở giữa chúng và gần như không khớp với cái nào.

fixed — dễ dự đoán, dễ lý giải nhất

v float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
    model_name='Xenova/all-MiniLM-L6-v2' from='content'
    chunk_strategy='fixed' max_tokens='256' overlap_tokens='32'

Cắt cứ mỗi max_tokens token, bất kể văn bản đang ở đâu. Số đoạn là hàm tuyến tính của độ dài tài liệu, nên kích thước chỉ mục có thể dự đoán trước khi nạp dữ liệu.

Dùng khi văn bản không có cấu trúc đáng tin cậy: đầu ra OCR, HTML bị mất thẻ đoạn văn, bản ghi máy không dấu câu, bản dump log, nội dung đã nén. Cũng là mặc định tốt khi bạn chỉ muốn thứ rẻ nhất chặn được hiện tượng cắt cụt.

Cái giá phải trả: ranh giới có thể rơi vào giữa câu, và một đoạn bắt đầu từ giữa ý sẽ có embedding kém. Đó chính là lý do overlap_tokens tồn tại.

recursive — mặc định tốt nhất cho văn xuôi

v float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
    model_name='Xenova/all-MiniLM-L6-v2' from='title,content'
    chunk_strategy='recursive' max_tokens='256' overlap_tokens='32'

Cùng ngân sách token như fixed, nhưng mỗi nhát cắt được kéo lùi về ranh giới tự nhiên gần nhất: dòng trống trước, rồi ngắt dòng, rồi kết thúc câu, rồi khoảng trắng. Một đoạn dừng ở nơi văn bản dừng, không phải nơi bộ đếm cạn. Ranh giới không bao giờ bị kéo lùi qua điểm giữa của đoạn, nên bạn không nhận được hàng loạt mảnh vụn nhỏ xíu.

Nếu bạn từng dùng RecursiveCharacterTextSplitter của LangChain, đây là cùng ý tưởng, chỉ khác là nó chạy bên trong cơ sở dữ liệu trên token thật của mô hình thay vì ký tự, và không cần cài gì cả.

Dùng cho: tài liệu Markdown và HTML, trang wiki, cơ sở tri thức, bài blog, file README, báo cáo có cấu trúc — mọi thứ con người viết theo đoạn. Đây là chiến lược đạt điểm cao nhất trên nội dung sâu trong bài kiểm thử của Manticore.

sentence — khi đoạn phải là một ý trọn vẹn

v float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
    model_name='Xenova/all-MiniLM-L6-v2' from='content'
    chunk_strategy='sentence' max_tokens='256' overlap_tokens='32'

Phát hiện ranh giới câu bằng chuẩn Unicode UAX #29, rồi gom nguyên câu cho đến khi chạm ngân sách token. Một đoạn không bao giờ bắt đầu hay kết thúc giữa câu. Câu nào dài hơn ngân sách sẽ bị cắt theo cửa sổ token như biện pháp cuối.

Dùng cho: ticket hỗ trợ và chuỗi email, bản ghi chat và cuộc họp, văn bản pháp lý và chính sách, tin tức, đánh giá khách hàng, tóm tắt y khoa và khoa học — mọi thứ mà một mảnh câu có thể làm thay đổi hoặc phá hủy ý nghĩa. Đây cũng là chiến lược nên chọn khi các đoạn sẽ được đưa tiếp cho một LLM, vì một đoạn kết thúc giữa mệnh đề đọc rất tệ trong prompt.

sentence có phần thận trọng hơn recursive: nó tạo ra ít đoạn hơn, sạch hơn, và đạt recall@5 xấp xỉ nhau trong thử nghiệm.

Ba tham số tinh chỉnh

chunk_strategy  = truncate | mean | fixed | recursive | sentence
max_tokens      = kích thước đoạn tính theo token; 0 (mặc định) = giới hạn của mô hình
overlap_tokens  = token chia sẻ giữa các đoạn liên tiếp; cần max_tokens khác 0
max_chunks      = giới hạn số vector mỗi tài liệu; 0 (mặc định) = không giới hạn

max_tokens bị chặn trên theo khả năng thực tế của mô hình — yêu cầu 4.096 trên mô hình 512 token thì bạn vẫn chỉ nhận 512, không báo lỗi. Đoạn nhỏ hơn cho kết quả khớp sắc nét hơn nhưng nhiều vector hơn; đoạn lớn hơn mang nhiều ngữ cảnh hơn nhưng ít vector hơn. Với văn xuôi tiếng Anh, khoảng 128–512 bao phủ gần như mọi trường hợp; Manticore dùng 256 xuyên suốt bài kiểm thử.

overlap_tokens lặp lại phần đuôi của đoạn này ở đầu đoạn kế, để một câu nằm vắt qua ranh giới vẫn xuất hiện nguyên vẹn ở đâu đó. Mức thông thường là 10–20% của max_tokens. Manticore đảm bảo luôn tiến về phía trước: fixed và recursive giới hạn overlap ở nửa kích thước đoạn, còn sentence gieo mầm đoạn kế với tối đa overlap_tokens giá trị của các câu trọn vẹn ở cuối, đồng thời luôn tiến ít nhất một câu.

max_chunks giới hạn tác động của những tài liệu lớn bất thường. Không có nó, một file PDF 400 trang dán vào một dòng sẽ trở thành hàng nghìn nút HNSW.

-- tài liệu ~600 token, chia ở mức 64 token
chunk_strategy='fixed' max_tokens='64'                  -- 22 vector
chunk_strategy='fixed' max_tokens='64' max_chunks='3'   --  3 vector

Hãy dùng nó như rào chắn chống ngoại lệ, không phải cách tiết kiệm bộ nhớ trên diện rộng.

Tìm kiếm trông như thế nào

Không có gì thay đổi ở phía truy vấn so với trước. Không bảng đoạn, không trường lồng nhau, không join, không GROUP BY.

DROP TABLE IF EXISTS notes;
CREATE TABLE notes (
    title text,
    body text,
    chunks float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
        model_name='Xenova/all-MiniLM-L6-v2' from='title,body'
        chunk_strategy='sentence' max_tokens='32'
);

SELECT id, title, knn_dist() FROM notes
WHERE knn(chunks, 3, 'how do I replace an expiring certificate on every node');

Kết quả trả về ba tài liệu, xếp hạng theo khoảng cách tới đoạn gần nhất của mỗi tài liệu. Sáu vector, ba dòng kết quả. Tìm kiếm tuân theo các quy tắc của cơ chế nhiều vector cho mỗi tài liệu:

• Một tài liệu khớp nếu bất kỳ vector nào của nó gần vector truy vấn.
• Manticore trả về mỗi kết quả khớp đúng một lần. knn_dist() là khoảng cách tới đoạn gần nhất.
• Tham số k đếm tài liệu, không đếm vector. knn(chunks, 3, ...) nghĩa là ba tài liệu.
• Tài liệu không có vector sẽ không bao giờ được trả về.

Truy vấn tương tự qua HTTP:

POST /search
{
  "table": "notes",
  "knn": {
    "field": "chunks",
    "query": "how do I replace an expiring certificate on every node",
    "k": 3
  },
  "_source": ["title"]
}

Mọi thứ khác trên trang KNN vẫn hoạt động như trước: lọc dữ liệu, chiến lược prefilter và postfilter, lượng tử hóa, dừng sớm và chấm điểm lại.

Con số thực tế trên tài liệu hướng dẫn Manticore

Manticore thử nghiệm tính năng trên tài liệu hướng dẫn tiếng Anh của chính họ — 189 trang, khoảng 298.000 từ, trải từ ghi chú hai đoạn đến bản changelog 39.000 từ.

Tập truy vấn được tạo tự động, không chọn thủ công. Với mỗi trang, họ lấy các tiêu đề mục, chỉ giữ tiêu đề duy nhất trên toàn bộ tài liệu, rồi chia làm hai nhóm:

• Truy vấn nội dung sâu (419) — tiêu đề xuất hiện sau khoảng 1.200 ký tự đầu của trang. Đây là ranh giới cố ý thận trọng: cửa sổ mô hình là 512 token, tương đương khoảng 2.000 ký tự, nên một vài truy vấn trong nhóm này vẫn trỏ tới văn bản mà truncate nhìn thấy một phần. Khoảng cách bên dưới do đó là đánh giá thấp, không phải phóng đại.
• Truy vấn nội dung đầu trang (88) — tiêu đề nằm trong khoảng 1.200 ký tự đầu. Đây là nhóm đối chứng: nội dung mà truncate đã nhìn thấy được.

Một truy vấn được tính là trúng nếu KNN trả về đúng trang chứa tiêu đề đó trong top k. Mô hình dùng là Xenova/all-MiniLM-L6-v2 (384 chiều, cửa sổ 512 token) chạy trên backend ONNX của Manticore, với 32 luồng.

Nội dung sâu — điều mà chunking hướng tới

Chiến lược	Số vector	Thời gian nạp	RAM chỉ mục	hit@1	hit@5	hit@10	MRR
truncate	189	21 s	4,2 MB	33,7%	55,1%	63,2%	0,44
mean	189	72 s	4,2 MB	43,9%	65,2%	74,7%	0,54
fixed	3.430	73 s	9,5 MB	56,3%	81,1%	86,2%	0,68
recursive	4.664	86 s	11,7 MB	58,7%	83,3%	89,5%	0,70
sentence	4.041	79 s	10,6 MB	55,4%	83,5%	89,0%	0,68

Chia đoạn biến một canh bạc thành một hệ thống tìm kiếm hoạt động được. recall@5 tăng từ 55,1% lên 83,3%, và thứ hạng của câu trả lời đúng cũng cải thiện tương đương — MRR từ 0,44 lên 0,70. Trong số những truy vấn mà truncate hoàn toàn không trả lời được trong top 5, recursive cứu lại được khoảng hai phần ba.

mean nằm đúng ở vị trí bạn kỳ vọng: nó lấy lại khoảng một phần ba khoảng cách mà không tốn thêm chi phí lưu trữ hay tìm kiếm nào.

Nội dung đầu trang — nhóm đối chứng

Chiến lược	hit@1	hit@5	MRR
truncate	65,9%	86,4%	0,74
mean	59,1%	83,0%	0,69
fixed	60,2%	83,0%	0,71
recursive	58,0%	86,4%	0,70
sentence	56,8%	85,2%	0,69

Với nội dung mà mô hình đã nhìn thấy được, truncate vẫn chính xác nhất ở hạng 1 — 65,9% so với 58,0% của recursive. Một vector toàn tài liệu mang theo chủ đề tổng thể của trang, và khi truy vấn nói về chủ đề mở đầu, ngữ cảnh đó có ích.

Nhưng đến hạng 5 thì khác biệt biến mất: recursive khớp chính xác truncate ở mức 86,4%. Vậy cái đánh đổi là vài điểm độ chính xác top-1 trên nội dung gần đầu trang, để lấy +28 điểm recall trên mọi thứ còn lại. Với tìm kiếm tài liệu, trung tâm trợ giúp, hay bất kỳ hệ thống RAG nào đưa 5–10 đoạn cho LLM, đây không phải một lựa chọn khó.

Chi phí

• RAM chỉ mục: 4,2 MB → 11,7 MB, khoảng 2,5×, cho số vector nhiều gấp ~25 lần. Vector chỉ là một phần những gì bảng RT lưu trữ.
• Thời gian nạp dữ liệu: 21 s → 86 s cho 189 tài liệu. Chia đoạn nghĩa là phải embedding toàn bộ corpus thay vì 380 từ đầu của mỗi tài liệu.
• Thời gian phản hồi truy vấn: 6,3 ms → 8,5 ms ở p50. HNSW xử lý 4.664 vector gần như dễ như 189.

Nếu bạn dùng API embedding trả phí, hãy đọc con số thời gian nạp như một hóa đơn: chia đoạn gửi toàn bộ corpus tới mô hình thay vì phần đầu mỗi tài liệu, và bạn trả tiền cho từng token. Mô hình ONNX cục bộ không có chi phí theo token.

Ảnh hưởng của kích thước đoạn tới chất lượng tìm kiếm

Khuyến nghị chọn chiến lược chia đoạn

Dữ liệu của bạn	Bắt đầu với
Tiêu đề, tên, mô tả ngắn, thẻ tag, dòng log	truncate
Dài nhưng đơn chủ đề; hoặc RAM là giới hạn cứng; hoặc cột là float_vector có sẵn	mean
Tài liệu hướng dẫn, wiki, cơ sở tri thức, bài viết, README	recursive, max_tokens 128–256
Ticket hỗ trợ, email, bản ghi, văn bản pháp lý, đánh giá	sentence, max_tokens 128–256
OCR, HTML thu thập, bản ghi máy, dump phi cấu trúc	fixed, max_tokens 256, kèm overlap
Các đoạn sẽ được đưa cho LLM làm ngữ cảnh	sentence, max_tokens 384–512

Overlap cố ý vắng mặt trong hầu hết các khuyến nghị trên: phép thử của Manticore không đo được lợi ích nào từ nó trên văn xuôi có cấu trúc, mà lại tốn thêm vector. Hãy thêm khi một ý thường xuyên vắt qua ranh giới — bản ghi phi cấu trúc, OCR, văn tự sự dài không có ngắt đoạn.

Chia đoạn lớn cỡ nào?

Kích thước đoạn là tham số thực sự ảnh hưởng tới kết quả. Đánh đổi rất trực tiếp: đoạn nhỏ hơn cho kết quả khớp sắc nét hơn với một ý, đoạn lớn hơn mang nhiều ngữ cảnh nhưng pha loãng từng ý bên trong. Một đoạn văn bị chôn trong tài liệu dài chỉ trở nên tìm thấy được khi kích thước đoạn đủ nhỏ để nó có vector riêng.

| max_tokens | overlap