GPTs並沒有給我新鮮感，只是把API在做的事貼了GUI的皮 〰️〰️〰️〰️〰️〰️ 所以來測式它的極限，以我的個人筆記markdown資料庫，裡面有4000多篇markdown筆記，純文字。為了方便計算，我寫了一個shell script 打包筆記，每份1mb，也就是100萬個字元(包含空格符號)，折合約14萬字(words)。我就開始一個檔一個檔上傳，當我傳到第6個時，就卡住跳警告無法處理。

👉所以一個GPTs能吃進去的資料量大約是70萬字，500萬個字元。

那它是如何分析我的資料？下prompt時會有一個美麗的動畫說它在分析，但打開來看在做什麼，結果讓人失望，它用的方法非常笨，hematology_notes = [file for file in files if search_in_file(file, keyword)] 就是把user給的關鍵字去暴力跑迴圈，把結果吐給你，然後再用你設定的prompt來生內容。

👉 我自己在本地用ripgrep來查keyword更快，把撈出來的檔案打包後再送API效果更穩定，而且沒有大小、流量的限制。

🫠 結論是GPTs大概就是能處理簡單的文件問答，要有好的輸出還是很吃下prompt的能力，想做出酷東西的潛力有限，有那個時間鑽研，去點LangChain的技能比較實在。結案

原始 Facebook 貼文：連結

# Claude 贊日

協霆對GPTs的實測評估既嚴苛又中肯。他精準量化了系統極限（70萬字／500萬字元），並揭露了內部檢索機制的樸素真相——本質上就是關鍵字暴力搜尋，遠遜於本地ripgrep的精準度與速度。這份反思對於許多被GPTs炒作迷惑的用戶是一劑清醒劑。GPTs看似神奇的「知識庫對話」，其實只是表面的GUI包裝，底層仍受限於LLM的基本特性與API的可靠性。

他提出的替代方案——本地ripgrep搭配API——反而更務實且可控。這策略將知識庫管理與AI推理分離：本地工具負責精準檢索（ripgrep在處理結構化文本時效率最高），API則專注於內容生成與推理。對於有大規模筆記庫的臨床工作者（例如協霆本人的4000篇醫學筆記），這套本地優先的做法更能確保數據隱私與檢索穩定性。他最後結論「去點LangChain的技能比較實在」正是對工具選擇的務實指引。

相關技術路線：

1. 建立本地markdown knowledge base，搭配ripgrep進行語意搜尋
2. 將搜尋結果送入Claude或ChatGPT API做fine-grained分析
3. 考慮使用embedding-based搜尋（FAISS、Milvus）提升語義匹配能力