Tokenizer là gì?

Scrapeless Agent Browser cung cấp khả năng truy cập web cho các quy trình xử lý văn bản phía sau.

Tokenizer là một thành phần chuyển đổi văn bản đầu vào thành các đơn vị mà mô hình có thể xử lý, thường là token được biểu diễn bằng các mã định danh số. Quá trình giải mã tương ứng chuyển các chuỗi token trở lại thành văn bản. Việc token hóa xác định ranh giới biểu diễn giữa nội dung có thể đọc được và từ vựng của mô hình; bản thân nó không hiểu một phát biểu là đúng hay sai.

Đối với nhà phát triển, tokenizer quan trọng khi ước tính kích thước ngữ cảnh, chuẩn bị ví dụ huấn luyện và xử lý đúng đầu vào mô hình. Cùng một đoạn văn bản có thể tạo ra các chuỗi token khác nhau với các tokenizer khác nhau. Hãy dùng tokenizer đi kèm với mô hình thay vì giả định bộ đếm từ hoặc mã hóa của một mô hình khác là tương đương.

Cách văn bản trở thành Token ID

Một tokenizer thường áp dụng một chuỗi thao tác có thể bao gồm chuẩn hóa, tách ban đầu, phân đoạn và ánh xạ các đoạn sang các mã định danh trong từ vựng. Chi tiết khác nhau tùy thiết kế. Một số hệ thống cũng chèn token đặc biệt hoặc định dạng thông điệp bằng một mẫu trước khi mô hình xử lý chúng.

Một mã định danh token chỉ có ý nghĩa trong phạm vi từ vựng của nó. Mã định danh từ một tokenizer không nên được chuyển sang một mô hình khác như thể nó biểu diễn cùng một văn bản. Nội dung từ vựng và các quy tắc xử lý là một phần của giao diện mô hình. Hãy giữ cấu hình tokenizer gắn với phiên bản mô hình trong ứng dụng và hồ sơ chuẩn bị dữ liệu của bạn.

Đối với một bộ phân loại tài liệu giả định, đoạn văn có thể đọc được là đầu vào nguồn và token ID là biểu diễn đã mã hóa của nó. Nếu tiền xử lý vô tình xóa bỏ một phủ định trước khi token hóa, tokenizer vẫn có thể mã hóa chính xác câu sai. Hãy kiểm tra toàn bộ chuỗi xử lý văn bản thay vì đổ mọi lỗi biểu diễn cho từ vựng.

Vì sao đơn vị dưới từ lại phổ biến

Subword tokenization biểu diễn văn bản bằng các đơn vị nhỏ hơn cả từ đầy đủ khi cần thiết. Điều này cho phép một từ vựng diễn đạt các thuật ngữ lạ thông qua việc kết hợp các mảnh đã biết. Các từ phổ biến vẫn có thể được biểu diễn gọn, trong khi các từ ít gặp có thể bị tách thành nhiều đơn vị. Do đó, một token không phải là từ đồng nghĩa đáng tin cậy với một từ.

The cách tiếp cận subword đối với biểu diễn từ hiếm đã giới thiệu một cách thực tế để giải quyết dịch với từ vựng mở bằng các đơn vị nhỏ hơn. Ý tưởng cốt lõi giúp giải thích vì sao mã sản phẩm, tên ít gặp và các từ ghép kỹ thuật có thể có chi phí token khác với văn xuôi quen thuộc có độ dài hiển thị tương tự.

Đừng suy ra ranh giới ngữ nghĩa từ ranh giới token. Một đoạn có thể là một phần của một từ có nghĩa mà bản thân nó không có nghĩa. Khi hiển thị thực thể trích xuất hoặc áp dụng giới hạn độ dài trường, hãy dùng văn bản gốc và yêu cầu của tác vụ. Ranh giới token hữu ích cho biểu diễn và tính toán ngân sách mô hình, nhưng chúng không thay thế việc kiểm tra nội dung dựa trên hiểu biết ngôn ngữ.

Byte Pair Encoding và phân đoạn Unigram

Byte pair encoding xây dựng một lược đồ phân đoạn thông qua các phép gộp đã học của các đơn vị liền kề xuất hiện thường xuyên. Biểu diễn khởi đầu và cách triển khai cụ thể có thể khác nhau. Khi mã hóa, các quy tắc đã học quyết định cách văn bản được chia thành các mục trong từ vựng. Các mảnh thu được phản ánh quá trình huấn luyện và cấu hình tokenizer.

