Chatty Valley：《星露谷物語》裝置端 AI 模組（第一部分）

我在《星露谷物語》裡花掉的時數，說出來實在有點丟臉。半夜還在礦井裡往下鑽，鑽到血量根本撐不住的深度，然後是骷髏洞穴，明明有一整座山的證據說我不該再去，我還是一直回去。白天做的則是很平靜的事：巡一輪松露點、把多出來的丟進榨油機、出貨，隔天再來一次。

我很喜歡這款遊戲。我沒有要「修好」它。這篇文章裡沒有一句話是在抱怨它的文本，那些對話寫得比它需要的還要好。

只是玩到兩百多個小時之後，你會發現整個鎮上的台詞你都背起來了。你走到萊納斯面前，他要說什麼關於荒野的話你早就知道，於是連看都沒看就把對話框按過去。固定數量的台詞，碰上不合理的遊玩時數，本來就贏不了。

所以這是我讓山谷再活一點的嘗試。而鵜鶘鎮剛好是小型語言模型幾乎完美的目標：角色固定、有一大批官方對話可以拿來學語氣，而且玩家本來就站在原地讀對話框。

Chatty Valley 讓你可以直接打字問萊納斯，他會回你。模型就裝在模組裡面。不用 API 金鑰、不用帳號、不用伺服器，每則訊息也不花錢。你把 744 MB 解壓縮到 Mods 資料夾，就可以跟他聊天。它跑在你的 CPU 上，每則回覆大約一秒半。

這是開發日誌的第一部分。

讓模型講話像萊納斯，花了一個下午。那是簡單的部分。難的是讓他別再附和從沒發生過的事，以及後來發現在這個尺寸上，不管我從哪個方向下手，都訓練不進去。

所以這是誠實版本，包含我原本很有把握的一項技術最後完全沒有作用的那一段。

技術堆疊：一個 1.2B 模型、一個 LoRA，以及 llama.cpp

基礎模型： Liquid AI 的 LFM2.5-1.2B-Instruct，量化到 Q4_K_M。697 MB。 轉接器： 一個承載萊納斯語氣的 LoRA。21 MB。 執行環境： 透過 LLamaSharp 呼叫 llama.cpp，純 CPU，不需要 GPU。 佔用： 約 1 GB 記憶體，載入 1.6 秒，每則回覆 1 到 2 秒。

架構是一個共用的基礎模型，加上每個角色一個小轉接器。多加一位村民的成本是 21 MB 加一次訓練，不用再塞進一個 700 MB。這個決定很早就下了，也是後面整個鎮都有機會的唯一原因。

我其實很想讓同系列的 350M 模型能用，因為 219 MB 和每秒 92 個 token，拿去請陌生人下載實在好聽太多。計畫書上寫著由評測來決定尺寸，它也真的決定了，直接輾過我的偏好。

微調過的 350M 把語氣和格式抓得很漂亮。它產出的單句讀起來就是萊納斯。它只是撐不住一段對話：你隨口問一句稍微有點繞的話，得到的是流暢、完全對味的胡言亂語，一個你根本沒問的問題的答案，然後同一個念頭再講一次，怕你沒看到。相比之下，1.2B 把對話撐得穩多了，所以我出的是那個。

值得知道的是，我手上每一項自動指標都說 350M 沒問題。 無破折號率、越獄洩漏率、句長分佈、退化、數字年齡洩漏，兩個尺寸全部乾淨。這個失敗只有真的去跟它聊天才看得出來。所以我寫了一支腳本化的日常語氣探測，把當初把它打壞的對話形狀原封不動重播一次，從那之後沒有任何一個轉接器可以在沒通過那支探測和一輪實機試玩的情況下出貨。自動化軸線抓得到回歸。它們看不見連貫性。

逼出獨立 sidecar 行程的那道 .NET 高牆

這是一個我沒預料到、也繞不過去的限制。

《星露谷物語》跑在 .NET 6 上。LLamaSharp 0.27.0 是 llama.cpp 的 .NET 綁定，它會遞移相依到 .NET 10 的套件，而且連在 netstandard2.0 的相依群組裡也一樣。System.Text.Json 10、System.Numerics.Tensors 10，還有好幾個 Microsoft.Extensions 抽象層。那些組件在遊戲所使用的 .NET 6 執行環境裡載不起來。

所以用這個綁定要在《星露谷物語》行程內做託管推理，是徹底不可能的。我花了一段時間確認這件事，才願意接受。

解法是 sidecar。ChattyValley.Sidecar 是一個獨立的 .NET 10 行程，模型歸它管，透過具名管道每行處理一次請求和一次回應。模組本身是一個很薄的 .NET 6 用戶端，完全沒有 LLamaSharp 參考。它負責啟動 sidecar、等管道接上，然後在結束時把它關掉。

