最近在看了一些 AI 文章，注意到有一件事出現多次，就是在探討 AI 應用程式 (apps) 的可觀察性，它是軟體工程的一部分。身為一位什麼都要懂的軟體工程師，來挑戰這個主題吧。

應用程式的可觀察性就是是否能觀察程式運作時的各項數值。比如一項功能是由多個元件串聯執行，若想分析各項元件的執行順序、消耗時間，就需在程式加上記錄這些資訊的程式，上述是一種觀察類型 – trace. 還有 2 種常見的觀察類型：metric, log.

可觀察性在軟體工程中是建議早期規劃的。因為一旦程式上線，使用者開始使用，那麼可能一些開發、測試階段沒遇到的 bugs/issues 就開始出現，這時若沒有任何可觀察的程式運作訊息，對 bugs/issues 就束手無策。接下來只能再補回觀察程式碼，重新上線，但如此一來就會花較多時間，因為需要第 2 批使用者觸發新版程式 bugs/issues，產生觀察訊息，才有除錯的線索 但如此一來可能就會流失較多客戶。

AI apps 也需面臨上線後才出現的 bugs/issues，比如有部分使用者反應 apps 運作很慢。這時有 traces 可查的話，就能分析是 AI apps 的哪一個元件太耗時。AI apps 還有一些要考量的 issues，如 model drift, token count.

接著我就動手實作將我之前寫的一支語意搜尋 backend app

https://github.com/MrMYHuang/demo_langchain_vec

加入 trace 觀察，使用的 trace 標準是 OpenTelemetry OTLP，並使用 Jaeger UI 呈現 trace. 如圖所示，是 backend app 在作搜尋的時間線圖，其中搜尋 Qdrant DB 佔了大部分時間。

「可觀察性」的用途不止用於軟體工程，各領域需要除錯、維修、迭代改進產品都用得上。