111 地方特考三等 圖書資訊管理(選試英文) 資訊系統與資訊檢索 考古題詳解

核心觀念

本題核心在於考查搜尋引擎（Search Engine）之運作架構——特別是「檢索（Crawling）」與「索引（Indexing）」的階段性差異，以及網站管理員如何透過網路協定與中繼標記控制搜尋引擎行為：

1. 搜尋引擎運作階段：搜尋引擎運作包含「抓取/漫遊（Crawling）」$\rightarrow$「剖析與建立索引（Indexing）」$\rightarrow$「查詢處理與排序呈現（Ranking/Serving）」。要讓網頁不出現於搜尋結果，關鍵在於阻止或移除索引（De-indexing），而非單純阻擋爬行。
2. Robots Exclusion Protocol 與中繼標記：HTML <meta name="robots"> 標籤與 HTTP 標頭 X-Robots-Tag 的 noindex 指令，係告知漫遊器不得將該頁面收錄至搜尋資料庫之標準機制。
3. HTTP 狀態碼（HTTP Status Codes）生命週期：利用伺服器端回應碼（如 404 Not Found、410 Gone），促使搜尋引擎在重訪（Recrawl）時判定資源失效並永久自索引庫剃除。
4. 身分驗證與存取控制（Authentication & Access Control）：限制未獲授權的請求存取內容，使爬蟲無法讀取頁面結構。

解題方法

欲達成「永久禁止網頁出現在 Google 搜尋結果」，必須確保 Googlebot 無法將網頁內容編入索引庫，或強制 Googlebot 將已建立的索引移除。以下採用技術規格最完整、官方規範認可的三種標準作法進行切入：

方法一：使用 noindex 標記（Robots Meta Tag 或 HTTP 標頭）

• 原理說明： 當 Googlebot 抓取網頁時，若偵測到頁面中含有 noindex 指令，便會完全排除該網頁建立索引；若該頁已在索引庫中，則會在下次造訪時將其永久移除。
• 實作方式：

1. HTML 頁面：在 HTML 原始碼的 <head> 區段內加入中繼標籤：

<meta name="robots" content="noindex">

2. 非 HTML 檔案（如 PDF、圖片）或伺服器全域設定：在網頁伺服器回應（HTTP Response Header）中加入 X-Robots-Tag：

X-Robots-Tag: noindex

• 必要條件：該網頁不可在 robots.txt 中被設為 Disallow，必須允許 Googlebot 正常抓取網頁，Googlebot 才能讀取並執行 noindex 指令。

方法二：移除頁面內容並回傳 HTTP 404 或 410 狀態碼

• 原理說明： 直接刪除伺服器上的網頁檔案，或設定伺服器路由針對該 URL 回傳客戶端錯誤狀態碼。
• 實作方式：

1. HTTP 404（Not Found）：代表找不到該網址資源。Googlebot 遇到 404 時，會在複檢數次確認資源不存在後，永久將其從索引中剔除。
2. HTTP 410（Gone）：代表該資源已被永久刪除且不再恢復。Googlebot 對 410 的處理優先權高於 404，能以更快的速度將該網址自索引庫中永久抹除。

方法三：實施存取限制與密碼驗證（Password Protection / Access Control）

• 原理說明： 將網頁置於安全防護機制之後，限制公開存取權限。Googlebot 是一個無登入權限的公開訪客，無法通過驗證流程，因而無法獲取網頁實質內容與建立索引。
• 實作方式：

1. HTTP 基本驗證（HTTP Basic Authentication）：在伺服器端（如 Apache 的 .htaccess 或 Nginx 設定檔）啟用 401 Unauthorized 驗證機制。
2. 使用者帳號登入系統：設定網頁必須經過帳號密碼登入或 Token 授權方可檢視。
3. IP 白名單管制：伺服器僅允許特定受信任 IP 網段連線，對外部連線（包括 Googlebot）回傳 403 Forbidden。

核心觀念

本題為典型的「軟體工程」與「管理資訊系統（MIS）」跨領域基礎核心題，評量考生對現代系統開發方法論以及組織內部資訊架構層級之理解。

1. 敏捷軟體開發（Agile Software Development）：

• 相對於傳統結構化、線性順序之「瀑布式模型（Waterfall Model）」，敏捷開發以「迭代（Iterative）」、「增量（Incremental）」與「高度適應性」為核心。
• 核心準則奠基於 2001 年發布之《敏捷軟體開發宣言》（Manifesto for Agile Software Development）四大價值與十二項原則，強調跨功能團隊合作、面對面溝通、快速交付可用軟體及擁抱需求變更。