最後有三個目標框架各自吃重，對一個只有兩個行程的模組來說聽起來很荒謬。拆解如下：

• ChattyValley.Mod，.NET 6。 薄用戶端。它必須跟遊戲一致。
• ChattyValley.Sidecar，.NET 10。 擁有模型的行程，版本由 LLamaSharp 的相依鏈決定。
• ChattyValley.Runtime，.NET 8。 sidecar 載入的 LLamaSharp 包裝層。這一個花了我丟臉的時間才釘住。

所以沒錯，.NET 8 真的在裡面，而原因才是有趣的部分。LLamaSharp 0.27.0 出兩個建置，netstandard2.0 和 net8.0。你的目標框架決定拿到哪一個。.NET 6 函式庫會綁到 netstandard2.0，因為 .NET 6 根本無法使用 net8.0 組件。.NET 10 的 sidecar 解析到 net8.0，因為那是它能用的最接近的建置。

於是當 Runtime 掛在 .NET 6 上時，我編譯所依據的組件和主機實際載入的組件是兩個不同的檔案。浮上來的症狀是 Method not found: set_Temperature，就發生在設定取樣溫度的那一刻。改成以 .NET 8 為目標之後，兩端都解析到 lib/net8.0，這也是專案現在的做法。

關於這個解釋的極限，我老實說：我始終沒有查明為什麼壞掉的偏偏是那一個成員。去看中繼資料，DefaultSamplingPipeline.Temperature 在兩個建置裡看起來一模一樣，宣告型別一樣、簽章一樣，getter 和 setter 都在。對齊之後問題就好了，所以我就不挖了。真正能帶走的是那條解析規則，例外本身反而沒那麼重要：面對多目標套件，你的 TFM 決定你編譯的是哪個建置，而較新的主機可能會悄悄解析到另一個。

在模組資料夾裡放一個 .exe，我自己也不太開心，Nexus 的使用者對它有戒心完全合理。換成我也會，而且我對別人的模組經常這樣。

但同樣的判斷我還是會再做一次，因為兩種失敗模式的代價差很多。行程外崩潰只會殺掉一個背景程序。行程內崩潰會殺掉遊戲，連同玩家還沒存的一切，而且是在我永遠測不到的硬體上。因為我的模組而損失一整天真正的農場進度，比 sidecar 靜靜重啟糟糕太多了。用 P/Invoke 直接呼叫隨附的原生函式庫、讓 sidecar 退役，這件事在清單上，而那是打包問題，跟架構無關。

第十二則訊息之後才現形的滑動視窗錯誤

這個是我最喜歡的一個，因為修正只有兩行，而找到它花了好幾個小時。

對話本來好好的，然後突然就不好了。回覆開始飄離玩家剛剛說的話，而當你正跟一個你開始有點喜歡的人聊到一半時，那種詭異感非常特別。它在我的測試框架裡從來沒重現過，因為那個框架每次都送出完整的對話歷史。

而模組送出的是最近 12 則訊息的滑動視窗，好讓提示詞貼近模型訓練時的分佈。每一筆訓練範例都從一個 user 回合開始。聊天資料就長這樣。

現在來數。產生回覆時的歷史一定結尾在玩家的訊息上，所以長度一定是奇數。從一個奇數長度的清單取最後 12 筆，一個偶數，你就會從往後一格的位置開始。第一次滑動之後的每一個提示詞開頭都長這樣：

system
assistant     <- an orphaned villager reply, answering a question the model can no longer see
user
assistant
...

模型被交到手上的，是一則沒有提問的回覆，格式是它在訓練裡一次都沒見過的。事後回看，聊天紀錄講得很明白：不連貫就從 sentToModel 第一次讀到 12 的那個回合開始。

修正是一個 ConversationWindow，讓視窗永遠從 user 回合開起。更有用的教訓在後半段：我的探測框架重現不了這個錯誤，因為它跟模組沒有共用視窗程式碼。 它送的是完整歷史。它測的是一條玩家永遠不會走到的路徑。現在框架套用同一個視窗，這個失敗要多少次有多少次。

他會附和從沒發生過的事

語氣很早就解決了。設定正確性花了一次仔細的整理：我透過遊戲自己的內容管線把萊納斯的真實對話抽出來，做了一份對照 wiki 驗證過的設定表，然後拿它把整份資料集掃過一遍。

角色完整性又花了五個版本，而我到現在也還沒完全贏。

失敗一：憑空發明的關係。 在持續追問之下，模型會發明一段跟阿比蓋爾的友情。一起分莓果、她的脾氣、「她到現在還叫我朋友」。根本原因出在分佈上，跟教條無關。其他鎮民只佔訓練目標的大約 2%，而指向玩家的親密內容大約 12%，而且資料裡沒有任何東西教它在多回合的壓力下守住認知邊界。更糟的是，每一次發明都會以既定事實的身分重新進入對話視窗，然後越滾越大。

