28. Ppl Perplexity - Symato 03/2023

Mở đầu

Khám phá sâu hơn về LLMs, thiên hướng xây dựng LLMs riêng cho Tiếng Việt từ những cái nhỏ nhất (dataset, tokenizer, models, optimizer, ...). Cũng như cố gắng có cái nhìn chung nhất về tình hình AI hiện tại, các hướng phát triển tương lai, hiểu sâu hơn các vấn đề, về cả mặt toán học, logic, nhân quả, ... Nền tảng vững chắc được đóng góp từng chút một từ cộng đồng mạnh mẽ

https://github.com/telexyz là big project nghiên cứu sâu về NLP nhằm tạo ra các LLMs Tiếng Việt của anh Tiến Dũng, đúc kết tinh túy nghiên cứu nhiều năm của anh ấy. Ta lấy đây làm điểm khởi đầu để học hỏi

Perplexity

https://huggingface.co/docs/transformers/perplexity

Perplexity (PPL) là 1 trong những metrics chung nhất để đánh giá language models

Ta cần lưu ý rằng những metric này áp dụng cho classical language models (autoregressive hay casual LMs) chứ không được định nghĩa cho masked language models như BERT

Theo trực giác, có thể coi đay là 1 đánh giá về khả năng dự đoán thống nhất (model's ability to predict uniformly) giữa các tập token trong 1 corpus. Quan trọng gơn, điều này nghĩa là tokenizaion perplexity có tác động trực tiếp đến model's perplexity mà điều này nên được xem xét khi so sánh các mô hình khác nhau

Việc này cũng tương đương với exponentiation của cross-entropy giữa data và model predictions. Đồng thời liên quan đến Bits Per Character (BPC) và Bytes Pair Encoding (BPE)

Calculating PPL with fixed-length models

Nếu không bị giới hạn bởi model's context size, ta đánh giá PPL qua autoregressively factorizing 1 sequence và conditioning trên 1 entire preceding subsequence tại mỗi bước

Tuy nhiên khi làm việc với approximate models, ta thường có hạn chế về số tokens có thể process (ví dụ GPT-2 là 1024)

-> Ta cần chia nhỏ chuỗi dài thành các phần rời rạc (disjoint chunks) và cộng các decomposed log-likelihoods của mỗi phần independently

Điều này giúp ta tính toán nhanh chóng perplexity nhưng đổi lại thì do đây là phép tính gần đúng (poor approximation) cho nên kết quả PPL thường cao hơn (tệ hơn) vì ít context hơn tại các prediction steps

Thay vào đó, fixed-length models nên dùng sliding-window strategy (cửa sổ trượt)

nhưng ta có thể theo các bước lớn hơn thay vì chỉ padding 1 token 1 lần

Implement exampe: https://huggingface.co/docs/transformers/perplexity

Symato

https://docs.google.com/document/d/1VQz-4Hy7s6h0dtzbFyL3d4vcOkDd5LH0JAoMlYF807A/edit

Mấu chốt, lí do có Symato?

Ta đã biết GPTs được train chủ yếu trên tiếng anh, nhưng vẫn hoạt động khá tốt trên các ngôn ngữ khác, tuy nhiên sau quá trình Data Analysis, anh Dũng nhận ra rằng tiếng Việt có cấu trúc khác tiếng Anh, nên nếu chỉ áp dụng LLMs fine-tuning như thế sẽ khó có kết quả ổn.

Cụ thể ở đây, chữ tiếng Anh có cấu trúc rõ ràng left-to-right (cat - cats). Nhưng tiếng Việt không có rõ ràng như thế (bình yên - yên bình) nên cần thay đổi phương pháp cho phù hợp

Với LLMs trên tiếng anh, phương pháp tách từ để train phổ biến nhất hiện nay là BPE (Byte pair encoding). Mục đích là cân bằng số lượng từ (vocab size) và độ phủ (nén) thông tin của các từ trong bộ từ vựng (mỗi từ vựng là 1 đơn vị entire để đưa vào training)

Do đơn vị khởi điểm của BPE là byte (cỡ bằng 1 chữ cái mã ASCII) nên không có khái niệm về âm tiết tiếng việt (chữ cái riêng của tiếng việt được hiểu là symbol đặc biệt theo mã Unicode). Nguyên tắc hoạt động là coi các node là chữ cái rời rạc và tìm cách link các node lại sao cho thành 1 từ có nghĩa (1 từ là 1 sequence các chữ cái liền nhau ngăn cách bởi space " ")

Tuy nhiên, phân tích Tiếng Việt cho thấy dữ liệu thuần âm tiết chiếm tới 80% tổng dữ liệu. Nên nếu áp dụng BPE truyền thống (thường cho phi âm tiết) thì sẽ không được quan tâm đúng mức -> Symato tập trung vào âm tiết

Ta có 1 ví dụ so sánh:

Có thể thấy về tổng thể BPE nén tốt hơn (dùng ít đơn vị hơn), tuy nhiên symato biết liên kết các từ 2 âm tiết. Ta sẽ bàn kĩ hơn tại sao symato lại token lạ như vậy

Note: những chữ xanh là bigrams cần thêm vào vocal, chữ đỏ là cần thay thế

Thực nghiệm so sánh

Ta thử cả 2 cách tokenizer với 1.2B LLM, dataset vietnamese laws 6G, giống hệt archtecture, cùng số lượng tham số, cùng số lượng vocal (16k), chỉ khác cách phân tách từ. Mỗi model train 3 epochs (mỗi đơn vị được huấn luyện 3 lần)

Thông số GPU để tham khảo

Đi sâu hơn về ý tưởng
Hoc hỏi qua trao đổi với anh Tiến Dũng

Q: Tại sao Symato lại tokenizer nhiều thứ như thế? như vậy có gây dư thừa không?

A: Người nhìn và máy nhìn khác nhau ( hiểu biết/cái nhìn của con người nếu không đủ sâu sẽ gây lầm tưởng). Mặc dù ta thấy rằng số đơn vị BPE dùng là ít hơn, nhưng ta không biết mỗi đơn vị phức tạp thế nào, dài bao nhiêu :D

Ví dụ:

- BPE mỗi "Đi" là 1 từ, nhưng symato cần thêm 1 token "^^" cho viết hoa hoàn toàn và "^" cho viết hoa chữ đầu. Vậy symato cần nhiều hơn BPE 1 token

- Nhưng BPE coi "Đi", "đi", "ĐI" là khác nhau. Trong khi symato chỉ có 1 nghĩa "đi" và 1 token cho cách viết

Thậm chí BPE còn coi mỗi kí tự tiếng Việt là symbol đặc biệt theo mã Unicode (chuyển thể từ phần mềm bộ gõ Vni, Telex,...) nên hoặc từ đó có trong vocal trước, hoặc sẽ thế này

Q: Ý tưởng nào để xây dựng Symato?

A: "words" trong mắt BPE nguyên ản là đơn vị chữ, đa phần được phân tách bởi 'space" trong khi phân tách bởi dấu "space" trong tiếng Việt là âm tiết (vocal trước 1975 tốt hơn?), không phải từ tiếng Việt

Nó không đơn giản như cách con người nghĩ (BitterLesson), tiếng Việt có khoảng 18k âm tiết có nghĩa (chưa phải từ) -> từ điển bét nhất cũng 32k, 64k,... -> Làm thế nào để nhồi tất cả vào vocal-size 16k? (đây chính là tinh túy của symato)

symato = sym + marktone, tách âm tiết thành viết không dấu + (dấu và thanh)

Vậy thay vì lưu 18k âm tiết ta chỉ cần 1 bộ tối thiểu 3k syms + marktone

13k còn lại thì lưu những thứ khác (từ ghép, kí tự, ...)

Q: Vậy cấu trúc của symato là thế nào?

Q: tại sao lại cần 16k?

A: quả thật ta có thể rút gọn xuống 3.2k, tuy nhiên, mục đích tokenizer là cân bằng số lượng từ (vocab size) và độ phủ (nén) thông tin của các từ trong bộ từ vựng. Nếu quá ít vocal trong khi context length dài, ta phải nhìn lại rằng Transformer embeding position bằng bộ vocab => Không đủ length => Hoặc có vị trí không embedding được, hoặc có vị trí có embedding trùng vị trí khác => Sai mục đích của Transformer

=> Qua thời gian, ta cũng phải thay đổi size của nhiều thứ để phù hợp với cấu hình phần cứng và ngược lại

Q: Vậy kinh nghiệm nào được suy ra từ đây?

- Đầu tiên, symato sẽ thống kê trong corpus các âm tiết nào xuất hiện nhiều nhất thì lưu lại (có 1 lượng lớn các âm tiết tuy có nghĩa nhưng rất ít được sử dụng), vậy chỉ lưu những âm tiết thật sự phổ biến

- Hiệu quả biểu diễn không cần nhiều slots, ta cps thể ép bộ từ vựng xuống 3.2k mà vẫn hiệu quả

- Thống kê ra, ta mới biết cái gì thực sự cần, cái gì tưởng cần nhưng lại không. Mọi người làm LMs bị BPE chi phối nên không thấy toàn cảnh

- Thực ra cách làm ra symato theo đúng cách nghĩ làm BPE (ta nghiên cứu tư duy, không phải kết quả). Và đơn vị quan trọng nhất của BPE là 256 bytes, nên symato cũng có 256 slots đầu cho 246 bytes (cái này bất di bất dịch), sau đó mới biến tấu cho hợp tiếng Việt

- Hiểu đúng và dùng một cách linh hoạt

- 1 cái rất đơn giản, đọc qua là biết, nhưng hiểu sâu và ứng dụng hiệu quả thì lại là chuyện khác. Đa phần mọi người thích transformer, gpt, llm, rlhf,... quên mất mọi thứ phải từ data đi lên, nếu không phân tích được data và biểu diễn data tốt thì những cái trên phế vật -> 1 model cùi, đủ computing và 1 dataset tốt là OK

- Tranh nhau về model, về performance, về accuracy là hơi sai hướng. Cái cần thiết là data và data representation -> Data Sientist

Quả thật, nghiệm ra mới thấy, xét theo góc nhìn về data, bản chất toàn bộ Deep Learning là ta biến những bài toán/ task thực tế về cùng 1 task duy nhất là data representation và fill in missing value, model chỉ là tạo ra 1 biểu diễn function phổ biến để rồi cố gắng tinh chỉnh function đấy sao cho hợp với datasets nhất (tìm nguyên hàm biểu diễn dataset) -> Tất cả là xác suất thống kê và tối ưu đạo hàm

Ví dụ điển hình: trong hầu hết trường hợp, model phức tạp hơn, bậc cao hơn sẽ biểu diễn được theo dạng model nhỏ hơn, nhưng khi tối ưu thì lại dễ bị overfit/ kẹt ở local optimization hơn

-> Chưa chắc model nào, mặc dù phức tạp hơn đã tốt hơn, tất cả dựa vào data representation -> Việc dựa vào feature-based chỉ giúp ta hình dung phần nào data representation chứ khó chính xác hoàn toàn