# 開發場論語言模型之路 part4 ## PipeOwl-1.3-multilingual ![patch](https://hackmd.io/_uploads/rJnoWnkc-l.jpg) ![multilingual](https://hackmd.io/_uploads/B1ES23qKWg.jpg) 模型資源(**不推薦 開啟時間過久 請用1.4**): [fp32版:HuggingFace:PipeOwl-1.3-multilingual](https://huggingface.co/WangKaiLin/PipeOwl-1.3-multilingual) --- ### multilingual ~~很糗 拼成multilinqual 跟不知道雪裡蕻一樣~~ 沒想到multilingual比我想像中還要快 原本計畫在4~5月到 挖了english freq發現裡面包含了一些其他國語言 我這邊也很困惑 到底該不該拔噪音詞 拔了:像釘正沒了 沒拔:輸出有機會跑莫名其妙的詞 可能又會像以前一樣 IME功能和LLM功能要分開 這邊誕生了一個想法 難道做IME也放錯字是更好的選項? 以前沒有這樣想過 --- ### mmap 提早撞到了一些問題 startup time來到了30s 原本做了mmap管線 理論上可以到1~5s 但因為上一版沒有提升 所以當時就先拔掉了 非常尷尬 所以要再把它裝回去 還卡到原本的row-nomalize 實測結果非常糟 30s>1min up 會先選擇fp16優化 ## PipeOwl-1.4-multilingual 模型資源: [HuggingFace:PipeOwl-1.4-multilingual](https://huggingface.co/WangKaiLin/PipeOwl-1.4-multilingual) --- ### fp16 fp16後 整體好像就很好了? 我也不清楚現在的標準在哪 startup time壓到了2s 吐字時間到0.1s附近 當然繼續壓縮也可以 但單純的優化還沒有帶來更好的體驗 應該會回頭再把純中文的fp32壓成fp16 總之又到了我可以接受的速度 開始跑performance --- ### 想優化開源專案的心 其實有很多好專案在這世界上 我也是因為這些專案才開始碰代碼的 不避諱就是魔獸世界的postal跟craftsim 但完全不懂程式碼的我 在以前沒有AI工具的情況下 我修postal一段程式碼需要讀半天的內容 用十幾種可能的寫法 但改動只有短短兩三行 背後可能就是一整天 之後我可以修復多種框架 在遊戲群裡當個能解決報錯的戰友 craftsim的出現讓遊戲全專業的我 省去了大部分查價 時間 讀懂背後的算式 道理我都懂 但怎麼變成程式碼的? 我才開始意識... 怎麼玩個遊戲玩的跟上班一樣 到底我在追尋什麼? 話說回來 我還是認為改別人代碼不太禮貌 所以我有看得懂的地方 我大多都私下寄信 並不會直接當著在頁面展示 但其實我還是有點希望 issue可以當成聊天看板XD 真是充滿矛盾 --- 此圖展示模型多語言的空間位置 ![multilingual4](https://hackmd.io/_uploads/H1rib8TtWe.png) --- 正負樣本配對 ![eval1](https://hackmd.io/_uploads/rJZbx_aYZl.png) --- 多語言類比 ![eval2](https://hackmd.io/_uploads/ry8WeuaFZx.png) --- ## PipeOwl-1.5-jp 模型資源: [HuggingFace:PipeOwl-1.5-jp](https://huggingface.co/WangKaiLin/PipeOwl-1.5-jp) --- ### 怎麼感覺benchmark好像要決戰了 ![2](https://hackmd.io/_uploads/rJHhHsJ5Wx.png) | Comparison | Speedup | | ------------- | ---------------- | | vs BM25 | **11.7× faster** | | vs Embedding | **7.9× faster** | | vs FAISS Flat | **9.0× faster** | | vs FAISS HNSW | **6.4× faster** | 不只贏速度 還有載入時間 ### [mask] & vocabulary 這設計很精妙 在我清洗資料的時候發現 日本模型竟然剛好對齊vocab=32768 太細節了吧 不得不說真的太有美感了 就像是數學最後算到答案是0或1一樣 學到一樣mask技術 在早期我也是用[slot]來表示文字區 我做了的casinoowl model 就是每天玩slot的感覺 原來技術早就在了 現在是[mask] 但模型有很多##"文字" 的形式當token 這就是語義濃度高的下場嗎 都要O(n^2^)的形式 --- ## PipeOwl-1.6-tw ### 挫折感 怎麼說呢 目前的進展其實很有限 基本上只是把模型從 666MB 壓縮到 334MB 在上面談了不少性能 但我也開始懷疑自己的能力 看了一些其他專案和學生作業十份左右 如果把我的答案放進去比較 可能敬陪末座 我曾經花了兩個小時閱讀某個專案 試著不依靠 AI 一行一行看過去 嘗試在腦中模擬程式在編譯器與執行時的流程 那個過程 我發現自己很多時候只是很會描述想法 但真正去看程式 找問題 理解系統的能力 還遠遠不夠 如果回到學校 我大概還是那個會想逃課的人 ### dynamic calculate 想好了我的運算式 >score = α⋅base + β⋅Δfield 要改成動態 >score = α⋅base + (1-α⋅base)⋅Δfield 這是可化簡的 考量到易讀性 但這是暫時的進展 因為我還沒有耦合loss function 現在也在思考三種可能的方向： - 靜態權重 - 動態權重 - 靜態 + 動態混合 如果設計不當 後面的工程可能會變得非常複雜 為了得到更準確的 score 也許需要犧牲一點運算時間 某種程度上像是在不同地方之間做取捨 但好在新架構式的運算效率很高 我現在需要在節省下來的時間內 找到更合理的 scoring ### 去掉長尾效應 測試出的模型 比PipeOwl-1.5-jp弱好多 即使有 16 萬詞彙 效果仍然沒有3萬詞彙的jp模型好 例如輸入: 台北 卻沒有出現: 新北 新竹 桃園等詞 這其實讓我重新思考目前的資料分布問題 1.考量到性能 我要把大多長尾詞彙移到 longtail.md的文件去觸發 2.模型並沒有對艱難詞彙去finetune 我也必須想一套finetune 不管資料多廣泛或多狹隘 起碼看出 朋友測試"台積電" 被分成了"台""積""電" 地名也都沒有相關的浮現 我知道台灣有finetune好的llm 但PipeOwl的目標其實不太一樣 我在做的是embedding計算架構的改進 我一直很難接受某些模型 初始化就需要十秒以上 現在壓到2秒了 嗯? 對阿 我自己其實還沒好好搜尋過 台灣相關的 embedding 模型 ![brave](https://hackmd.io/_uploads/Hkv3qgb9bx.jpg)