2. 六類主要資訊系統（Six Major Types of Information Systems）：

• 依據 Laudon & Laudon 經典組織階層金字塔架構，企業與機構內部依據「作業層（Operational Level）」、「知識層（Knowledge Level）」、「管理控制層（Management Level）」與「策略規劃層（Strategic Level）」劃分為六大資訊系統：
• 交易處理系統（TPS）
• 辦公室自動化系統（OAS）
• 知識工作系統（KWS）
• 管理資訊系統（MIS）
• 決策支援系統（DSS）
• 主管資訊系統（ESS / EIS）

解題方法

本題包含兩大子題，採申論題「破題定義 $\rightarrow$ 核心架構展開 $\rightarrow$ 實例應用（扣合理論與圖資實務）」之標準應試結構作答：

1. 第一部分：敏捷軟體開發

• 破題定義：界定敏捷開發的概念本質及其與傳統瀑布式的根本差異。
• 四大核心價值：完整列舉敏捷宣言之四項對比原則。
• 運作機制：扼要說明以 Sprint（衝刺）為核心的短週期循環運作與代表框架（如 Scrum）。

2. 第二部分：六類主要資訊系統及其應用

• 階層化開展：自組織底層（作業層）逐層向上延伸至頂層（策略層），展現嚴謹之邏輯架構。
• 系統四要素陳述：每個系統依「全稱與縮寫」、「服務層級與主要功能」、「資料處理特徵」、「具體應用實例（兼顧通用商業與圖書館/資訊機構）」逐一說明。
• 彙整比較：以結構化表格整合組織層級、系統名稱、使用者與應用範例，強化作答的視覺組織性。

選項分析

本題為公務人員高等三級暨普通考試／地方特考三等之「申論題」，非選擇題，故無單選選項。針對題目的評分要點拆解如下：

• 子題一（敏捷軟體開發，配分約 10～12 分）：
• 考生若僅回答「開發速度很快的軟體方法」，難以獲得基本分數。
• 必須點出「迭代」、「增量交付」、「回應變更」三大支柱，並精確寫出《敏捷宣言》之四大對比價值。若能帶出 Scrum 角色與衝刺週期，能穩拿高分區間。
• 子題二（六類主要資訊系統及其應用，配分約 13～15 分）：
• 閱卷委員評分關鍵在於「是否涵蓋 Laudon 六大系統架構」。若隨意拼湊 ERP、CRM、SCM 等企業應用套裝軟體而忽略基礎六分法（TPS, OAS, KWS, MIS, DSS, ESS），將嚴重失分。
• 各系統必須明確給出「實際應用場景」，若能結合圖書資訊機構（如讀者借還流通、館藏採購決策、館長策略儀表板），更能彰顯本科系考生的專業深度。

解題技巧

1. 敏捷四大價值速記口訣：

• 「人重於程、碼重於文、合重於約、變重於劃」
• （個人與互動 重於 流程與工具；可用的軟體 重於 詳盡的文件；客戶合作 重於 契約協商；回應變化 重於 遵循計畫）。

2. 六大系統層級口訣：

• 「操（TPS）知（OAS/KWS）管（MIS）策（DSS）戰（ESS）」
• 記憶時由底層向上推導：作業操作 $\rightarrow$ 知識傳播與創新 $\rightarrow$ 例行管理控制 $\rightarrow$ 方案決策分析 $\rightarrow$ 頂層戰略洞察。

3. 常見失分陷阱：

• 廣義與狹義 MIS 混淆：不要將全科名稱的「資訊管理系統（廣義 MIS）」與六大系統之一的「管理資訊系統（狹義 MIS）」混為一談；狹義 MIS 專指以 TPS 資料為基礎、產出結構化例行摘要報表之系統。
• DSS 與 MIS 之區別：MIS 處理「結構化問題」（已知的固定報表），DSS 處理「半結構化或非結構化問題」（具備 What-If、敏感度分析等模型運算）。

【答案】

一、敏捷軟體開發（Agile Software Development）

(一) 定義與核心精神

敏捷軟體開發是一種以人為核心、以價值為導向、採用**迭代（Iterative）與增量（Incremental）**方式推進的軟體工程方法論。其目的在於克服傳統瀑布式開發（Waterfall Model）前期需求僵化、交付週期冗長及無法迅速因應外在環境變動的缺點。敏捷開發將大型專案切分為數個週期極短（通常為 1 至 4 週）的開發階段，透過頻繁驗收與持續交付可用軟體，在高度不確定性的環境中快速獲取利害關係人反饋。