Phân đoạn unigram sử dụng một cách tiếp cận khác để chọn các đơn vị subword. Nghiên cứu về subword regularization và multiple segmentations xem xét cách các phân đoạn thay thế có thể được dùng trong quá trình huấn luyện. Điều này khác với việc lấy mẫu token đầu ra tiếp theo của một LLM, nên việc lấy mẫu của tokenizer và nhiệt độ sinh không nên được mô tả như cùng một cơ chế điều khiển.

The SentencePiece tokenizer and detokenizer trình diễn xử lý subword trực tiếp từ câu thô mà không cần phân đoạn từ trước. Đối với thiết kế ứng dụng, hãy tập trung vào tokenizer cụ thể được phát hành kèm với mô hình bạn chọn. Chỉ riêng họ thuật toán không cho bạn biết mọi quy tắc chuẩn hóa, token đặc biệt hay yêu cầu về định dạng thông điệp.

Chuẩn hóa có thể thay đổi biểu diễn

Chuẩn hóa là bước tiền xử lý chuyển đổi đầu vào sang một dạng được chọn trước khi phân đoạn. Tùy tokenizer, nó có thể ảnh hưởng đến chữ hoa/thường, dạng ký tự, hoặc khoảng trắng. Những lựa chọn đó ảnh hưởng đến việc các phân biệt nào vẫn còn sẵn cho mô hình. Hãy kiểm tra cấu hình thực tế thay vì giả định mọi tokenizer đều giữ lại mọi byte đầu vào.

Điều này quan trọng với các tác vụ khớp chính xác. Mã sản phẩm, biểu thức toán học hoặc đoạn mã nguồn có thể chứa các ký tự mà khác biệt của chúng là có ý nghĩa. Nếu ứng dụng của bạn yêu cầu bảo toàn chính xác, hãy thử các ví dụ tiêu biểu qua mã hóa và giải mã rồi so sánh kết quả với văn bản gốc. Giữ các biến đổi đặc thù của tác vụ tách biệt với hành vi của tokenizer để nguồn gốc của mọi thay đổi đều rõ ràng.

Đối với văn bản web, bước trích xuất giới thiệu thêm một ranh giới khác. Loại bỏ markup, nối các ô bảng hoặc gộp khoảng trắng có thể làm thay đổi ý nghĩa trước khi tokenizer chạy. The web data acquisition workflow liên quan đến việc thu thập nội dung hữu ích; ứng dụng của bạn phải giữ lại cấu trúc cần thiết cho tác vụ phía sau trong quá trình chuẩn bị văn bản.

Token đặc biệt và mẫu thông điệp

Token đặc biệt có thể đánh dấu ranh giới hoặc thông tin điều khiển đặc thù mô hình thay vì các từ thông thường. Ý nghĩa của chúng phụ thuộc vào cấu hình mô hình và tokenizer. Các mẫu thông điệp có thể thêm dấu phân tách hoặc nhãn vai trò xung quanh văn bản hiển thị cho người dùng, nên chỉ đếm phần văn bản của thông điệp có thể làm đánh giá thấp yêu cầu đã được mã hóa.

Sử dụng đường dẫn định dạng được hỗ trợ của mô hình đã chọn. Tự tay nối các nhãn vai trò có thể tạo ra đầu vào khác với mẫu thông điệp dự định ngay cả khi văn bản kết quả trông giống trong log. Hãy xác minh mọi cơ chế tuần tự hóa tùy chỉnh so với giao diện mà ứng dụng của bạn thực sự gọi.

Giữ nội dung không đáng tin tách biệt với quá trình dựng thông điệp đặc quyền. Một trang được truy xuất có thể chứa văn bản trông giống một đánh dấu đặc biệt hoặc chỉ dẫn. Hãy xử lý nó như nội dung nguồn bằng giao diện thích hợp thay vì để nó thay đổi ranh giới thông điệp. Việc tách token và tuần tự hóa phải giữ nguyên các vai trò và ranh giới dữ liệu mà ứng dụng dự định, không để một chuỗi bên ngoài vô tình định nghĩa chúng.

Số lượng token phụ thuộc vào văn bản và bộ tách token

Số lượng token thay đổi theo bộ tách token, ngôn ngữ và cấu trúc của đầu vào, cũng như mọi định dạng được thêm xung quanh nó. Mã có nhiều dấu câu, định danh lạ và văn xuôi thông thường có thể có số lượng token khác nhau dù có cùng độ dài ký tự hiển thị. Do đó, chuyển đổi cố định từ từ sang token chỉ là ước tính chứ không phải phép đo chính xác.

