> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2025/w45-thoughts-from-participating-in-a-data-compression-competition.md).

# W45-參加數據壓縮競賽的感受

參加了大模型小社區的數據壓縮競賽，用了大半天時間就完成交卷。什麼水平還要等等看別人的提交，但用 AI Coding 的完成速度是真快呀。

這次用了 Windsurf 的 Codemap，很快就讀懂了倉庫。AI Coding 的大多數產品集中在輸出端，忽視了人讀得更慢、更亂的問題。當生成的速度逼近實時，認知輸入端的延遲就成了新的性能瓶頸。像 Codemap、Deepwiki 這樣的工具，是輸入端的增強器，幫助工程師快速建立 mental model。

數據壓縮的理論基石是信息論。香農定義的信息量，用於度量不確定性的消除，不確定性越高，信息熵越大。能有效消除不確定性的部分，才是真正的信息載荷。可預測、重複的部分屬於冗餘，數據壓縮的目標是減少冗餘、提升編碼效率。

拿到題目後，想到了三種思路，對應三個層次的壓縮邏輯。

**第一種思路是語義壓縮，結構化摘要。**&#x5C0D;數據做常規分析、消除冗餘。我提交的版本用的就是這個思路，主要策略包括：

1. 列表聚合：消費、行為、位置等長列表按時間窗口或類型聚合，只保留核心指標（訂單數、平均客單價、停留天數等）；
2. 語義摘要：文本類數據（對話、搜索等）通過正則與模式抽取，生成 top\_issues、top\_keywords 等高價值線索；
3. 統一清洗：利用通用工具（safe\_json\_list、日期解析、字段歸一化），讓不同來源的髒數據在統一框架下被壓縮和解釋；

**第二種思路是編碼壓縮，符號級優化。**&#x901A;過統計概率生成更高效的詞表映射，用更短的符號表達高頻內容，類似哈夫曼編碼。但問題是壓縮後的數據要交給大語言模型使用，如果模型沒見過這種符號體系它就看不懂。哪怕把編碼規則一併提供，context 的開銷估計也不會減少，相當於把轉譯工作也交給了大模型。所以這個思路的實現需要重新訓練一個專屬模型，成本極高。

**第三種思路是工程壓縮，Context Engineering 的方向。**&#x5728;實際生產中，單純從數據壓縮的角度節省 context 空間屬於一種策略，放在 Context Engineering 下可以找到更多有效策&#x7565;**。**&#x8B93;大模型編寫查詢語句、調用 RAG 等工具，把得到的統計信息作為輸入，再加上高壓縮比的壓縮算法，最終效果應該會成倍放大。