(二) 《敏捷宣言》（Agile Manifesto）之四大核心價值

敏捷開發的核心思維建立於 2001 年所發布之四大對比原則：

1. 個人與互動 重於 流程與工具（Individuals and interactions over processes and tools）：強調團隊成員之間的即時對話與自主協作，勝過僵化的標準程序。
2. 可用的軟體 重於 詳盡的文件（Working software over comprehensive documentation）：以交付可實際運作的系統功能為主要產出，避免過度繁文縟節的規格文件延誤進度。
3. 客戶合作 重於 契約協商（Customer collaboration over contract negotiation）：將客戶視為開發夥伴並持續邀請其參與驗證，而非受限於僵固的合約條款相互推諉。
4. 回應變化 重於 遵循計畫（Responding to change over following a plan）：視需求的變更為常態與競爭優勢，具備隨時調整開發優先級與架構的彈性。

(三) 主要實踐架構（以 Scrum 為例）

敏捷開發最廣泛運用的框架為 Scrum，其運作機制包含：

• 核心角色：產品負責人（Product Owner, 負責需求優先級）、Scrum Master（敏捷教練, 掃除流程障礙）、開發團隊（跨功能自主團隊）。

核心觀念

本題旨在測驗資訊檢索評量（Information Retrieval Evaluation）中兩大經典指標——**求全率（Recall rate）與求準率（Precision rate）**的定義、互補與消長（Trade-off）關係，以及在不同檢索情境與使用者需求（Information Needs）下的相對重要性。

1. 檢索評量公式與列聯表

資訊檢索系統的評量常建立在二元相關性（Binary Relevance）假設上，以混淆矩陣（Confusion Matrix）劃分檢索結果：

• 求全率（Recall Rate, $R$）：系統檢索出的相關文件數，佔資料庫中所有相關文件總數的比例。衡量系統「抓得全不全」、「是否漏檢」。 $R = \frac{TP}{TP + FN} = \frac{|\text{檢索出且相關的文件}|}{|\text{所有相關文件}|}$
• 求準率（Precision Rate, $P$）：系統檢索出的相關文件數，佔所有被檢索出文件總數的比例。衡量系統「抓得準不準」、「雜訊多寡」。 $P = \frac{TP}{TP + FP} = \frac{|\text{檢索出且相關的文件}|}{|\text{所有檢索出的文件}|}$

2. 消長關係（Trade-off）與綜合指標

在常規資訊檢索系統中，求全率與求準率呈現反比消長關係。調寬檢索條件（如使用 OR 布林運算元、擴展同義詞）可提高求全率，但雜訊增加會降低求準率；縮窄檢索條件（如使用 AND、限制欄位）可提升求準率，卻容易遺漏相關文件而降低求全率。為了平衡兩者，常使用加權調和平均數 $F\text{-measure}$： $F_\beta = \frac{(1 + \beta^2) \cdot P \cdot R}{\beta^2 \cdot P + R}$ 當 $\beta = 1$ 時為標準 $F_1\text{-score}$；當重視求全率時令 $\beta > 1$；重視求準率時令 $\beta < 1$。

解題方法

本題為評析型的申論題，題眼為「何者重要？試舉例說明」。解題切入點不可落入「非黑即白」的偏頗陷阱，必須採取**「視檢索情境與任務目的而定（Context-dependent）」**的專業架構開展論述：

1. 破題立論：明確指出求全率與求準率無絕對的優劣或高低之分，其重要性取決於使用者的「資訊需求類型」、「漏檢成本（Cost of Missing）」與「瀏覽負擔（Cognitive/Time Load）」。
2. 情境對比論證：

• 情境 A（求全率優先）：探討「寧可多讀雜訊，絕不可漏掉任何一筆」的高風險、窮盡性檢索任務。
• 情境 B（求準率優先）：探討「只要前幾筆正確即可，不追求全數獲取」的高效率、日常性檢索任務。

3. 引入實例支撐：分別提出具體、具代表性的實務範例進行對比剖析。

情境範例分析

核心觀念

求全率（Recall）衡量相關資料中有多少被搜尋引擎找出；求準率（Precision）衡量搜尋結果中有多少是相關資料。兩者數值愈高，代表該項檢索表現愈好。

題目指定求準率的重要性是求全率的 $2$ 倍，因此評分時應給求準率兩份權重、求全率一份權重。將權重正規化後，求準率權重為 $\frac{2}{3}$，求全率權重為 $\frac{1}{3}$。

解題方法

以加權平均比較兩個搜尋引擎：

搜尋引擎 A：

搜尋引擎 B：