大型語言模型（LLM）與圖像生成 AI，在數個月內快速發展。如今我們可以簡單透過 API 串接，就做出一個 AI 應用。這在幾年前難以想像，也讓具備程式技能的開發者可以發揮所長，快速打造符合自己需求的小專案。
不過，要從實驗性質的 side project 發展成一項產品給更多人使用，還有許多要考量的部分。如果你正在考慮讓一個 AI side project 產品化，本文提出了六個思考點，幫助你判斷與理清思路。
GPT 3.5 推出不久後，為了熟悉 API 串接，我做了一個 AI 塔羅牌解讀服務。因為是練習，當初決定從單純的題目著手，過程中卻發現，AI 應用的難度反而在程式開發以外：如何將 AI 融入產品體驗、如何管理 prompt，甚至是「我真的該用 AI 嗎？」這些問題我尚未全部解決，本文提出的六個思考點，是我在嘗試搭建產品的過程中反覆自問的問題。
延伸閱讀：5 個找尋 AI 應用點子的網站，快速了解趨勢與產品定位
一、是否解決了真正的問題？
思考 AI 應用產品化時，最核心的議題便是「這解決了什麼問題？」
舉例而言，「AI 摘要」或「和文件對話」是最早出現的服務。如果想打造這類型應用，必須先思考自己解決了什麼問題：是讓「還沒有讀過文章的人，快速理解並掌握文章」，還是「已經讀過文章的人，不必自己整理筆記」？又或者是「讓人透過摘要，判斷這篇文章是否值得一讀」？釐清想要解決的問題後，才能不斷深入探索，做出能夠解決問題的應用。
另一個常見的思路是「套殼」，也就是提供和 ChatGPT 相似的服務，只是改進 UI，或加入延伸功能（如：快速選擇 prompt）。
在 ChatGPT 剛發佈時，尚有巨大的資訊差可供套利，許多手腳快的開發者，就藉著在 App Store 上架套殼版 ChatGPT 而賺了一筆。但是一年多過去，ChatGPT 也提供自己的 iOS app，現在競爭已經非常激烈。套殼 AI 應用並非不能做，只是難以長久經營，而更像是炒短線。
若想長久經營，發想點子時可以從只服務一小群人的利基型應用著手。因為小型利基市場不太會被 OpenAI 注意到，但是顯而易見的基礎建設（infrastructure）與延伸應用，OpenAI 遲早會進去做。
二、AI 是解決問題最好的辦法嗎？
由於 AI 能力廣泛且強大，我們很容易陷入「拿著錘子，看什麼都是釘子」的思維。回到上一節的例子，許多產品提供 AI 摘要——然而如果單純只下直覺的 prompt，現行的 LLM 並不擅長摘要。面對一篇有精妙比喻與特殊洞見的文章時，AI 時常會略過中間的邏輯思路，將其改寫成陳腔濫調。
又比如，假設我們想做一個英語學習的應用，如果一直緊盯著 AI，或許會很快想到「讓 AI 扮演英文老師，生成教材與題庫，並回答學生的問題」。
但是，坊間已經有無數英語學習的教材與題庫，如果想解決的問題是英語學習，並不一定要讓 AI 自行生成教材。當學生有疑問，題庫提供的解釋足以應付絕大多數的情境；此時加入 AI 解釋，要是回答的立場不堅定，或是超過範圍提供過多延伸，反而可能讓學生困惑。
從 side project 到產品化的過程中，我們的目標不再只是做出一個 AI 應用，而是解決真實情境的問題。各領域業界採用的現行解法，不一定比 AI 差，要小心別「為了 AI 而 AI」。從 AI 出發解決問題，有時可以產生新的思考突破，有時卻會成為盲點。
三、結果不合預期怎麼辦？
AI 模型在生成內容時，結果並非百分之百可控的。即使盡可能讓回應穩定，仍然需要事先設想，當生成內容超出控制，產品應該如何自我調整。
例如要求輸出 JSON 格式，儘管大多數時間都能正確生成，卻需要應付少部分失敗的案例（可能是多了一層括號或逗點）。如果內容是文字頁面，此時改用 Markdown 會更有彈性，也能減少處理錯誤時的複雜度。
另一種情境是，儘管已經調整好 prompt，內容卻仍然可能不完美。我在做塔羅牌解讀服務時，就遇到了這樣的狀況。GPT 有點太喜歡說教了，不論我如何下 prompt 禁止，AI 仍然會時不時出現「請記住⋯⋯」、「我完全理解⋯⋯」、「祝你好運！加油！」等看了會有些心煩的句子。
讓許多開發者不太適應的是，AI 的回應內容無法窮盡測試。隨著模型改變，也需要不斷應付新發現的極端案例（edge case），這是與過往開發軟體服務時最大的差別。一旦升級或切換模型，原本的 prompt 可能不再有好的效果，回傳結果也充滿未知。因此，開發者需要預留更多時間測試，並系統化比較不同模型間的輸出差異。
四、如何管理 Prompt？
Prompt 是與 AI 模型溝通的主要界面，會經過多次微調與迭代。製作 AI 應用時，管理 prompt 是一項重要的工作。在架構面，需考慮如何讓程式碼方便地切換 prompt 版本，並在遇到問題時回滾（rollback）到上一版。若是製作多國語言的版本，還得考慮：要直接用目標語言寫 prompt，還是先全部輸出英文後，再翻譯成指定語言？
此外，有兩個問題也需要注意：Prompt Injection 與 Prompt Leak。前者是指透過在 prompt 內加入特殊的句子，讓 AI 產品執行原先預定任務以外的事。後者則是透過 Prompt Injection，問出該產品背後的 prompt。
這兩個問題都無法完全避免，但如果想長久經營產品，基本的防護不能省。同時，也因為 Prompt Leak 防不勝防，prompt 不可能是營業機密或護城河。競爭對手幾乎不用費太大功夫，就可以問出產品的 prompt。
五、如何處理資料隱私權與安全性？
Prompt Injection 延伸的下一個問題是隱私。由於 Prompt Injection 無法完全阻擋，在製作 AI 應用時，需要限制 AI 的資料存取權限，以避免使用者能透過 Prompt Injection，輕易取得其他人的資料。
如果是提供企業端產品，或有法遵需求，隱私權就變得更加重要。可以透過一個模型做前處理，隱藏輸入與輸出端的個人識別資訊（PII）。比如「客戶名為黃小嘉，住在台北市基隆路，電話號碼為 0912345678」，會被改為「客戶名為〈姓名〉，住在〈地址〉，電話號碼為〈電話〉」。
除此之外，也需要思考安全性。如果使用者輸入具有傷害性的內容，可藉由事先處理，決定是否要繼續執行。比如，如果做的是陪伴 AI，而使用者透露了自我傷害、傷害他人、危害公共安全等意圖，此時與其交給 AI 自由發揮回覆，讓系統預先攔截並採取處置會更加適當。
延伸閱讀：關於隱私與安全性，可以參考這篇文章〈Balancing Innovation With Safety & Privacy in the Era of Large Language Models (LLM)〉
六、如何定價？
產品化之後，下一步便是商業化。AI 產品是變動成本而非固定成本，每次 API 呼叫或 GPU 運算都需要費用，因此不適用於一次買斷的商業模式。
一種作法是訂閱制，觀察每個使用者的平均成本，並抓出毛利、往上定價。另一種作法則是實支實付（pay as you go），用多少付多少。這個做法的優點是，如果有大客戶（如用量大的企業客戶），營收的天花板很高；缺點則是相對不穩定。當然也可以走混合制：訂閱者可獲得一定量的點數，如果超過用量，則需額外購買點數。
不同的定價方式間沒有孰優孰劣，而是需要聆聽客戶的聲音，反覆修正並制定適合自己客群的計價方式。
剩下的就不是 AI 的問題了
當你走到第六步，恭喜你，原先的 side project 已經是更完整、具備商業潛力的產品了！接下來，將會面臨維護、客服、成長等新創事業經營的挑戰，而這超過了本篇文章想要討論的範圍。
當然，side project 不一定要讓其他人付費使用，只要能夠探索與學習新技術，本身就非常有價值，也可能帶來社群上的互動與機會。我所製作的塔羅牌服務也尚未處理完所有問題，其中使用情境、定價與隱私權，是我認為相當棘手的部分。正因如此，目前仍然維持在興趣專案的狀態。
希望本文提出的六個思考點能幫助你在產品化過程中釐清思緒。說不定你的 side project 其實蘊藏著無窮的商業潛力，正等待被打造成一個好產品！
【GenAI Engineer: LLM 應用開發工作坊】向專家學習，快速掌握完整 LLM 技術和 AI 應用的多項案例