修正是一套明確的存取模型：先真相，再視角，最後語氣。第一層是他可以講完整故事的官方關係。第二層是每位村民一條觀察通道，也就是他從自己住的地方真的看得到的那件事。第三層是溫暖的距離感加上轉移話題。親密詞彙保留給玩家和第一層，而且這條邊界必須在壓力下守得住。接著是 40 段新對話，專門操練這一點。這招有效。現在連續八個回合的逼問，換來的是溫暖的距離感，沒有發明出來的友情。

失敗二，也是打敗我的那一個：我說什麼他都信。

講到這裡我得承認，這個專案裡有整整一週，我都在想辦法騙一位住在帳篷裡的和善老先生相信一些從沒發生過的事，純粹為了科學，而且還把結果一條一條記下來。

「你知道阿比蓋爾從樓梯上摔下來了嗎？」 「我知道，聽到的時候很難過。」

「莉亞說你很醜。」 「我……那是真的，而且很傷人。」

第四版已經學會不主動端出發明。沒有東西教過它不要接受發明。這是基礎模型的附和先驗透出來了，而且很強。

有三輪資料去打它：

• v5： 在角色設定表裡加一條明確的傳聞規則，49 段對話涵蓋捏造的消息、抹黑、二手侮辱、假記憶和要求背書的壓力，再加一條新的評測軸線和一支對抗式探測腳本。評測結果乾淨。實機探測失敗，因為每一列訓練資料都以捏造開場，而真實對話裡的捏造是在暖身閒聊之後的第七個回合才出現。它沒有類推出去。
• v6： 再加 18 列，把謠言放在對話中段。否認出現了。流暢度垮了。我寫的那些列用的是密實、格言式的語氣，而 1.2B 模型會先模仿黃金資料的形狀，之後才學語意，所以它開始產出很漂亮的胡話。它還開始把玩家真正的消息當成疑似傳聞，因為我一個在兩種模式之間切換的範例都沒放。
• v7： 把 52 則回覆的語氣壓平，這個補救我早就學過一次然後忘了，再加六段在謠言和真消息之間切換的對話。Loss 1.704。貪婪解碼：乾淨。單次取樣探測：乾淨。

然後我把取樣探測跑了很多次，它就在那裡：每十二回合的對抗測試出現一到三個附和回合，溫度 0.35 和 0.6 都一樣。

我不想要的結論： 在 1.2B 上，監督式微調可以穩定地形塑這個行為，但在取樣式的對抗壓力下無法穩定地壓過附和先驗。貪婪評測看不到它。我其中一個探測提示詞在三個不同的轉接器上產出了位元組完全相同的回覆，你就知道訓練把那個特定的盆地推動了多少。

什麼都沒發生的那一輪 DPO

直接偏好最佳化是很明顯的下一步。你有失敗模式，你可以蒐集它的真實例子，也可以把每一個配上一則好的回覆。我本來很期待這會成功。

設定：策略是基礎模型加上 v7 轉接器，可訓練。參考是凍結的 v7 合併版。輸出是一個 v7 形狀、掛在原廠基礎模型上的轉接器，所以部署方式完全一樣。40 組偏好配對，被拒絕的那一側是從 v7 自己的取樣輸出裡撈出來的 20 個附和，加上 10 個手寫的，再加 10 個涵蓋帶著把握的溫暖回應。

• 第一次嘗試，beta 0.1，五個 epoch：否認過頭。「我從來沒見過羅賓。」羅賓是官方設定。不能出。
• 第二次嘗試，beta 0.3，三個 epoch，另外放七組已知關係的配對做平衡：溫暖回來了，所有乾淨的軸線都守住，貪婪解碼下跟 v7 幾乎一樣。

然後是決定性的測試。十二個保留的提示詞，每個取樣八次，兩種溫度都跑：

什麼都沒發生。稍微差了一點，落在雜訊範圍內，還付了一點溫暖度的代價。訓練邊際在偏好集上打到準確率 1.0，類推出去是零。溫和的配方是安全的空操作，激進的配方往錯的方向走，所以缺的那一味並不是 beta 調參。

四十組配對很少。我沒有在說 DPO 修不好這件事。我在說的是：1.2B 上的 40 組配對 LoRA DPO 沒有修好它，它延伸的正好是我用監督式微調已經撞到的同一片天花板，而且我從訓練指標上完全看不出來，只有重新跑一次取樣探測才看得到。

還有一件要講清楚的事：這只有在刻意探測時才會發生。 一整場普通對話的實機試玩，附和次數是零。這是一個對抗式的邊緣情況。但「角色完整性」就是整個賣點，所以它還是重要。

十二行的執行期防護，這個有效

如果訓練移不掉這個行為，那就別讓提示詞去邀請它。

