Skip to main content

2 posts tagged with "Observability"

View All Tags

Wei Ji

其實自我架設 LLM 可觀測工具 (2025-10-05) 以後，陸續嘗試幾款 LLM 工具有獲得一些觀察，不過當時因為覺得缺乏嚴謹考證所以沒有發文，不過現在我可以說是往下一個階段前進了（？），大概也沒有做嚴謹實驗的計畫，就把當時的紀錄發出來水一篇廢文好了。

LLM 可觀測​

這邊簡單跟不知道發生什麼事情的讀者解釋一下「LLM 可觀測」是什麼。以下容我重複使用以前做的圖卡：

info

「角色卡」是一種角色扮演類 LLM 應用軟體的資料包，本質上是包含一堆人物設定、世界觀設定、台詞樣板...的文字。

AnythingLLM​

AnythingLLM 是一個很熱門的 LLM 應用軟體。不過正如我前面所說的，LLM 只是一個組件，要讓它發揮效用，關鍵在於應用程式是否擷取正確資料或資訊餵給 LLM 處理，因此「應用程式的外部連線能力」是我測試的重點。

這是我的測試題目；我知道正確答案，而我也知道這個題目不簡單，我只是想觀察這些 LLM 應用軟體會怎麼處理這個任務：

幫我搜尋這個專案的歷史

https://github.com/ill-inc/biomes-game

最後得到的結果當然不符合我的預期，於是我開啟我的可觀測工具檢查剛剛發生了什麼事情。

我們可以觀察到，AnythingLLM 根據我的輸入觸發了一個「網頁爬蟲工具」：

然後我們可以看到它單純從 GitHub 爬了一堆垃圾就開始唬爛我試著回答剛剛那個問題。

info

正確答案是要用 ill-inc 找到 Global Illumination, Inc. 這間公司，接著找到 OpenAI 在 2023 年收購它們的新聞。 並且在專案的文件網站找到：「被收購之後，專案被團隊釋出後不再維護」的資訊。 我知道這個題目很難，所以後來我也沒有用這個題目測試了，加上我後來找到一些其他對於 LLM 軟體更重要的特性。

Perplexica​

Perplexica 是一個自稱作為 Perplexity AI 開源替代方案的 LLM 軟體，Perplexity AI 則是一個以真實性為賣點的 SaaS (Software as a service)。

同一個題目，表現的跟 AnythingLLM 一樣差勁，不過除了外部連線的機制問題以外，我觀察到另外一個更可疑的行為：

它把對話紀錄的所有角色 (role) 都設定成 assistant！在 OpenAI API 的設計，role 至少有三種：user、assistant、system。

因此 LLM 實際上無法分辨歷史紀錄中誰說了什麼，因為全部都是 assistant 在自言自語。

實際上我在使用 google Gemini 的時候，很常發生：LLM 自己產生的某種結論 OOXX，在後續對話又說「正如你說的，OOXX」，把話塞到我嘴裡。我嚴重懷疑這是由類似的角色不分的提示詞工程造成的。

Local Deep Research​

Local Deep Research 是一個只有 3.8k 星星的專案（截至 2026-01-08），但是它嚴謹的特性深得我喜愛。

觀察到這個特性其實源自於一個意外，我搞錯搜尋引擎的設定，因此它當下無法使用搜尋引擎：

但是我們看看它是怎麼回答使用者的：

  • 它懂得回報使用者當下沒有對外連線、額外可供參考的資料，而不是直接試圖唬爛使用者。
  • 這甚至是「光速是多少？」這種大部分 LLM 都可以應對的簡單問題。它也懂得自我檢討這個回答沒有參考資料佐證。
  • 我使用的是普通的繼承 GPT 幹話王血統的 openai/gpt-oss-20b，並不是什麼特別調整的 LLM。

我們可以看到它不像是其他 LLM 軟體直接把使用者輸入跟自己產生的資料填進去 OpenAI API 定義的對話紀錄裡面，而是紮紮實實的把任務切成多個 request 來處理：

另外一個我在學習 VR 生態系時的例子，比對多個資料來源矛盾的敘述：

因此我可以簡單的把一些需要確認的主題丟給它研究，真正意義上的降低認知負荷，而不是時時要擔心 LLM 在唬爛我：

結論​

