- Trong quá trình hỗ trợ phát triển ứng dụng AI xử lý dữ liệu e-commerce, đã phát hiện vấn đề là Retrieval-augmented generation (RAG) hoạt động tốt với một số truy vấn nhưng lại không như vậy với những truy vấn khác
- Khi giải quyết các vấn đề như thế này, điều quan trọng là phải xem xét dữ liệu đầu vào (văn bản gốc đã được lập chỉ mục, truy vấn người dùng dùng cho tìm kiếm)
- Đặc biệt, có vẻ cần tối ưu hóa ở khía cạnh chunking và tokenization
[Tokenization]
- Tokenization là quá trình phân tách văn bản thành các token, tức các mảnh nhỏ hơn, bằng tokenizer
- Các token này được ánh xạ sang token ID, là các giá trị số nguyên dùng để định danh duy nhất token trong từ vựng của tokenizer
- Từ vựng của tokenizer là tập hợp tất cả token có thể có được dùng để huấn luyện tokenizer
- Nếu token trong văn bản không có trong từ vựng của tokenizer của LLM thì có thể phát sinh vấn đề
- Phần lớn LLM có từ vựng lớn với kích thước khoảng 30k~300k
- Hầu hết các LLM được dùng rộng rãi đều dựa vào subword tokenizer (BPE, Wordpiece, v.v.)
- Các loại tokenizer
- word: tách dựa trên khoảng trắng, dấu câu, v.v.
- character: tách theo từng ký tự riêng lẻ (đôi khi cả dấu câu)
- subword: tách token thành các đơn vị con của từ có vẻ không mang nghĩa
- phần lớn LLM sử dụng subword tokenizer
- BPE (Byte-Pair Encoder): thư viện
tiktoken của OpenAI
- Wordpiece: Cohere, MiniLM-L6-v2, v.v.
So sánh MiniLM-L6-v2 và tiktoken
- Kích thước từ vựng tokenizer của mô hình MiniLM-L6-v2 là 30522, nhỏ hơn rất nhiều so với
tiktoken (200019)
- Khi token hóa câu "tokenizer tokenizes text into tokens"
- MiniLM-L6-v2: [CLS] token ##izer token ##izes text into token ##s [SEP]
- tiktoken: token, izer, token, izes, text, into, tokens
- Thư viện
tiktoken của OpenAI triển khai BPE tokenizer và được dùng trong các mô hình ChatGPT LLM
- Trong từ vựng của MiniLM-L6-v2 cũng có cả chữ cái tiếng Đức và ký tự tiếng Nhật
Token hóa emoji, lỗi gõ sai và từ chuyên biệt theo miền
- MiniLM-L6-v2 token hóa emoji thành token [UNK]
tiktoken được huấn luyện với một số token ký tự Unicode, nhưng điều này vẫn có thể gây vấn đề cho RAG- Các tên sản phẩm chuyên biệt theo miền như "Gucci Savoy Leathertrimmed Printed Coatedcanvas Suitcase" cũng không được token hóa đúng cách
- Với câu có lỗi chính tả ("I hve received wrong pckage")
- MiniLM-L6-v2: i, h, ##ve, received, wrong, pc, ##ka, ##ge
- tiktoken: I, h, ve, received, wrong, p, ck, age
[Embeddings]
- Bản thân tokenizer không quá hữu ích. Nó chủ yếu được phát triển để thực hiện các phân tích số phức tạp dựa trên tần suất của từng token
- Để bảo toàn ý nghĩa ngữ cảnh của văn bản, cần có cách nắm bắt được mối quan hệ giữa các token
- Embedding là vector biểu diễn token, giúp nắm bắt tốt ý nghĩa và quan hệ giữa các từ trong văn bản
- Embedding là sản phẩm phụ của quá trình huấn luyện transformer, và thực sự được học từ các kho văn bản đã được token hóa
- Khi yêu cầu sinh văn bản, thứ được đưa vào LLM làm đầu vào chính là embedding
- LLM gồm hai thành phần chính là encoder và decoder
- Cả encoder lẫn decoder đều nhận embedding làm đầu vào
- Đầu ra của encoder cũng là embedding, và chúng được truyền tới các head cross-attention của decoder, đóng vai trò quan trọng trong việc sinh (dự đoán) token ở đầu ra của decoder
- Trong pipeline RAG, văn bản trước tiên được token hóa, sau đó được embedding, rồi được đưa vào transformer
- Token ID đóng vai trò chỉ mục trong từ vựng tokenizer, đồng thời cũng được dùng để lấy embedding từ ma trận embedding
- Các embedding được lấy ra sẽ được ghép thành tensor và đưa vào đầu vào của transformer
- Luồng encoder: token hóa văn bản -> lấy embedding của từng token -> ghép tensor embedding -> đưa vào đầu vào transformer -> mã hóa -> truyền đầu ra encoder vào cross-attention của decoder -> tạo đầu ra decoder
Ví dụ về embedding
- "You can break it 😞" và "You can not break it 😊" có cảm xúc trái ngược nhau, nhưng trong MiniLM-L6-v2 thì khoảng cách embedding lại rất gần
- OpenAI cho hiệu năng tốt hơn vì từ vựng token xử lý emoji tốt hơn
- Với lỗi chính tả, OpenAI cũng xử lý tốt hơn
- Tuy nhiên ngay cả với OpenAI, nếu thêm khoảng trắng ở cuối câu thì khoảng cách giữa các embedding cũng giãn ra một cách ngoài dự kiến
- Các nhà phát triển cũng gặp khó khăn khi xử lý định dạng ngày tháng. Biểu đạt thời gian tương đối ("đã được giao hôm qua") có thể là vấn đề còn lớn hơn
- Sự khác biệt trong cách biểu thị tiền tệ (£40, $50, 40£, 50¢, v.v.) cũng có thể gây ra những vấn đề kỳ lạ
- Với dữ liệu chuyên biệt theo miền như trường hợp túi Gucci, thông thường người ta giải quyết bằng fine-tuning, nhưng luôn cần kiểm tra kỹ dữ liệu và chỉ số đánh giá
Kết luận
- Bài viết này giúp hiểu rõ hơn tokenizer có thể ảnh hưởng đến ứng dụng RAG như thế nào, và vì sao cần chú ý đến tokenizer
- Với các ứng dụng agent, garbage-in garbage-out sẽ không phải lúc nào cũng cho ra kết quả đúng như mong đợi
- Chỉ cần dọn dẹp nhẹ văn bản đầu vào cũng có thể mang lại khác biệt lớn
- Chuẩn hóa định dạng ngày tháng một cách nhất quán
- Loại bỏ khoảng trắng thừa ở cuối khi có thể (đã xác nhận ảnh hưởng tới embedding)
- Áp dụng tương tự cho các dữ liệu số khác như giá bằng các loại tiền tệ khác nhau
- Hy vọng một ngày nào đó chúng ta sẽ không còn phải nghĩ đến tokenizer nữa. Có thể bỏ hẳn nó đi
- Khi đó sẽ không còn cần xử lý lỗi chính tả, khoảng trắng tùy ý, hay các kiểu tấn công đối kháng dựa trên perplexity của từ. Một dạng nỗi buồn có thể biến mất chỉ sau một đêm
- Cho đến lúc đó, hãy token hóa một cách có trách nhiệm
Ý kiến của GN⁺
- Bài viết này cho thấy rất rõ tokenizer và embedding có thể ảnh hưởng thế nào đến hiệu năng của các ứng dụng AI dựa trên RAG. Đặc biệt, bài viết giải thích bằng các ví dụ thực tế những điểm cần chú ý khi xử lý emoji, lỗi chính tả, thuật ngữ chuyên biệt theo miền, nên có vẻ sẽ rất hữu ích cho các nhà phát triển
- Tuy vậy, cả MiniLM-L6-v2 và
tiktoken của OpenAI được giới thiệu trong bài đều là các mô hình tối ưu cho tiếng Anh, nên khi xử lý các ngôn ngữ khác có thể sẽ có thêm những điểm cần cân nhắc. Với tiếng Hàn, tokenization dùng bộ phân tích hình thái được sử dụng khá nhiều, nên cũng có vẻ cần xem xét thêm về ưu nhược điểm và giới hạn của cách tiếp cận này
- Ngoài ra, bài viết tập trung vào vai trò của tokenizer và embedding trong pipeline RAG, nhưng trong môi trường production thực tế còn rất nhiều yếu tố khác cần cân nhắc như tiền xử lý dữ liệu, tuning hyperparameter, lightweight hóa mô hình, v.v. Vì vậy, nên xem nội dung bài viết như một điểm khởi đầu, còn trong quá trình phát triển thực tế thì điều quan trọng là phải tìm ra phương pháp tối ưu thông qua nhiều thử nghiệm và đánh giá khác nhau
- Mặt khác, cũng có ý kiến cho rằng tầm quan trọng của tokenizer đang giảm đi nhờ sự xuất hiện của các mô hình ngôn ngữ lớn như GPT-4. Lý do là các mô hình này hoạt động ở mức câu hoặc đoạn thay vì mức token, nên tác động của chất lượng token riêng lẻ tới hiệu năng có thể nhỏ hơn tương đối. Tuy nhiên, vì nghiên cứu về vấn đề này vẫn chưa đủ nhiều nên rất khó để khẳng định chắc chắn
- Cuối cùng, như bài viết đã đề cập, chỉ riêng việc làm sạch và chuẩn hóa dữ liệu đầu vào trước cũng có thể cải thiện đáng kể hiệu năng mô hình. Khi phát triển dịch vụ thực tế, việc xây dựng pipeline tiền xử lý dữ liệu đủ vững chắc để tính đến tính đa dạng và nhiễu trong đầu vào người dùng là rất quan trọng. Đồng thời, cũng cần đầu tư đủ nguồn lực cho công việc gán nhãn và chú thích dữ liệu để đảm bảo dữ liệu huấn luyện chất lượng cao
1 bình luận
Ý kiến Hacker News
Tokenizer không được xem là phần “hấp dẫn” của LLM, nhưng cũng có người nhìn thấy cơ hội ở đó. Các bài báo như xVal đưa ra chiến lược chuyên biệt hóa tokenization. Các tác vụ về chính tả và ký tự là một vấn đề khác có thể hưởng lợi từ đổi mới trong tokenization
Cần hiểu dữ liệu thì mới có thể thực hiện công việc có ý nghĩa. Lý do chính khiến nhiều người dùng công cụ xử lý dữ liệu tự động là vì họ không muốn trực tiếp nhìn vào dữ liệu. Họ muốn máy tính có thể tự xem dữ liệu và yêu cầu thu thập thêm thông tin
Đặc biệt đánh giá cao phần nói về lỗi chính tả trong bài blog. Đang hỗ trợ một ứng dụng tương tự RAG trong dự án, và lo ngại về tác động của những lỗi chính tả nhỏ hoặc khác biệt định dạng trong truy vấn người dùng lên việc tính khoảng cách embedding
Từng làm việc trên một ứng dụng dùng Elasticsearch để xử lý độ tương đồng giữa đầu vào 1-2 câu và các tài liệu dài từ một đoạn trở lên bằng truy vấn văn bản nâng cao. Thật thú vị khi thấy chiến lược tokenization có thể ảnh hưởng đến các truy vấn cụ thể đến mức nào
Cảm thấy bài viết chưa bàn đủ về giải pháp cho từng vấn đề. Đề xuất chạy kiểm tra chính tả trước khi token hóa, hoặc token hóa song song từ viết sai với từ có khả năng là bản sửa đúng
Nhiều nhà phát triển đã quen làm việc trong không gian truyền thống (mang tính quyết định), nhưng chưa thay đổi cách nghĩ về vấn đề trong không gian thống kê. Ứng dụng LLM về bản chất cuối cùng là không gian thống kê
Hầu hết những người triển khai RAG đều nghĩ về embedding mà không nghĩ về tokenization
Không thể tái hiện một số con số trong bài blog. Ví dụ, trong đoạn mã dùng SentenceTransformer, kết quả tính độ tương đồng cosine giữa hai câu khác với kỳ vọng
Đã thấy vấn đề trong nhiều cách triển khai RAG là giả định tài liệu mục tiêu sẽ là khóa tìm kiếm tốt cho truy vấn đầu vào. Trong một dự án gần đây, mức độ liên quan của tìm kiếm được cải thiện đáng kể bằng cách tách khóa tìm kiếm khỏi giá trị trả về (tài liệu đã được chia chunk) và dùng LM để tạo rồi embedding các khóa phù hợp
Dù nhiều người nói từ vựng của các LLM lớn là khá lớn, riêng tiếng Anh thôi cũng đã có hơn 1 triệu từ. 30k-300k token có vẻ vẫn nhỏ