# 開發場論語言模型之路 part4
## PipeOwl-1.3-multilingual


模型資源(**不推薦 開啟時間過久 請用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
真是充滿矛盾
---
此圖展示模型多語言的空間位置

---
正負樣本配對

---
多語言類比

---
## PipeOwl-1.5-jp
模型資源:
[HuggingFace:PipeOwl-1.5-jp](https://huggingface.co/WangKaiLin/PipeOwl-1.5-jp)
---
### 怎麼感覺benchmark好像要決戰了

| 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 模型

吐一口老血 連tokenizer也都格式了
我能把embedding倒過來學也是奇耙
解析這東西�� 真是心累