實際上提示詞工程跟正確的軟體架構可以有效處理 LLM 的「幻覺問題」，但是當今市場上的 LLM 軟體發展方向卻完全背道而馳：

  • 基於聊天形式的頁面設計，本質上是一個上下文極度不受控的環境，很容易讓 LLM 產生垃圾資料。
  • 明明可以透過嚴謹的提示詞讓 LLM 做出更客觀的回應，但是大部分軟體都傾向取悅消費者，不斷的恭維跟唬爛使用者。
  • 明明可以使用 one shot 的軟體形式提供更穩定的服務，但是就是要做成聊天機器人來欺騙投資人與使用者。

就算不提閉源的 SaaS 方案（ChatGPT, Gemini...），AnythingLLM 或 Perplexica 這類譁眾取寵的實作反而贏得更多喝采（星星），而老實解決問題的 Local Deep Research 卻倍受冷落。

我用 LLM 可觀測性工具看見的不是邪惡的 LLM，更多的是整個產業帶有惡意的商業決策與人們的集體瘋狂。

後記​

曾經有工程師問我，既然我想觀察提示詞工程，為什麼不乾脆看程式碼？畢竟那些自架軟體都有開源。

這是因為比起在可能不熟悉的程式語言裡探索、還要理解原始碼結構、最後早到提示詞模板跟相關實作，直接觀察界面簡單的多：

  • 當我送出一個指令，應用程式呼叫了幾次 LLM 來處理？
    • 複雜問題但是只有一次呼叫，代表著實作的架構有問題。
  • 每次呼叫給了什麼輸入？
    • 「Garbage in, garbage out」，如果 LLM 給了什麼糟糕的答案，十之八九來自應用程式給了糟糕的輸入。

Wei Ji

前情提要​

info

日期是根據 Git Commit 紀錄跟螢幕截圖時間推論的，但是不是真正精準的時間，因為 Git Commit 可能延後一段時間才推送，截圖的問題則是不是每一個當下都有截圖。

2025-10-04 左右： LiteLLM 和 Langfuse 上線。 2025-10-11 左右： Local Deep Research 上線。

2025-10-14 左右： 開始比較頻繁使用 Local Deep Research。

2025-10-22 左右：Homelab 開始出現當機異常。

  • 圖表的斷層就是伺服器完全當機讓資料採集的機能癱瘓造成的。
  • 可以觀察到 CPU 跟 RAM 異常使用是 Langfuse 服務簇的 ClickHouse 造成的。

2025-10-23 的紀錄：

2025-11-01 左右：連帶 Grafana 服務簇也失效，失效後就把 Langfuse 關掉然後沒有修復它了，直到最近 (2026-01) 佈署 K8s 才準備把服務遷移過去。

Grafana 失效前我有關查到 Docker 在重新拉取 image，推測是因為我忘記鎖定 image 版本造成的。

整個過程中出現過幾種不同的情況：

  • 電源鍵強制關機後恢復正常。
  • 電源鍵強制關機後 LiteLLM 異常。
    • Stack 刪掉後重新佈署後恢復正常。
  • 電源鍵強制關機後 Langfuse 異常。
    • 根據 clickhouse log 找到有問題的 block，刪除後重新佈署恢復正常（如下）。
2025.11.01 11:00:20.208590 [ 652 ] {c14fc20e-f2b0-45cb-939c-0fe47de9811c::202510_16681_17212_76} <Error> virtual bool DB::MergePlainMergeTreeTask::executeStep(): Exception is in merge_task.: Code: 40. DB::Exception: Checksum doesn't match: corrupted data. Reference: 52f594fc9d7f3ee0495f8f089d3882cf. Actual: c92bc03d0da25742da61b67ce5764aac. Size of compressed block: 3640. The mismatch is caused by single bit flip in data block at byte 2581, bit 2. This is most likely due to hardware failure. If you receive broken data over network and the error does not repeat every time, this can be caused by bad RAM on network interface controller or bad controller itself or bad RAM on network switches or bad CPU on network switches (look at the logs on related network switches; note that TCP checksums don't help) or bad RAM on host (look at dmesg or kern.log for enormous amount of EDAC errors, ECC-related reports, Machine Check Exceptions, mcelog; note that ECC memory can fail if the number of errors is huge) or bad CPU on host. If you read data from disk, this can be caused by disk bit rot. This exception protects ClickHouse from data corruption due to hardware failures: While reading or decompressing /var/lib/clickhouse/store/c14/c14fc20e-f2b0-45cb-939c-0fe47de9811c/202510_16681_17060_75/data.bin (position: 824782, typename: DB::ReadBufferFromFilePReadWithDescriptorsCache, compressed data header: <uninitialized>): (while reading column ProfileEvent_ReadBufferFromFileDescriptorRead): (while reading from part /var/lib/clickhouse/store/c14/c14fc20e-f2b0-45cb-939c-0fe47de9811c/202510_16681_17060_75/ in table system.metric_log (c14fc20e-f2b0-45cb-939c-0fe47de9811c) located on disk default of type local, from mark 2 with max_rows_to_read = 916, offset = 0): While executing MergeTreeSequentialSource. (CHECKSUM_DOESNT_MATCH), Stack trace (when copying this message, always include the lines below):

  • 電源鍵強制關機後 Langfuse 異常。

    • 根據 clickhouse log 找到有問題的 block，刪除後重新佈署依然無法恢復。
    • 把 clickhouse 建立全新的 Volume 後恢復正常。

  • 有幾次伺服器是完全沒螢幕反應，有反應的幾次可以在終端觀察到 CPU Lock：

