Write-time vs Read-time Compute

一個經典的軟體工程 trade-off：處理資料的成本要在寫入時付，還是讀取時付。

Write-time compute

在資料寫入（或 ingest）時就做好處理、轉換、聚合。後續讀取便宜且快速。

• 適合讀取頻繁、寫入較少的場景
• 缺點：寫入慢、需要維護預處理的產物
• 例子：karpathy-llm-wiki、search index、pre-computed reports

Read-time compute

資料原樣儲存，在讀取/查詢時才做處理和聚合。

• 適合寫入頻繁、查詢模式多變的場景
• 缺點：每次讀取都重複計算，慢且不一致
• 例子：RAG、ad-hoc SQL queries、log scanning

中間產物的可解釋性

Write-time compute 的產物不一定對人類有用。向量資料庫（RAG）的中間產物是 vectors — 只有機器能讀。而 LLM Wiki 的中間產物是 markdown — 人機皆可讀、可修正、可學習。同樣是 write-time compute，產物的形式決定了人類能否參與。見 llm-wiki-vs-rag。

LLM 改變了什麼

Write-time compute 最大的成本一直是維護。預處理的產物需要持續更新才能保持正確。LLM 讓這個維護成本趨近於零 — 這讓 write-time compute 在知識管理領域變得實際可行。