在一人顧問公司應用 LLM
應用的要訣：將任務的範疇縮減、給予總結型的任務
我問了 LLM ：
列舉 10 種最常見的，一人顧問公司應用 LLM 的方式？得到如下的答案：
報告和提案撰寫
市場研究與洞察
自動化回覆與客戶互動
內容行銷與社交媒體管理
演講材料製作
知識管理與檔案整理
個性化客戶簡報製作
合約與法律文件撰寫
創意發想
翻譯與多語言支持
在這 10 項應用裡，只有第 2, 6, 9, 10 四項，我認為實務上可行，而且實務中運用之後，算是有提高生產力，而且同時在產量與品質都有提高。
市場研究與洞察
我有時候會遇到朋友請我給一些策略上的建議。(這種建議我給的不多，因為我主要的業務是做 IT 顧問，而經營管理這一塊則多半是友情協助。)
我通常會用友人的 {公司的官方網站} 與 {公司名稱} 先下這兩個 prompt ：
從網路上現存的資訊，分析 {公司的官方網站} 這家公司。
{公司名稱} 是什麼細分市場的領導者？還有
根據網路上的資訊與 {公司官方網站} 的資訊，用簡短的 2 句話，講出 {公司名稱} 的價值主張。有時候 LLM 會果斷地回答：「某某公司本身可能尚未成為特定利基市場中廣泛認可的領導者。」透過 LLM 幫我對朋友說出這一句話，讓我的感覺好過多了。
知識管理與檔案整理
多數的時候，已經有許多成熟的工具可以輔助知識管理、檔案整理，所以也用不太上 LLM 。
也有少數的例外，比方說：我需要對 Datomic 的 schema 畫出 ER diagram 圖。因為 Datomic 沒有簡單好用的繪製 schema 工具，於是我下這樣子的 prompt：
將以下文本的 Datomic schema 的簡易表示法，轉換成 Mermaid 的 ER diagram 表示法創意發想
我有時滿討厭寫結論的，無論是書的章節又或是一般的文章。有靈感時可以很快地寫完。但是，大約有一半的機率會想不出好的靈感。偏偏我又強烈地覺得，用兩三句話把之前的重點再概述一次的這種中規中矩的寫法，非常無聊。
我有時候會下一個 prompt 來輔助：
接續前文，將結論寫完。這種時候，大約有 99% 的機率，我將會看到一個我無法忍受的結論。當我在寫書，幾乎寫完了一個章節，談論在企業內部導入現代資料棧會是如何如何，組織可能會扺抗創新，該怎麼應對。叫 LLM 幫我寫結論之後，得到了一個正面、鼓舞人心、彷彿反攻大陸都可以成功的那種結論。我看完之後，內心中止不住地咒罵，『你是戒嚴時代打造出來的 AI 嗎？』
受到了 LLM 的刺激後，謬思終於醒來，下筆若有神助地寫下憤世嫉俗的版本：
少數的組織可以引領潮流，但是多數的組織，他們的變革多半是由外部的壓力帶來的。換言之，很有可能無論讀者做了多少的技術研究、提交了多少個版本的行動計畫、在公司內辦了無數次的技術研討會，上級卻始終沒有允諾變革。然而，某一天，當組織的同業一個接一個開始做技術變革時，上級又立刻下達六個月內完成變革的不可能指令。 …
應用的可行性分析
由於 LLM 的本質是資料與統計，如果要讓 LLM 來輔助工作，至少應該考慮兩個原則：
分配給 LLM 的任務應儘可能縮減為完整任務範疇的一小部分。因為大多數的時候，任務都需要人類判斷，除非任務被分解成夠小的部分，否則很少可以完全依賴機器而不需要人類判斷。
儘量讓 LLM 處理總結型的任務 (summarization)，即從多量的資料映射到少量的資料，而不是生成型任務 (generation)，即從少量的資料映射到多量的資料。總結型的任務如果有給予適當的上下文，其實準確度還不錯。
回到文章開頭的 10 種應用，像 1, 3, 4, 5, 7, 8 都是生成型任務，因此常常產生幻覺且錯誤率偏高。產量提昇的同時，會不會同時也降低了品質？
至於最後一項應用「翻譯」，我做了不少的實驗，整體而言算是可用。翻譯是屬於轉換型的任務 (transformation)，即將同樣的資料從一種形式變成另一種形式。多數的時候，我認為算是成功的。少數的時候，則是真的很不行。出乎我意料之外的，在沒有特別設計 prompt 的前提下，翻譯程式語言比翻譯自然語言失敗得多。