Phân đoạn ngữ nghĩa cho RAG: Xây dựng một đường ống dữ liệu web
Advanced Data Extraction Specialist
TL;DR:
- Phân đoạn ngữ nghĩa nhóm văn bản bằng cách sử dụng sự thay đổi trong ý nghĩa. Nó cần một phương thức phân đoạn xác định, một mô hình nhúng, và một quy tắc để quyết định nơi mà một đoạn kết thúc.
- Văn bản nguồn sạch là một phần của chất lượng truy xuất. Các menu điều hướng và biểu ngữ lặp lại có thể bóp méo các đoạn trước khi bộ truy xuất nhìn thấy chúng.
- Mỗi đoạn nên giữ lại nguồn gốc và vị trí của nó. Nguồn gốc làm cho một đoạn văn được truy xuất hữu ích cho việc trích dẫn và chẩn đoán.
- Một bộ phân ngữ nghĩa cần một phép so sánh cơ sở. Công việc nhúng thêm không đảm bảo câu trả lời tốt hơn so với một chiến lược phân đoạn đơn giản hơn.
- Tự do để bắt đầu. Sử dụng tín dụng tài khoản Scrapeless để đánh giá bước thu thập upstream trên một tập tài liệu nhỏ được phê duyệt.
Giới thiệu: Truy xuất Bắt đầu Trước Kho Vector
Một bộ truy xuất chỉ có thể trả về các đoạn đã được lưu trữ trong chỉ mục của nó. Trong sinh ra dựa trên truy xuất, chứng cứ được truy xuất là một phần của đầu vào sinh ra. Nếu một đoạn chứa một nửa lời giải thích, hoặc kết hợp một tuyên bố chính trị với văn bản điều hướng không liên quan, thì trình tạo câu trả lời nhận được một ngữ cảnh không đầy đủ ngay cả khi điểm số tương đồng trông mạnh.
Phân đoạn ngữ nghĩa thay đổi nơi mà các đoạn đó bắt đầu và kết thúc. Thay vì chỉ cắt ở một độ dài cố định, bộ phân so sánh các đại diện câu gần kề và tạo ra một ranh giới khi ý nghĩa của chúng khác biệt đủ. Một giới hạn kích thước vẫn quan trọng vì một chủ đề liên kết có thể dài hơn những gì mô hình hạ lưu có thể chấp nhận.
Bài viết này mô tả một pipeline web-to-RAG với Scrapeless như lớp thu thập và một bộ phân Python minh bạch như lớp biến đổi. Nó bổ sung cho sự trích xuất có cấu trúc với một mô hình ngôn ngữ: trích xuất tạo ra các trường tác vụ, trong khi phân đoạn chuẩn bị các đoạn để truy xuất sau này.
Phân Đoạn Ngữ Nghĩa Làm Gì
Phân đoạn ngữ nghĩa sử dụng một đại diện của ý nghĩa để chọn ranh giới văn bản. Một thực hiện phổ biến chia một tài liệu thành các câu, nhúng các câu đó, so sánh các vector liền kề, và bắt đầu một nhóm mới tại một sự thay đổi đủ lớn.
Phương pháp nhúng câu ánh xạ văn bản câu thành các vector có thể được so sánh về độ tương đồng. Ý nghĩa của một điểm số tương đồng phụ thuộc vào mô hình và đầu vào, vì vậy việc thiết lập ranh giới số là một tham số để đánh giá hơn là một định nghĩa chung về sự thay đổi chủ đề.
| Chiến lược | Quy tắc ranh giới | Điểm khởi đầu hữu ích | Thoả hiệp chính |
|---|---|---|---|
| Kích thước cố định | Một độ dài được cấu hình | Một cơ sở đơn giản | Có thể cắt qua một lời giải thích |
| Nhận thức cấu trúc | Tiêu đề và ngắt đoạn | Các trang tham khảo có tổ chức | Phụ thuộc vào cấu trúc tài liệu sạch |
| Ngữ nghĩa | Sự thay đổi trong độ tương đồng nhúng | Văn bản có chuyển chủ đề | Thêm tính toán và tinh chỉnh mô hình |
| Lai ghép | Cấu trúc, kiểm tra ngữ nghĩa, và giới hạn | Tập hợp tài liệu hỗn hợp | Nhiều cấu hình hơn để đánh giá |
Tiêu đề, bảng, khối mã, và danh sách cần sự xử lý đặc biệt. Một bộ phân câu có thể làm hỏng một bảng bằng cách tách một giá trị khỏi nhãn cột của nó. Bảo tồn các đơn vị này trong quá trình tiền xử lý hoặc chuyển hướng chúng đến một con đường nhận thức cấu trúc.
Pipeline Tổng Quan
Pipeline chuyển đổi một tài liệu web được chụp thành các đoạn được lập chỉ mục giữ nguyên nguồn gốc của chúng. Các giai đoạn của nó là thu thập → tiêu chuẩn hóa văn bản → phân đoạn câu → nhúng → hình thành đoạn → đánh giá truy xuất.
Scrapeless Web Unlocker xử lý yêu cầu mục tiêu. Ứng dụng của bạn làm sạch nội dung trả về, tạo ra nhúng thông qua một mô hình đã chọn, và lưu trữ các đoạn kết quả. Việc thu thập web không tự tạo ra một chỉ mục vector hoặc chọn chiến lược phân đoạn chính xác.
Lưu phản hồi gốc trước khi biến đổi. Giữ nguyên URL đã yêu cầu, bất kỳ URL chính thức nào đã thiết lập, thời gian thu thập, tiêu đề trang, và một băm của văn bản đã chuẩn hóa. Một URL chính thức phải đến từ bằng chứng nguồn; không tạo ra nó bằng cách xóa các đoạn đường dẫn.
Điều Kiện Tiên Quyết
Bạn cần một bộ trang nguồn công khai đã được phê duyệt, một khóa API Scrapeless để thu thập, Python để xử lý, và một mô hình nhúng mà bạn có thể chạy cục bộ hoặc thông qua nhà cung cấp đã chọn của bạn. Nhà cung cấp hoặc mô hình xác định thiết lập nhúng và yêu cầu truy cập.
Bộ phân tại hướng dẫn này tiêu thụ một sentences.json file với một source_url chuỗi, một sentences danh sách tuần tự, và một danh sách embeddings chứa một vector số cho mỗi câu. Nó không giả định một mô hình cụ thể được lưu trữ hoặc kích thước vector. Mô hình giống nhau phải được sử dụng cho mỗi câu trong một lần chạy.
Việc thu thập trang đã xác thực và tạo ra nhúng là những điều kiện tiên quyết chưa được thực hiện từ đầu đến cuối cho ví dụ này. Bảng phân chia có thể được kiểm tra độc lập, nhưng kiểm tra thuật toán cục bộ không xác lập chất lượng truy xuất hoặc tích hợp mô hình thành công.
Giai đoạn 1: Thu thập và Làm sạch Tài liệu Nguồn
Một tài liệu hữu ích bắt đầu với nội dung trang dự định thay vì trang thách thức, biểu mẫu đăng nhập hoặc khung điều hướng. Thu thập trang thông qua giao diện yêu cầu Web Unlocker và xác minh rằng nội dung mong đợi của nó có mặt trước khi trích xuất văn bản.
Đối với mỗi trang được chấp nhận, hãy xóa các script, kiểu dáng, điều hướng lặp lại và các khối quảng cáo không liên quan. Bảo tồn tiêu đề và ranh giới đoạn văn. Nếu trang được hiển thị một cách động, hãy sử dụng cấu hình hiển thị được tài liệu và kiểm tra rằng nội dung trả về bao gồm văn bản liên quan.
Lưu trữ nội dung thô và đã chuẩn hóa riêng biệt. Điều đó làm cho việc chẩn đoán liệu một đoạn trích được lấy kém có nguồn gốc từ thu thập, dọn dẹp, phân đoạn hay mô hình nhúng trở nên khả thi. mối quan hệ nguồn gốc giữa dữ liệu nguồn và dữ liệu thu được là hữu ích ở đây: đoạn được lấy từ một phiên bản cụ thể của tài liệu đã chuẩn hóa.
Đừng kết hợp im lặng nội dung của một trang với tiêu đề hoặc ngày xuất bản từ trang khác. Nếu một trường không có sẵn, hãy giữ nó không được đặt. Thời gian thu thập trang và thời gian xuất bản nguồn là các trường siêu dữ liệu khác nhau.
Giai đoạn 2: Phân đoạn Câu và Tạo ra Nhúng Nhất quán
Phân đoạn câu tạo ra các đơn vị văn bản có thứ tự mà bộ phân chia ngữ nghĩa sẽ so sánh. Sử dụng một bộ phân đoạn phù hợp với ngôn ngữ và kiểm tra cách thức xử lý của nó đối với các từ viết tắt, số thập phân, tiêu đề và danh sách có dấu đầu dòng trên các tài liệu mẫu của bạn.
Tránh tuyên bố rằng phân chia cơ bản thành dấu chấm hoạt động cho mọi trang. Một đoạn văn chứa một từ viết tắt hoặc một ví dụ mã có thể bị phân tách thành các mảnh gây hiểu lầm. Đối với các trang tham khảo ngắn, ranh giới tiêu đề và đoạn văn có thể đã cung cấp cấu trúc đủ mà không cần một lần chạy ngữ nghĩa.
Tạo một nhúng cho mỗi câu và bảo tồn thứ tự chính xác. Ghi lại định danh mô hình, cài đặt chuẩn hóa và băm văn bản nguồn cùng với các vector. Từ chối các vector thiếu, kích thước không đồng nhất hoặc các giá trị không hữu hạn trước khi tính toán sự tương đồng.
Một cửa sổ ngữ cảnh ở cấp độ đoạn văn có thể cải thiện một số biểu diễn câu, nhưng nó làm thay đổi thí nghiệm. Giữ cài đặt đó cố định khi so sánh các quy tắc phân chia để thay đổi đầu vào nhúng không được quy cho thuật toán ranh giới.
Bắt đầu Thu thập Dữ liệu với Scrapeless
Khởi động quy trình làm việc thu thập dữ liệu và tự động hóa web của bạn với Scrapeless!
Đăng ký ngay hôm nay và nhận 5 đô la tín dụng miễn phí — không cần thẻ tín dụng.Nhận tín dụng miễn phí của bạn ngay bây giờ trong Bảng điều khiển Scrapeless.
Giai đoạn 3: Tạo các Khối Ngữ nghĩa Giới hạn
Bảng phân chia bên dưới bắt đầu một khối mới khi độ tương đồng giữa các câu liền kề giảm xuống dưới ngưỡng đã cấu hình hoặc ngân sách ký tự sẽ bị vượt quá. Lưu nó dưới dạng chunk_sentences.py.
Lưu ý: Kịch bản này yêu cầu một tệp
sentences.jsonthực sự được tạo ra từ văn bản đã thu thập và mô hình nhúng của bạn. Việc tạo ra nhúng vẫn là điều kiện tiên quyết; ví dụ này không bao gồm một tập vector giả tạo hoặc tuyên bố cải thiện truy xuất đã đo lường.
python
import json
import math
import os
from pathlib import Path
source = json.loads(Path("sentences.json").read_text())
sentences = source["sentences"]
vectors = source["embeddings"]
threshold = float(os.environ["SIMILARITY_THRESHOLD"])
max_chars = int(os.environ["MAX_CHUNK_CHARS"])
if not -1 <= threshold <= 1 or max_chars <= 0:
raise ValueError("Invalid chunking configuration")
if not sentences or len(sentences) != len(vectors):
raise ValueError("Each sentence needs one embedding")
dimension = len(vectors[0])
if not dimension:
raise ValueError("Embeddings must not be empty")
for text, vector in zip(sentences, vectors):
if not isinstance(text, str) or not text.strip():
raise ValueError("Sentence text must be nonempty")
if len(text) > max_chars:
raise ValueError("Segment oversized sentences before chunking")
if len(vector) != dimension or not all(math.isfinite(v) for v in vector):
raise ValueError("Invalid embedding dimension or value")
if sum(v * v for v in vector) == 0:
raise ValueError("A zero vector has no cosine direction")
def cosine(a, b):
numerator = sum(x * y for x, y in zip(a, b))
denominator = math.sqrt(sum(x*x for x in a) * sum(y*y for y in b))
return max(-1.0, min(1.0, numerator / denominator))
chunks, start, current = [], 0, []
for index, sentence in enumerate(sentences):
topic_change = index > 0 and cosine(vectors[index-1], vectors[index]) < threshold
too_long = len(" ".join(current + [sentence])) > max_chars
if current and (topic_change or too_long):
chunks.append({"start_sentence": start, "end_sentence": index,
"text": " ".join(current)})
current, start = [], index
current.append(sentence)
chunks.append({"start_sentence": start, "end_sentence": len(sentences),
"text": " ".join(current)})
records = [dict(chunk, source_url=source["source_url"], chunk_index=index)
for index, chunk in enumerate(chunks)]
Path("chunks.json").write_text(json.dumps(records, ensure_ascii=False, indent=2))
print(json.dumps({"chunk_count": len(records)}))
Khoảng thời gian câu sử dụng một khởi đầu bao gồm và kết thúc không bao gồm. Quy ước đó cho phép tái tạo chính xác các câu đầu vào nào đã sản xuất ra một khối. Các đầu vào trống và vector không hợp lệ sẽ thất bại một cách rõ ràng thay vì tạo ra một chỉ mục trống có vẻ thành công.
Giới hạn kích thước ở đây đếm ký tự. Đó không phải là giới hạn ký tự. Nếu hệ thống nhúng hoặc tạo của bạn có ngân sách ký tự, hãy đo ký tự với bộ phân tích cú pháp của hệ thống đó trước khi gửi văn bản. Mã sẽ từ chối một câu có kích thước lớn để bộ phân đoạn phía trên có thể xử lý một cách cẩn thận.
Việc triển khai này cố ý đơn giản: nó so sánh các vector câu kề nhau. Nó không thực hiện phân cụm qua các phần xa của một tài liệu, ngưỡng phần trăm thích ứng hoặc một bộ phân loại ranh giới đã được đào tạo. Những phương pháp đó là những phương pháp riêng biệt cần có đánh giá riêng.
Giai đoạn 4: Lập chỉ mục Các Đoạn mà Không Làm Mất Nguồn Của Chúng
Lập chỉ mục nên bảo tồn đủ siêu dữ liệu để kết nối một khối đã truy xuất với tài liệu nguồn của nó. Lưu trữ văn bản khối, URL nguồn, băm văn bản, chỉ mục khối, khoảng câu, thời gian thu thập, và định danh mô hình nhúng.
Tạo vector embedding từ văn bản cuối cùng nếu đó là đại diện mà trình truy xuất của bạn sử dụng. Trung bình các embedding câu là một lựa chọn thiết kế khác; đừng giả định rằng nó tạo ra thứ hạng truy xuất giống như việc nhúng đoạn văn được lắp ráp.
Khi một tài liệu nguồn thay đổi, hãy giữ phiên bản cũ và mới có thể phân biệt được. Việc tái sử dụng cùng một mã định danh đoạn trong khi thay đổi văn bản cơ sở có thể khiến các trích dẫn đã lưu trở nên không rõ ràng. Một khóa phiên bản dựa trên băm nguồn chuẩn hóa giúp tách biệt các quan sát.
Một kho vector chỉ là một chỉ mục có thể có. Một đánh giá nhỏ có thể truy xuất các đoạn trong bộ nhớ. Bắt đầu bằng cách sắp xếp đơn giản nhất cho phép bạn kiểm tra văn bản trả về cho mỗi câu hỏi.
Giai đoạn 5: So sánh Truy xuất, Không chỉ Hình thức Đoạn
Phân đoạn ngữ nghĩa nên được đánh giá dựa trên các câu hỏi mà ứng dụng cần trả lời. Một tập hợp đoạn văn sạch sẽ về mặt hình thức không chứng minh rằng trình truy xuất sẽ trả về bằng chứng đúng.
Xây dựng một tập câu hỏi nhỏ với các đoạn hỗ trợ được đánh dấu trong các tài liệu gốc. Chạy một cơ sở hạ tầng cố định, một cơ sở hạ tầng nhận thức cấu trúc, và bộ chia ngữ nghĩa chống lại cùng một nội dung đã được chuẩn hóa. Giữ cho mô hình nhúng, cài đặt truy xuất và đánh giá câu trả lời không thay đổi.
| Đo lường | Câu hỏi mà nó trả lời |
|---|---|
| Truy xuất đoạn hỗ trợ | Bằng chứng cần thiết có được truy xuất không? |
| Văn bản không liên quan đã được truy xuất | Bao nhiêu bối cảnh đã bị lãng phí? |
| Hỗ trợ trả lời | Câu trả lời được tạo ra có theo bằng chứng không? |
| Thời gian xử lý | Chi phí của việc phân đoạn và nhúng về mặt hoạt động là gì? |
| Khối lượng đầu vào | Bao nhiêu văn bản đã đến từng bước mô hình? |
Nghiên cứu về các yếu tố tranh thủ tính toán trong phân đoạn ngữ nghĩa hỗ trợ việc coi phương pháp như một lựa chọn thực nghiệm. Công việc thêm vào không nhất quán tạo ra sự cải thiện trên mọi tác vụ và bộ dữ liệu.
Kiểm tra các thất bại theo từng giai đoạn. Bằng chứng thiếu trong việc thu thập thô là một vấn đề về việc thu nhận. Các đoạn văn bị hỏng là một vấn đề dọn dẹp. Một đoạn văn liên quan được xếp hạng thấp hơn các đoạn không liên quan có thể chỉ ra cấu hình nhúng hoặc truy xuất. Những vấn đề này yêu cầu các thay đổi khác nhau.
Theo dõi thành phần thu nhận một cách riêng biệt qua Giá cả Scrapeless. Chi phí nhúng và lập chỉ mục thuộc về ngăn xếp đầu ra; chúng không nên được báo cáo như việc sử dụng Web Unlocker.
Kết luận: Chọn Bộ chia mà Truy xuất Bằng chứng Tốt hơn
Phân đoạn ngữ nghĩa hữu ích khi ý nghĩa thay đổi bên trong các tài liệu theo cách mà các ranh giới đơn giản không thể nắm bắt. Quy trình làm việc thực tế là bảo tồn văn bản nguồn sạch sẽ, sản xuất các embedding nhất quán, thi hành giới hạn đoạn, và so sánh truy xuất với các lựa chọn đơn giản hơn.
Giữ cho siêu dữ liệu nguồn được gắn liền suốt quá trình. Một đoạn đã truy xuất trở nên hữu ích hơn rất nhiều khi ứng dụng có thể chỉ ra nguồn gốc của nó và phiên bản tài liệu mà nó đại diện.
Sẵn sàng để Xây dựng Pipeline Dữ liệu Web của Bạn?
Tham gia các nhà phát triển đang làm việc trong việc thu thập dữ liệu web trên Discord và Telegram.
Tạo một tài khoản Scrapeless và điều chỉnh quy trình làm việc cho các nguồn dữ liệu đã được phê duyệt của bạn.
Câu Hỏi Thường Gặp
H: Phân đoạn ngữ nghĩa có tốt hơn phân đoạn cố định không?
Không. Lợi ích của nó phụ thuộc vào các tài liệu, mô hình nhúng, cài đặt truy xuất và nhiệm vụ. So sánh các chiến lược trên một tập đánh giá chung trước khi chọn một.
H: Scrapeless có tạo ra các embedding trong quy trình làm việc này không?
Không. Scrapeless cung cấp bước truy cập web đầu nguồn. Mô hình nhúng và chỉ mục bạn đã chọn xử lý đại diện và truy xuất ở hạ nguồn.
H: Các bảng và khối mã nên được phân đoạn như thế nào?
Giữ nguyên cấu trúc của chúng hoặc điều hướng chúng qua một bộ chia nhận thức cấu trúc chuyên dụng. Ranh giới câu một mình có thể tách rời giá trị từ tiêu đề hoặc phá vỡ bối cảnh mã.
H: Thì sao nếu một trang thu được chứa một thách thức hoặc HTML khác nhau?
Từ chối nội dung không đáp ứng hợp đồng nguồn và kiểm tra giai đoạn thu thập hoặc phân tích. Sự tương đồng ngữ nghĩa không thể sửa chữa một tài liệu nguồn không đúng.
H: Việc thu thập có cần một proxy riêng không?
Sử dụng các tùy chọn định tuyến của yêu cầu Web Unlocker mà bạn đã chọn. Đừng suy luận yêu cầu proxy từ thuật toán phân đoạn, mà chạy sau khi thu thập.
H: Liệu pipeline có thể chạy mà không cần một đại lý AI không?
Có. Một ứng dụng có thể thu thập tài liệu và thực hiện phân đoạn dựa trên nhúng mà không cần một đại lý tự động. Mô hình nhúng vẫn được yêu cầu cho việc so sánh ngữ nghĩa.
H: Những giới hạn nào nên áp dụng cho việc thu thập nguồn song song?
Bắt đầu với bộ sưu tập giới hạn, chẳng hạn như không nhiều hơn ba công nhân mỗi máy chủ, và tuân thủ các giới hạn mục tiêu và tài khoản nghiêm ngặt hơn. Các lô nhúng có giới hạn riêng theo từng mô hình.
Q: Có thể thêm bất kỳ trang công khai nào vào chỉ mục RAG không?
Chỉ có sự khả dụng công khai không đủ để thiết lập quyền cho mọi bộ sưu tập hoặc tái sử dụng. Xem xét các điều khoản nguồn, quyền áp dụng, và cách xử lý dữ liệu dự kiến trước khi tiếp nhận.
Tại Scrapless, chúng tôi chỉ truy cập dữ liệu có sẵn công khai trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách bảo mật trang web hiện hành. Nội dung trong blog này chỉ nhằm mục đích trình diễn và không liên quan đến bất kỳ hoạt động bất hợp pháp hoặc vi phạm nào. Chúng tôi không đảm bảo và từ chối mọi trách nhiệm đối với việc sử dụng thông tin từ blog này hoặc các liên kết của bên thứ ba. Trước khi tham gia vào bất kỳ hoạt động cạo nào, hãy tham khảo ý kiến cố vấn pháp lý của bạn và xem xét các điều khoản dịch vụ của trang web mục tiêu hoặc có được các quyền cần thiết.



