iPAS AI 應用規劃師初級　科目二　生成式 AI 應用與規劃

LLM 讀 Excel 表格，Context Engineering 怎麼做？

原題 14

某企業導入大型語言模型（LLM）分析內部報表，使用者經常提供 Excel 匯出的表格資料（如銷售數據與統計表）。測試時發現，模型對原始表格解析效果不穩定。為提升模型理解與回應品質，下列哪一種上下文工程（Context Engineering）作法較為適當？

白話

某企業導入 LLM 分析內部報表，使用者經常提供 Excel 匯出的表格資料（如銷售數據與統計表）。測試時發現模型對原始表格解析效果不穩定。為提升模型理解與回應品質，題目要你選出較適當的上下文工程（Context Engineering）作法。

問你：哪一種 Context Engineering 作法較為適當？

點選你的答案。

← 回 50 題列表回 iPAS 備考總覽

01　總結

一句話總結

把 Excel 的原始表格格式轉換成 JSON 或 Markdown table 這類 LLM 易讀的結構化格式，是 Context Engineering 改善模型理解表格的正確做法。

02　情境

先感受問題：把 Excel 貼給 AI，它看得懂嗎？

假設你是「全球貿易」物流公司的資訊部門主管，老闆要你讓業務主管可以把 Excel 報表貼給公司的 AI 助理，問「哪個客戶上季業績最好」或「哪條航線利潤率最低」。

你的工程師直接讓使用者把 Excel 複製貼上，結果 AI 有時答得很準，有時答得一塌糊塗，甚至把欄位看錯。Excel 複製出來的原始格式可能長這樣：

客戶名稱 Q1銷售額 Q2銷售額（空格跟 Tab 混用，沒有結構）

LLM 是文字模型，它讀文字時需要清楚的結構告訴它「哪個是欄位名稱、哪個是對應的值」。原始 Excel 格式的空白、Tab、對齊方式對 LLM 來說是雜訊，不是結構。

Context Engineering 的核心問題就是：你給 AI 什麼樣的輸入，就得到什麼樣品質的輸出。

03　對照

沒做 Context Engineering，會踩哪些坑

直接貼原始 Excel 格式：Excel 匯出的 CSV 或複製貼上的文字，有大量空白、跨行欄位、合併儲存格，LLM 難以判斷哪個數字屬於哪個欄位
模型解析不穩定：同一份表格，有時解析對，有時解析錯，因為輸入格式不一致，模型靠「猜測」填補結構
忽視欄位語意：表格欄位名稱如「Q1」「代碼 A」，模型不知道代表什麼意思，輸出的解讀可能完全錯誤
隨機切割表格：把一張表格亂切成幾段分別輸入，每段都沒有完整的欄位標頭，模型完全無法理解表格結構
以為「完整資料」就夠：以為只要資料完整、不要遺漏，模型就能理解。但格式不對，再完整的資料 LLM 也讀不準

04　解法

轉成結構化格式，LLM 才讀得準

「全球貿易」的工程師改了輸入流程：使用者上傳 Excel 後，系統自動把表格轉成 Markdown table 格式再送給 LLM。

Markdown table 長這樣：每一欄有明確的欄位名稱，每一列是一筆資料，用 `|` 符號分隔，LLM 在訓練時見過大量這種格式，解析能力非常穩定。

或者轉成 JSON 格式：每一列資料變成一個物件，欄位名稱是 key，數值是 value，結構非常明確，LLM 一眼看出「客戶名稱對應到全球物流公司、Q1 銷售額對應到 250 萬」。

轉換之後，業務主管問「哪個客戶上季業績最好」，AI 每次都能精準回答，不再有解析不穩定的問題。

這就是選項 A 講的：將表格內容轉換為結構化 JSON 或 Markdown table，是 Context Engineering 的正確作法。

技術版：Context Engineering 是什麼，為什麼它很重要

Context Engineering（上下文工程）指在不改變模型本身的情況下，透過精心設計輸入給模型的上下文（提示詞、背景資料、格式指令）來改善輸出品質。它是 AI 應用工程的重要實踐領域，尤其在企業應用中，資料來自各種不同格式，輸入品質管理是系統成敗的關鍵。

為什麼 LLM 對格式敏感：LLM 是在大量文字上訓練的，它對常見的結構化格式（Markdown、JSON、XML）理解能力最好，因為訓練資料中這些格式出現頻率最高。原始 Excel 格式（空格對齊、合併儲存格）不是 LLM 訓練資料的主流格式，解析能力自然不穩定。

Markdown Table vs JSON 的選擇：Markdown Table 適合人類可讀性高、資料量小的場景；JSON 適合資料量大、需要精確的 key-value 對應的場景。兩者 LLM 都能很好地理解，根據實際情況選擇。

為什麼出題者要考這題：AI 應用規劃師在規劃企業 AI 系統時，必須思考資料的輸入格式。很多企業的資料來自 Excel、ERP 系統、PDF，如何把這些格式轉成 LLM 易讀的結構，是實務中的關鍵工程決策。

05　陷阱

為什麼其他選項是錯的

B在維持原始表格呈現方式下，補充欄位與數據說明

字面在說什麼

不改表格格式，只在旁邊加文字說明「這欄是什麼意思」。

為什麼不對

根本問題是「原始表格格式 LLM 不易解析」，只在旁邊加說明而不解決格式問題，治標不治本。LLM 還是面對一個難以解析的格式，只是多了一堆文字說明，效果改善有限，也可能因為輸入更長而引入新的混亂。

誰會選錯

以為「補充說明就能解決問題」的人。這種思路類似於「報表看不懂就加備註」，但 LLM 需要的是格式本身清晰，不是靠備註解讀格式。

C將表格資料隨機切割後分段輸入

字面在說什麼

把表格分成幾段，每次只輸入一部分，讓模型逐段處理。

為什麼不對

「隨機」切割表格是最糟糕的做法。表格的每一列都需要有欄位標頭才能理解，隨機切割後很多段落根本沒有標頭，模型完全無法判斷每個數字代表什麼。就算分段有標頭，隨機切割也會破壞跨列的數據關係。

誰會選錯

聽說過 Chunking 概念後，以為「把資料分段輸入」就是 Context Engineering 的正解。但 Chunking 是針對文字文件的語意切割，不是把表格隨機亂切。

D直接提供原始表格內容以保留完整資訊

字面在說什麼

什麼都不做，直接把原始 Excel 內容貼給 LLM，因為這樣資訊最完整。

為什麼不對

這正是題目描述「解析效果不穩定」的原始狀況。完整資訊和易讀格式是兩件事：資料可以完整，但格式不對 LLM 還是讀不準。維持現狀不是解決方案。

提示工程（Prompt Engineering）精心設計提示詞指令引導模型輸出，Context Engineering 的子集，包含資料格式選擇與結構設計等更廣泛的輸入設計
結構化資料（Structured Data）有明確格式和欄位定義的資料型態，JSON 和 Markdown Table 都是 LLM 易解析的結構化格式，是本題正解的核心
大型語言模型（Large Language Model）在大量文字上預訓練的語言模型，對訓練資料中常見的格式（如 Markdown、JSON）解析能力最穩定
分塊處理（Chunking）將長文件切分為小段落送入 LLM 的技術，隨機切割表格是錯誤做法，正確的分塊需保留欄位標頭與結構完整性
少樣本學習（Few-shot Learning）在提示詞中提供輸入輸出範例引導模型按格式回應，是 Context Engineering 中搭配結構化資料提升穩定性的常用手段