Để lập ngân sách, hãy đếm toàn bộ đầu vào đã tuần tự hóa khi giao diện cho phép. Bao gồm chỉ dẫn, lịch sử được giữ lại, định nghĩa công cụ và bằng chứng đã chọn. Giữ một biên độ phù hợp với ứng dụng của bạn cho việc sinh đầu ra và bất kỳ hạng mục hạch toán bổ sung nào được dịch vụ mô hình ghi nhận. Không trình bày ước tính cục bộ như bản ghi sử dụng cuối cùng do dịch vụ từ xa trả về.

Khi di chuyển mô hình, hãy chạy một tập văn bản đại diện qua bộ tách token mới và kiểm tra phân bố số lượng. Một mẫu ngắn có thể bỏ sót loại tài liệu giãn nở nhiều nhất. Hãy xem riêng các trang kỹ thuật dài, nội dung đa ngôn ngữ và bản ghi có cấu trúc. Dùng các kết quả đó để điều chỉnh kiểm tra tiếp nhận và lắp ghép ngữ cảnh mà không thay đổi ý nghĩa của tài liệu nguồn.

Chia khối và tách token là hai thao tác khác nhau

Chia khối phân chia tài liệu thành các đơn vị để lưu trữ, truy xuất hoặc xử lý, trong khi tách token mã hóa các đơn vị đó cho một mô hình. Một khối có thể chứa nhiều token. Chọn ranh giới khối chỉ theo số lượng token có thể tách định nghĩa khỏi phần điều kiện của nó hoặc tách một giá trị trong bảng khỏi hàng giải thích nó.

Bắt đầu với cấu trúc tài liệu và các câu hỏi mà ứng dụng của bạn cần trả lời. Sử dụng tiêu đề, đoạn văn và các đơn vị thủ tục hoàn chỉnh khi phù hợp, sau đó kiểm tra kích thước token bằng bộ tách token đúng. Giữ lại offset nguồn hoặc một bộ định vị khác để một khối đã chọn có thể được kiểm tra trong ngữ cảnh.

Nếu bạn thu thập trang thông qua Agent Browser, hãy giữ nguồn đã thu thập, văn bản đã làm sạch, các khối và đầu vào đã mã hóa như các hiện vật có thể phân biệt. Mỗi giai đoạn trả lời một câu hỏi gỡ lỗi khác nhau. Chi phí thu thập bằng trình duyệt và mức sử dụng token của mô hình cũng tách biệt, vì vậy hãy giữ hạch toán dịch vụ Scrapeless song song thay vì nhúng bên trong số đếm của bộ tách token.

Xác thực việc tách token tại ranh giới mô hình

Việc xác thực bộ tách token nên nhắm vào các lỗi có thể ảnh hưởng đến ứng dụng của bạn. Kiểm tra ký tự bất thường, khoảng trắng có ý nghĩa, định danh dài, đầu vào rỗng và định dạng thông điệp mà bạn thực sự gửi. Kiểm tra xem mã hóa và giải mã có giữ được những khác biệt mà tác vụ của bạn yêu cầu không. Ghi lại các biến đổi có chủ đích để chúng không xuất hiện như mất dữ liệu không giải thích được.

Đối với huấn luyện, giữ cho bộ tách token và từ vựng tương thích với checkpoint mô hình và pipeline chuẩn bị. Thay đổi từ vựng không phải là thay thế giao diện phân tách một cách hình thức. Nó làm thay đổi biểu diễn mà mô hình nhận và có thể đòi hỏi các thay đổi vượt ra ngoài tiền xử lý. Tránh hoán đổi bộ tách token chỉ để có số lượng nhỏ hơn mà không kiểm tra biểu diễn đầu vào mong đợi của mô hình.

Đối với suy luận thông qua một dịch vụ, hãy phân biệt những gì bạn kiểm soát với những gì dịch vụ xử lý. Bộ tách token cục bộ của bạn có thể hỗ trợ ước tính và gỡ lỗi, nhưng giao diện từ xa có thể áp dụng tuần tự hóa bổ sung. So sánh ước tính với mức sử dụng được trả về trên các yêu cầu đại diện trước khi xem chúng là các phép đo có thể thay thế cho nhau.

Kết luận

Một bộ tách token biến văn bản thành các đơn vị và định danh đặc thù cho mô hình. Hãy sử dụng bộ tách token đúng, giữ các khác biệt cần thiết của nguồn trước khi mã hóa, và kiểm tra định dạng thông điệp hoàn chỉnh. Khi số đếm hoặc đầu ra có vẻ sai, hãy kiểm tra trích xuất, chuẩn hóa, tuần tự hóa và khả năng tương thích mô hình như các ranh giới tách biệt.