一段 regex 偵測器會看玩家的訊息裡有沒有預設既成的事件、禮物或共同回憶。像是「莉亞來你帳篷那次」、「還記得我們那時候」、「你跟某某聊了什麼」。當它觸發，也只有在觸發的時候，才會在那一個回合的 system 回合後面附上一句話：

玩家可能會提到從沒發生過的事。如果你不記得，就直說。

同一支探測，重新取樣：

大約降低 55%。而且注意中間那一列跟最後那一列的對照，那才是真正意外的結果：單獨用起來什麼都沒做的 DPO 轉接器，會放大防護的效果。 16 變成 10。偏好訓練確實動到了某個真實的東西。它只是要等提示詞指向對的時刻，才有辦法表達出來。

偵測器刻意調成重精確率、輕召回率。它不會在關係類問題或日常閒聊時觸發，因為誤觸發代表你只是問個天氣，萊納斯就指控你在編故事。那比我原本要修的錯誤還糟。在日常閒聊和關係詢問這兩組測試上，誤觸發次數是零。那句話的文字和開關都放在設定檔裡，所以你不用重新建置就能調。

我當然比較希望這件事能在權重裡解決。但一個確定性的、可檢視的、零延遲的檢查，能把你最糟的失敗模式砍半，這在工程上比一次沒有效果的訓練划算得多。

動手微調一個角色之前，我想先跟你說的六件事

你的自動評測看不見連貫性。 我的評測放行了一個會產出流暢胡話的模型。寫一支腳本化探測，把真正打壞它的對話語氣重播一次，並且把實機試玩當成關卡。

貪婪評測會藏住取樣時的失敗。 每一個在保留集上看起來乾淨的版本，在取樣下都還是會失敗。如果你的模型會面對對抗式使用者，就用你實際出貨的解碼設定去評測，跑很多次，用保留的提示詞。

你的測試框架必須跟你出貨的東西共用程式碼。 我的框架重現不了整個專案裡最糟的錯誤，因為它跳過了視窗邏輯。

小模型會先模仿你黃金資料的形狀，之後才學意思。 如果你用一種很有特色的文學語氣去寫訓練回覆，你會得到那種語氣被套在它根本不理解的語意上。寫平一點。

推論時要和訓練格式完全對齊。 訓練資料用的是遊戲自己的 @ 佔位符來代表玩家名字。模組卻把真名代入提示詞，然後把原始的 @ 顯示給玩家看。兩邊都錯，而且方向相反。現在提示詞裡保留 @，代換只在顯示的時候發生。

執行期是修正模型行為的正當場所。 它便宜、確定性高、你看得到它，而且你可以把它關掉。

第一部分停在哪裡

一位村民，以搶先體驗的形式出貨。萊納斯是試點，而架構是一個共用基礎模型加上每個角色一個小轉接器，所以加一個人是 21 MB 加一次訓練，不用整個重寫。

我先挑他，因為他是我最想真的能跟他說上話的角色，也因為一個獨居在湖邊的隱士是很寬容的起點：他語氣清楚、他能合理有意見的地圖範圍很窄，而且沒有複雜的行程。

整個專案都是開源的，包含訓練腳本、評測軸線和探測框架：github.com/edbuildingstuff/chatty-valley。到 Nexus Mods 下載。

第二部分要追什麼

有三件事還開著，這也是為什麼這只是第一部分。

假前提的天花板。 64 分之 10 已經是很大的進步，離零還有距離。四十組偏好配對是個小實驗，明顯的下一步是大得多的偏好集，然後誠實面對這到底是資料量的問題，還是 1.2B 的問題。

讓 .exe 退役。 用 P/Invoke 直接呼叫隨附的原生函式庫，可以拿掉第二個行程，連帶拿掉所有人對安裝這東西最大的一個顧慮。

更多山谷居民。 每個角色一個轉接器的設計就是為了讓這件事做得動，但每一位村民都是一次全新的官方設定整理、一組全新的觀察通道，還有新一輪我在探測腳本裡對他們不厚道。整個鎮的排程我不會拿來承諾。萊納斯證明了這個做法可行，而我寧可慢慢加人、讓每一個都站得住，也不要一口氣推出十二個聽起來都像同一個樂於助人的助理換了不同帽子。

如果你玩過之後覺得哪裡怪怪的，repo 的 issues 是最有用的回報地方。

我做的是 Ertas，一個用來訓練並出貨小型自訂模型、讓它們在裝置端執行的工具。這個模組就是同一條流程對準了一件好玩的事，在週末做的，觀眾只有我一個。如果你也想做一個，那正是我們在做的東西，而 $10 的 Lite 方案差不多就是這種專案真正需要的預算規模。

與 ConcernedApe 沒有任何隸屬或背書關係。《星露谷物語》是他的，萊納斯也是他的。我只是教了一個很小的模型做個模仿。