watchdog: BUG: soft lockup - CPU#* stuck for **s!

仰賴鏈​

  1. Biomes 重構的進展目前面臨大量的 Schema 型別修復工作，我需要借助 LLM 之力來解決。

  1. 我拒絕使用基於聊天或 IDE Agent 的 LLM 方案。
  2. 我想使用 ComfyUI 來構造專門用來處理 Schema 修復問題的 pipeline。
  3. 我在本地使用 LLM 工具我要求必須在有 LLM Observability 的前提下使用，所以我必須先修復我的 LLM Observability。
  4. 在有伺服器崩潰的前車之鑑，我要求必須在有 Observability 的前提下佈署 LLM Observability，所以我必須先修復我的 Observability。
  5. 但是我不想在現有的節點上修復 Observability，而是在新的節點使用 K8s 並佈署 Observability，因此我要先學習使用 K8s。

Observability 重建的當前狀態​

到昨天 (2026-01-06) 為止，我已經：

  1. 設定新的節點，安裝 K3s。(2025-12-24)
  2. 整理之前跟 K8s 有關的知識點。(2025-12-28~2026-01-02)
  3. 釐清 Ingress/Load Balancer 的概念。(~2026-01-05)
  4. 釐清 PV/PVC 的概念。(~2026-01-05)
  5. 用 Helm 安裝 Longhorn。(2026-01-05)
  6. 用 Helm 安裝 Kube-Prometheus-Stack。(2026-01-06)

用 K8s 內的 Prometheus 和 Grafana 實例取代原本的，原本的兩張 Dashboard 則是本來就有 JSON 檔直接移過去。原本的伺服器指保留 Cadvisor 供新的 Prometheus 採集資料。

目前關於容器的 Dashboard 是處於兩個節點資料混在一起的狀態，暫時先不處理 Query 需要更新的問題：

Node Dashboard 則是直接接軌新的 Node Exporter 的資料，暫時也先不處理舊節點的資料：

info

Kube-Prometheus-Stack 其實有提供不少 Dashboard 用來觀察新節點，我就不在這邊一一列舉了。

Prometheus 安裝筆記​

跟 Longhorn 一樣直接使用 Helm 安裝：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update

helm show values prometheus-community/kube-prometheus-stack --version 51.6.0 >values.yaml

helm install prometheus-stack prometheus-community/kube-prometheus-stack \
    -f values.yaml \
    -n prometheus-stack \
    --create-namespace \
    --version 51.6.0

values.yaml 倒是有做一些調整：

  • 時區
  • 適應當前 K8s (K3s) 的 Ingress 為 Traefik
  • 對內網 DNS 暴露 Grafana
  • 適應當前 K8s 持久化實例為 Longhorn
  • 從舊 Node 的 Cadvisor 採集資料
grafana:
  defaultDashboardsTimezone: Asia/Taipei
  ingress:
    ingressClassName: traefik
    hosts:
      - grafana.observable.gas.arachne

prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: longhorn
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    additionalScrapeConfigs: |
      - job_name: beta-cadvisor
        static_configs:
          - targets:
            - web.cadvisor.arachne

LLM Observability 重建的當前狀態​

LiteLLM 雖然在 OpenRouter 排行榜蟬聯前幾名，但是實際使用下來給我的感覺不太穩定（經歷過加密 Bug、當機後無法正常復位）。

另一方面，Langfuse 給我的感覺則是相對肥大（服務簇需要同時配置 ClickHouse、MinIO、Redis、PostgresSQL），但是我又沒有使用到裡面的每一個功能。更別提 ClickHouse 就是表面上這次事故的主因。

因此我打算評估其他 LLM Gateway/Observability 方案，目前看上 Bifrost，試用了一下感覺不錯，就是它的資料庫配置稍微有點麻煩，這個部份可能之後再提。