Chiến lược chia khối cho dữ liệu RAG được thu thập từ web
TL;DR
Đối với RAG được thu thập từ web, ranh giới khối nên theo nghĩa và cấu trúc của tài liệu trước khi chúng tuân theo giới hạn ký tự.
Các tiêu đề Markdown hoạt động tốt cho tài liệu; phân tách đệ quy là một lựa chọn thực tiễn cho các đoạn dài; các phương pháp ngữ nghĩa và cha-con cần đánh giá riêng.
Giữ URL nguồn, đường dẫn tiêu đề, phiên bản, và ID ổn định với mỗi khối, và bảo vệ các rào cản mã, bảng, và ngữ cảnh điểm cuối/tham số.
So sánh các chiến lược trên cùng một trang và tập câu hỏi; bản nháp này cung cấp một phương pháp đánh giá, không phải kết quả chuẩn bị giả tạo.
Giới thiệu: Phân khối là một phần của thiết kế truy xuất
Nstdata Crawl là lớp thu thập trong quy trình này; tổng quan sản phẩm của nó mô tả việc truy xuất trang và trang web cho các đường ống dữ liệu hạ nguồn.
Phân khối chia tài liệu nguồn thành các đơn vị có thể được nhúng và truy xuất. Mục tiêu không phải là tạo ra các khối văn bản kích thước bằng nhau. Mục tiêu là làm cho khả năng một đoạn chứa đủ ngữ cảnh để đáp ứng câu hỏi mà không kéo theo tài liệu không liên quan trở nên cao hơn. Một trang web với một tiêu đề, một bảng API, một mẫu mã, và một chân trang không tương đương với một đoạn văn không có cấu trúc.
Một khối RAG tốt duy trì thông tin cần thiết để giải thích đoạn văn: tiêu đề, trang, phiên bản, và thường là câu hoặc khối mã bên cạnh. Một khối kém có thể tách một điểm cuối khỏi các tham số của nó hoặc lặp lại văn bản điều hướng trong mọi kết quả. Phương pháp dưới đây chuẩn bị Markdown sạch trước, sau đó so sánh các lựa chọn phân khối trên cùng một nhiệm vụ truy xuất.
Phân khối trong RAG là gì và tại sao nó quan trọng?
Trình truy xuất tìm kiếm các khối, không phải toàn bộ trang web nguồn. Nếu một khối quá rộng, một câu liên quan cạnh tranh với nội dung không liên quan và tiêu tốn nhiều ngữ cảnh hơn. Nếu một khối quá hẹp, một thuật ngữ được truy xuất có thể bị tách khỏi định nghĩa, điều kiện, hoặc ví dụ của nó. Điều này có thể giảm tính hữu ích của việc truy xuất ngay cả khi trang nguồn đã được ghi lại chính xác.
Phân khối không thể sửa chữa nội dung bị thiếu. Nếu một trình thu thập không ghi lại bảng được render cho khách, không có bộ tách nào sẽ tái tạo nó. Sử dụng Crawl để truy xuất và làm sạch trang, sau đó kiểm tra cấu trúc Markdown trước khi điều chỉnh bộ phân khối. Hướng dẫn ghi tài liệu đầu ra Markdown cho RAG và quy trình agent.
Tại sao nội dung được thu thập từ web cần phân tách dựa trên cấu trúc
Nội dung web bao gồm các tiêu đề và chân trang lặp lại, các tiêu đề lồng nhau, mẫu mã, bảng, liên kết, thông báo, và các đường dẫn có phiên bản. Một bộ tách chỉ có ký tự không biết rằng một rào cản mã là một ví dụ hay rằng tiêu đề “Xác thực” định nghĩa phạm vi của các đoạn văn tiếp theo. Chuẩn hóa các mẫu tiêu chuẩn trước, sau đó bảo vệ cấu trúc trang mang lại ý nghĩa.
Sáu chiến lược phân khối RAG phổ biến
Chiến lược
Ranh giới
Phù hợp tốt
Chi phí hoặc chế độ thất bại
Kích thước cố định
ký tự hoặc token
cơ sở nhanh
tách tiêu đề, ví dụ, và danh sách
Đệ quy
đoạn văn, dòng, câu
văn bản hỗn hợp
thứ tự và chồng chất của bộ phân tách cần điều chỉnh
Ngữ nghĩa
thay đổi nghĩa giữa các câu
văn bản với sự chuyển chủ đề
cần thêm công việc nhúng; nhạy cảm với ngưỡng
Tiêu đề Markdown
các phần H1/H2/H3
tài liệu kỹ thuật và cơ sở kiến thức
đoạn rất dài cần một lần kiểm tra thứ hai
Cha-con
con nhỏ, cha lớn
truy xuất chính xác cộng thêm ngữ cảnh đầy đủ
nhiều ID và logic truy xuất hơn
Ngữ cảnh/hệ thống phân cấp
phần cộng ngữ cảnh tài liệu
các trang bị phân mảnh hoặc tài liệu đa cấp
thêm token và khả năng tiêm ngữ cảnh
Đây là các mẫu thực hiện, không phải xếp hạng. Lựa chọn đúng phụ thuộc vào các câu hỏi hệ thống của bạn phải trả lời và chi phí của việc thiếu ngữ cảnh.
Chuẩn bị Markdown trước khi bạn phân khối nó
Một thứ tự xử lý trước hữu ích là: từ chối các trang trống hoặc thất bại, loại bỏ điều hướng trùng lặp đã sống sót sau khi trích xuất, chuẩn hóa khoảng trắng, bảo vệ thứ bậc tiêu đề, sau đó phân tách. Giữ nguyên các rào cản mã, bảng, liên kết, khối cảnh báo, và cặp phương thức/điểm cuối. Đầu ra hiện tại của Nstdata hỗ trợ Markdown và HTML đã được làm sạch; Markdown là định dạng khởi đầu thực tiễn cho việc truy xuất văn bản, trong khi HTML có thể hữu ích nếu cần phân tích tùy chỉnh.
Tránh bỏ qua một phần chỉ vì nó chứa văn bản ngắn. Một cảnh báo “Đã lỗi thời” ngắn có thể quan trọng hơn một tổng quan dài. Thêm xác thực để phát hiện nội dung trống, các băm nội dung lặp lại, các rào cản mã chưa đóng, và các đoạn rất dài trước khi chúng đến tay nhúng.
Bước từng bước: thực hiện ba chiến lược trong Python
Ví dụ chỉ dùng thư viện chuẩn này cung cấp kích thước cố định, đệ quy, và cơ sở có tiêu đề. Nó nhằm so sánh các ranh giới trên một mẫu tệp Markdown; thêm bộ phân tách sản xuất của bạn và bộ kiểm tra trước khi lập chỉ mục nội dung thực.
import re
deffixed_chunks(text:str, size:int=1200, overlap:int=150):if size <=0ornot0<= overlap < size:raise ValueError("require 0 <= overlap < size") start =0while start <len(text):end =min(start + size,len(text))yield text[start:end]if end ==len(text):break start = end - overlap
defrecursive_chunks(text:str, size:int=1200): parts = re.split(r"\n\n+|(?<=[.!?])\s+", text) chunks, current =[],""for part in parts: candidate =f"{current}\n\n{part}"if current else part
iflen(candidate)> size and current: chunks.append(current) current = part
else: current = candidate
if current: chunks.append(current)return chunks
defheading_chunks(markdown:str): path, lines, fenced =[],[],Falsefor line in markdown.splitlines():if line.strip().startswith("```"): fenced =not fenced
if line.startswith("#")andnot fenced and lines: body ="\n".join(lines).strip()if body:yield" / ".join(path), body
level =len(line)-len(line.lstrip("#")) path = path[:level -1]+[line[level:].strip()] lines =[line]else: lines.append(line)if lines:yield" / ".join(path),"\n".join(lines).strip()
Phiên bản kích thước cố định đo ký tự, không phải mã thông báo mô hình. Phân chia đệ quy sử dụng các ranh giới đoạn và câu nhưng vẫn có thể phân chia một bảng dài. Phân chia tiêu đề giữ lại các khối fenced nhưng có thể phát ra một phần mà vượt quá giới hạn đầu vào của mô hình của bạn. Đây là các cơ sở mà bạn có thể chạy trên một fixture, không phải là các bảo đảm thay thế cho mọi phương ngữ Markdown.
So sánh ranh giới khối trên cùng một tài liệu
Sử dụng một trang đại diện chứa văn xuôi, một bảng nhiều hàng, một khối mã nhiều dòng và ít nhất ba cấp tiêu đề. Đối với mỗi chiến lược, ghi lại số lượng khối, phân bố mã thông báo ước tính và thực tế, số lượng khối mã giữ nguyên, số lượng khối có ngữ cảnh tiêu đề và tỷ lệ trùng lặp. Kiểm tra các số liệu nổi bật thay vì chỉ báo cáo trung bình.
Một bảng so sánh có thể trông như thế này:
Chiến lược
Số lượng khối
Trung vị / tối đa mã thông báo
Khối mã nguyên vẹn
Siêu dữ liệu trích dẫn có mặt
Kích thước cố định
fill from run
fill from tokenizer
manually count
yes/no
Đệ quy
fill from run
fill from tokenizer
manually count
yes/no
Tiêu đề trước
fill from run
fill from tokenizer
manually count
yes/no
Đừng làm đầy bảng này với các số liệu benchmark tự chế. Chạy nó trên tập hợp mục tiêu của bạn và đính kèm phiên bản kịch bản và bộ phân tích mã với kết quả.
Cách chọn kích thước khối và độ chồng chéo
Kích thước khối tương tác với hình dạng truy vấn, giới hạn đầu vào của mô hình nhúng, top-k, tái phân loại và ngữ cảnh phát sinh. Độ chồng chéo có thể giữ lại một câu ranh giới, nhưng nó cũng tạo ra văn bản lặp lại, kết quả tìm kiếm trùng lặp, chi phí nhúng thêm và ít sự đa dạng kết quả hơn. Bắt đầu với các khối biết tiêu đề; thêm một phân tách thứ hai chỉ cho các phần vượt quá giới hạn của mô hình. So sánh một lưới nhỏ về kích thước và độ chồng chéo thay vì sao chép một số “tốt nhất” từ một tập dữ liệu khác.
Các câu hỏi hữu ích bao gồm: “Tiêu đề nào xác thực một cuộc gọi?”, “Tham số nào chấp nhận một danh sách?”, “Phản hồi lỗi có nghĩa là gì?”, và một câu hỏi trải dài qua hai tiêu đề. Theo dõi Recall@K hoặc tỷ lệ đạt được so với bằng chứng được gán nhãn, MRR hoặc hạng, độ chính xác câu trả lời, độ chính xác trích dẫn, và các mã thông báo ngữ cảnh. Giữ cho các thất bại trong việc truy xuất tách biệt với thất bại trong việc sinh ra: một mô hình không thể trích dẫn một đoạn có liên quan mà không bao giờ đạt đến top-k.
Xử lý mã, bảng, Câu hỏi thường gặp và ngữ cảnh phân cấp
Đối với mã, giữ nguyên khối fenced và nhãn ngôn ngữ của nó. Nếu nó quá dài, hãy phân chia tại ranh giới hàm hoặc ví dụ và đính kèm tiêu đề gần nhất cộng với tên tệp hoặc tên ngôn ngữ. Đối với các bảng, lặp lại hàng tiêu đề trong mỗi phân chia và giữ nhãn của một hàng với giá trị của nó. Các mục FAQ thường có thể là một cặp câu hỏi-trả lời trên mỗi khối. Thông số kỹ thuật sản phẩm nên giữ các đơn vị và tên trường được đính kèm vào các giá trị.
Truy xuất cha-con sử dụng một khối con nhỏ cho khớp và truy xuất một phần cha lớn hơn cho việc sinh ra. Lưu trữ parent_id, child_id, source_url, và heading_path. Phân khúc ngữ cảnh có thể thêm tiêu đề tài liệu hoặc đường dẫn phần vào văn bản trước khi nhúng, nhưng hãy kiểm tra xem ngữ cảnh thêm đó có thiên lệch sự tương đồng hay trùng lặp một tiêu đề chung trên nhiều trang hay không.
Xây dựng bộ câu hỏi đánh giá RAG
Tạo câu hỏi từ các vé hỗ trợ thực tế và nhiệm vụ của nhà phát triển, sau đó gán nhãn đoạn nguồn chính xác trả lời từng câu. Bao gồm các sự thật trực tiếp, tra cứu bảng, câu hỏi mã, câu hỏi theo phiên bản, câu hỏi giao nhau và câu hỏi không thể trả lời. Để một người xem xét xác minh câu trả lời và bằng chứng của nó thay vì coi nhãn của một LLM khác như sự thật không thể chối cãi.
Đo lường chất lượng lấy lại và câu trả lời một cách riêng biệt. Đối với việc lấy lại, ghi lại xem một khối được gán có xuất hiện trong top-k và ở thứ hạng nào. Đối với việc tạo ra, ghi lại tính chính xác, tính chính xác của liên kết nguồn, các tuyên bố không được hỗ trợ và xem hệ thống có từ chối khi trang không trả lời câu hỏi hay không. Lặp lại thí nghiệm sau khi cập nhật tài liệu để các sự suy giảm độ mới có thể được nhìn thấy.
Những sai lầm chung trong việc phân khúc
Cửa sổ cố định mù quáng: các tiêu đề và ví dụ có ý nghĩa bị tách ra mà không có siêu dữ liệu.
Quá nhiều chồng chéo: các khối gần giống chiếm ưu thế trong top-k và tốn nhiều chi phí hơn để nhúng.
Mất đường dẫn tiêu đề: một định nghĩa xuất hiện mà không có sản phẩm hoặc API mà nó miêu tả.
Code hoặc bảng bị cắt ngắn: kết quả lấy lại không còn đại diện cho những hướng dẫn hợp lệ.
Các phiên bản hỗn hợp: hướng dẫn API v1 và v2 được nhúng mà không có trường phiên bản có thể lọc được.
Không có bộ đánh giá: một khối được chọn chỉ dựa vào ngoại hình chứ không phải hiệu suất lấy lại.
Chọn theo trường hợp sử dụng
Đối với tài liệu dành cho nhà phát triển, bắt đầu với các tiêu đề Markdown và chia nhỏ các phần dài một cách đệ quy. Đối với các câu hỏi thường gặp, giữ nguyên cặp câu hỏi-trả lời. Đối với kiến thức sản phẩm, bảo tồn các hàng thuộc tính-giá trị và siêu dữ liệu phiên bản/trạng thái. Đối với các báo cáo dài, thử sử dụng việc lấy lại cha-con hoặc phân đoạn ngữ nghĩa nếu tập câu hỏi vượt qua các phần. Đối với tin tức, giữ ngày tháng và nhà xuất bản của mỗi mục kèm theo và xem xét các hồ sơ ngắn hạn. So sánh từng mục với cùng một tập câu hỏi được gán nhãn. Đối với chi tiết triển khai, xem các khái niệm phân tách LangChain, hướng dẫn nhúng OpenAI, và hướng dẫn tìm kiếm ngữ nghĩa Pinecone. Những nguồn tài liệu này ghi lại APIs và mẫu; chúng không xác định chiến lược nào có lợi hơn trên tập dữ liệu của bạn.
Danh sách kiểm tra cuối cùng
Làm sạch và xác nhận nội dung nguồn trước khi phân khúc.
Bảo tồn đường dẫn tiêu đề, URL nguồn, phiên bản, ngôn ngữ, và thời gian cập nhật.
Giữ nguyên các khối mã, bảng và định nghĩa trường được kết nối chặt chẽ.
Sử dụng một lượt phân tách thứ hai chỉ khi giới hạn đầu vào của mô hình yêu cầu.
Kiểm tra chất lượng lấy lại và câu trả lời trên cùng một câu hỏi cố định.
Ghi lại chi phí token và vector thực tế cho các tham số đã chọn.
Không có “chiến lược phân khúc tốt nhất cho RAG” nào là phổ quát. Đối với tài liệu được thu thập từ web, phân tách theo cấu trúc là một chuẩn mực hữu ích vì trang đã có tiêu đề và ranh giới mã. Các chiến lược đệ quy hoặc ngữ nghĩa có thể cải thiện các tập dữ liệu cụ thể, nhưng chỉ một bộ đánh giá mới cho thấy liệu chúng có giúp ích cho các câu hỏi của người dùng của bạn hay không. Giữ cho việc so sánh có thể tái tạo và ghi lại cả chất lượng lấy lại và chi phí hoạt động.
Chiến lược tốt nhất là chiến lược mà lấy lại được chứng cứ đầy đủ cho các truy vấn thực tế của bạn với chi phí token và lưu trữ chấp nhận được; phân tách nhạy cảm với tiêu đề là một tiêu chuẩn thực tiễn cho tài liệu web được cấu trúc.
Q: Kích thước khối lý tưởng là gì?
Không có kích thước lý tưởng phổ quát; đánh giá các kích thước dựa trên giới hạn đầu vào của mô hình nhúng, ngữ cảnh câu trả lời, và các câu hỏi lấy lại được gán nhãn.
Q: Chồng chéo của khối có cải thiện việc lấy lại không?
Chồng chéo có thể bảo tồn ngữ cảnh gần ranh giới, nhưng quá nhiều chồng chéo tạo ra kết quả trùng lặp và chi phí lập chỉ mục thêm, vì vậy hãy thử nghiệm trong một khoảng nhỏ.
Q: Phân khúc ngữ nghĩa là gì?
Phân khúc ngữ nghĩa sử dụng sự thay đổi về ý nghĩa hoặc sự tương đồng giữa các đoạn văn để đề xuất ranh giới, điều này có thể giúp văn xuôi nhưng cũng đưa ra các lựa chọn mô hình và ngưỡng.
Q: Tôi nên phân khúc Markdown cho RAG như thế nào?
Bắt đầu với các phần tiêu đề, mang theo đường dẫn tiêu đề như siêu dữ liệu, bảo tồn mã có khối và tiêu đề bảng, và chỉ phân tách đệ quy các phần dài.
Hiểu bảy chiều kích của chất lượng dữ liệu RAG và cách xác thực các trang web đã được thu thập, so sánh các đầu vào sạch và thô, bảo tồn nguồn gốc và chẩn đoán các thất bại trong việc truy xuất. Nó tách biệt các lỗi trích xuất, truy xuất và tạo ra để các nhóm có thể gỡ lỗi giai đoạn đúng.
Lena Zhou
Oct. 20th 2026
Thu thập toàn bộ trang web chỉ với một yêu cầu API
Tỷ lệ thành công 99,8% với kết xuất JavaScript
Nhận dữ liệu sạch, sẵn sàng cho LLM ở nhiều định dạng
Chuyển mọi trang web thành Markdown, HTML, JSON, liên kết, PDF và hơn thế nữa mà không cần quản lý hạ tầng thu thập dữ liệu.
