還記得學傾角變位法的時候，

背了好多桿端彎矩公式。

兩端剛接、

一端剛接一端鉸接，

還有對稱反對稱。

光顧著看這些公式和名詞，

以為自己好像學會了。

真的開始解題目的時候才發現，

這邊漏了一個負號，

那邊也算錯未知數。

背得滾瓜爛熟的名詞和公式，

怎麼一開始解題，
就變成最熟悉的陌生人。

後來才發現，

不是每個科目和技能，

都可以從專有名詞開始學。

最近我在學 AI，

並不是找一本教科書，

從專有名詞定義開始背。

我是從解決問題出發，

用動詞的方式來學習。

最近這幾個月，

我受到前輩同事的啟發，

想做一個方便的問答系統。

RAG 是什麼？

我一開始也不知道。

我只知道每次工程招標文件都有幾十個檔案，

光是要找到需要的資料，

就花了好長一段時間。

還有自己收集的工程資料，

同業的優良作法，

最近的新工法。

常常看過就忘了。

有時想找資料參考，

又要花很多時間，

才能整理出一個比較完整的答案。

所以我問了一個很簡單的問題：

「有沒有辦法直接問 AI，

就能得到我需要的答案？」

從這個問題出發，

我遇到了很多挫折。

本地模型有時說不清楚、
雲端 API 又偶爾 timeout、

回答會被截斷、

工程標案的內容找不到。

每次出問題，

我不是去查名詞，

而是問 AI：

「為什麼會這樣？」

慢慢地，

我開始理解這些概念。

Embedding，

就是把文字轉成數字向量。

語意相近的文字，

向量也會比較接近。

我不是從定義開始背，

我是從「為什麼中文搜尋找不到我要的」這個問題學會的。

Chunking，

把文件切成小段再嵌入。

一開始我把施工規範硬切成 800 字一段，
後來發現它很可能在句子中間被切斷。

語意不完整，
搜尋時找到的就不是我真正需要的材料。

後來我先把施工規範重新整理，
再把要放進資料庫的內容，
改成問答格式。

相似度提升，
回答品質也穩定多了。

Top K，

從資料庫取回最相近的 K 筆結果。

取太多，

模型的 context 太長，

輸出會提前結束。

取太少，

又可能漏掉相關資料。

這個平衡，

是在一次次測試中調整出來的，

過程中跳出了好幾次通知，

"You are out of messages until......"

看到那行字的時候，
我才知道，

原來付費訂閱也會被系統請去旁邊休息。

現在，

就算資料不在手上，

我也可以在 Telegram 問「某某工程的重要期程」，

幾秒內，就能得到整理過後的回答。

它不會替我做專業判斷，
但至少能替我省下找資料的時間。

最重要的是，

就算是 AI 整理好的資料，

來源還是要確認，

有關專業判斷和責任承擔的問題，

工程師絕對要自己確認。

這個過程讓我體會到一件事：

AI 不會因為你背了很多名詞，

就變得很好用。

真正讓 AI 變得有用的，

是你願意把問題想清楚，

把知識整理好，

然後一次次驗證輸出的品質。

從「回答被截斷」，

到「規範內容太籠統」，

到「各種計畫的提送期限應該寫在一起」。

每一次調整，都要問

「這樣對嗎？」

「有沒有更好的做法？」

「這樣真的能用嗎？」

這種思維，

比背理論名詞重要太多了。

工具是會不斷進化的，

但使用 AI 的思維和態度，

比較不會過期。

你有沒有仔細想過，

自己的工作要如何拆解？

哪些事情可以交給 AI 處理？
哪些地方需要你確認？
哪些責任最後還是要由你承擔？

如果你也想試試看，
不必一開始就想做一套超級系統。

先找一個公司最常被問到的問題，
把答案整理成文字。

解決問題，

就是工程師的起點。