111 年 國立臺灣大學新聞學研究所《資訊科學與新聞》

本題主要在考察資料庫設計的基礎概念，特別是如何運用實體關係圖（ERD）來建構一個能支援群眾外包（Crowd Sourcing）資料收集與驗證任務的資料庫。

核心觀念：

1. 實體關係圖（ERD）： 描述實體（Entities）、屬性（Attributes）以及實體之間的關係（Relationships）。
2. 資料庫正規化（Normalization）： 將資料拆分成多個表格，減少資料冗餘，提高資料一致性。
3. 群眾外包（Crowd Sourcing）資料特性： 需要記錄參與者資訊、提交的資料內容、驗證狀態等。

解題步驟：

1. 識別核心實體（Entities）：

   • 參與者 (Participant/User)： 負責上傳照片、進行驗證。
   • 看板 (Billboard)： 實際的選舉看板，包含其位置、照片等資訊。
   • 上傳紀錄 (UploadRecord)： 記錄某位參與者上傳了某個看板的照片。
   • 驗證紀錄 (VerificationRecord)： 記錄某位驗證人員對某個上傳紀錄進行的驗證。
   • 照片 (Photo)： 實際的看板照片檔案。
   • 編碼/標籤 (Tag/Label)： 驗證人員對照片內容進行的編碼或標籤。

2. 定義實體的屬性（Attributes）：

   • 參與者 (Participant)：

     • participant_id (Primary Key, PK)
     • username
     • email
     • registration_date
     • role (e.g., 'uploader', 'verifier', 'admin')

   • 看板 (Billboard)：

     • billboard_id (PK)
     • candidate_name
     • location_description
     • latitude (Optional, for precise geo-tagging)
     • longitude (Optional, for precise geo-tagging)
     • detected_date (Date when the billboard was first detected/registered)

   • 照片 (Photo)：

     • photo_id (PK)
     • billboard_id (Foreign Key, FK to Billboard)
     • uploader_id (FK to Participant)
     • upload_timestamp
     • image_url or image_data (Path to the image file)
     • status ('uploaded', 'under_verification', 'verified', 'rejected')

   • 驗證紀錄 (VerificationRecord)：

     • verification_id (PK)
     • photo_id (FK to Photo)
     • verifier_id (FK to Participant)
     • verification_timestamp
     • is_valid (Boolean: True if verified as valid, False otherwise)
     • decoded_data (e.g., candidate name, estimated cost, date on billboard, etc. - This could be normalized further if complex)
     • comments (Optional notes from verifier)

   • 編碼/標籤 (Tag)： (如果編碼是預設選項)

     • tag_id (PK)
     • tag_name (e.g., 'Candidate Name', 'Campaign Slogan', 'Estimated Cost', 'Date')

   • 照片標籤 (PhotoTag)： (Many-to-Many relationship between Photo and Tag)

     • photo_tag_id (PK)
     • photo_id (FK to Photo)
     • tag_id (FK to Tag)
     • tag_value (The actual value for that tag on that photo)

   備註： 這裡將「編碼」視為一種標籤（Tag），每個標籤有其名稱（如「候選人姓名」），而具體的值（如「候選人 A」）則記錄在 PhotoTag 中。如果「編碼」是指驗證人員輸入的自由文字，則可以直接放在 VerificationRecord 的 decoded_data 欄位。對於「估計花費」這種數值，可以設計成專屬欄位或作為 decoded_data 的一部分。

3. 建立實體間的關係（Relationships）：

   • 一個 Participant 可以上傳多張 Photo (One-to-Many: Participant -> Photo)
   • 一張 Photo 必須由一個 Participant 上傳 (Many-to-One: Photo -> Participant)
   • 一個 Billboard 可以有多張 Photo (One-to-Many: Billboard -> Photo)
   • 一張 Photo 屬於一個 Billboard (Many-to-One: Photo -> Billboard)
   • 一張 Photo 可以被多個 Participant (Verifier) 驗證，一個 Participant 可以驗證多張 Photo (Many-to-Many: Photo <-> Participant, implemented via VerificationRecord)
   • 一個 VerificationRecord 對應一張 Photo (Many-to-One: VerificationRecord -> Photo)
   • 一個 VerificationRecord 由一個 Participant (Verifier) 執行 (Many-to-One: VerificationRecord -> Participant)
   • 一個 Photo 可以有多個 Tag，一個 Tag 可以應用於多個 Photo (Many-to-Many: Photo <-> Tag, implemented via PhotoTag)

4. 繪製實體關係圖 (ERD)：
   （在此無法直接繪製圖形，但會描述其結構）
   ERD 將會包含上述的實體（方框表示），實體內的屬性（屬性名稱列出），以及實體之間的連線（線條表示），線上標示關係的基數（如 1:N, N:M）。

   • Participant (PK: participant_id)
     • username
     • email
     • role
   • Billboard (PK: billboard_id)
     • candidate_name
     • location_description
   • Photo (PK: photo_id, FK: billboard_id, FK: uploader_id)
     • upload_timestamp
     • image_url
     • status
   • VerificationRecord (PK: verification_id, FK: photo_id, FK: verifier_id)
     • verification_timestamp
     • is_valid
     • decoded_data
     • comments
   • Tag (PK: tag_id)
     • tag_name
   • PhotoTag (PK: photo_tag_id, FK: photo_id, FK: tag_id)
     • tag_value

5. 提供假想範例資料：

   假設有兩個參與者：

   • participant_id=1, username='Alice', email='[email protected]', role='uploader'
   • participant_id=2, username='Bob', email='[email protected]', role='verifier'
   • participant_id=3, username='Charlie', email='[email protected]', role='verifier'

   假設有兩個看板：

   • billboard_id=101, candidate_name='候選人A', location_description='中山路與復興路口'
   • billboard_id=102, candidate_name='候選人B', location_description='信義區A58號旁'

   假設 Alice 上傳了一張候選人 A 的照片：

   • photo_id=501, billboard_id=101, uploader_id=1, upload_timestamp='2023-10-27 10:00:00', image_url='/uploads/img_501.jpg', status='under_verification'

   假設 Bob 和 Charlie 都驗證了這張照片，且 Bob 認為是有效的，Charlie 認為是無效的（例如照片模糊，無法辨識）：

本題考察的是系統架構設計能力，特別是如何整合前後端、資料庫，並提供 API 服務，以及對相關軟硬體需求的理解。

核心觀念：

1. 系統架構： 分層設計（表現層、應用層、資料層）、前後端分離。
2. 雲端服務： 利用雲端平台（AWS, GCP, Azure）的彈性與擴展性。
3. API 設計： RESTful API 的概念，用於前後端溝通及對外提供服務。
4. 軟硬體需求： 考量伺服器、儲存、網路、作業系統、開發工具等。

解題步驟：

1. 系統架構設計：
   採用常見的三層架構（或稱 N 層架構），並將前後端分離，以提高靈活性和可維護性。

   • 前端 (Client-side/Presentation Layer):

     • 功能： 使用者介面（網頁），用於使用者註冊、登入、上傳照片、查看驗證狀態、瀏覽新聞內容。
     • 技術：
       • 框架： React, Vue.js, Angular (任選其一)。
       • UI 庫： Bootstrap, Material-UI。
       • 語言： HTML, CSS, JavaScript/TypeScript。
       • 部署： 可部署為靜態網頁（如使用 Netlify, Vercel, AWS S3 + CloudFront）。

   • 後端 (Server-side/Application Layer):

     • 功能： 處理業務邏輯、與資料庫互動、管理使用者、處理 API 請求、生成 API 回應。
     • 技術：
       • API 框架：
         • Python: Flask, Django (REST framework)
         • Node.js: Express.js
         • Java: Spring Boot
         • Go: Gin, Echo
       • 程式語言： Python, Node.js, Java, Go (任選其一)。
       • API 風格： RESTful API。
       • 認證授權： JWT (JSON Web Tokens), OAuth。
       • 圖片處理： Pillow (Python), Sharp (Node.js) - 用於圖片縮放、格式轉換等。

   • 資料庫 (Data Layer):

     • 功能： 儲存使用者資訊、看板資訊、照片中繼資料、驗證紀錄等。
     • 類型：
       • 關聯式資料庫 (RDBMS)： PostgreSQL, MySQL, MariaDB。適合儲存結構化資料，如使用者、看板、驗證紀錄。
       • NoSQL 資料庫： MongoDB (文件型，適合儲存靈活結構的資料，如 decoded_data 的 JSON)，Amazon DynamoDB (鍵值/文件型，可高度擴展)。
       • 物件儲存 (Object Storage)： AWS S3, Google Cloud Storage (GCS), Azure Blob Storage。用於儲存實際的照片檔案。

   • API 服務 (API Gateway / Public API):

     • 功能： 提供外部應用程式或第三方存取系統資料的介面。
     • 技術：
       • API Gateway: AWS API Gateway, Google Cloud Endpoints, Azure API Management。用於管理、保護、監控 API。
       • API 設計： RESTful API (e.g., /api/v1/billboards, /api/v1/photos/{photo_id}/verify).
       • 資料格式： JSON。

2. 雲端服務整合：
   為了彈性、擴展性和降低維護成本，可以將整個系統架構部署在雲端。

   • 計算服務： AWS EC2, Google Compute Engine, Azure Virtual Machines (用於部署後端應用程式)。若使用 Serverless，則可用 AWS Lambda, Google Cloud Functions, Azure Functions。
   • 資料庫服務： AWS RDS (for PostgreSQL/MySQL), Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL/MySQL。
   • 物件儲存： AWS S3, GCS, Azure Blob Storage (用於儲存照片)。
   • CDN (Content Delivery Network)： AWS CloudFront, Google Cloud CDN, Azure CDN。用於加速前端靜態資源和照片的載入。
   • API 管理： AWS API Gateway, Google Cloud Endpoints。
   • 容器化： Docker, Kubernetes (AWS EKS, Google GKE, Azure AKS) - 方便部署和擴展。

3. 架構圖說明（文字描述）：
   （在此無法繪製圖形，但會描述其佈局）

本題旨在考察學生對群眾外包（Crowd Sourcing）在資料新聞領域應用的理解，以及能否發想新的應用。

核心觀念：

• 群眾外包 (Crowd Sourcing)： 運用大量非特定人士（群眾）的集體智慧來完成任務。
• 資料新聞 (Data Journalism)： 運用數據分析、視覺化來報導新聞。
• 資料取得與處理： 思考如何從群眾手中有效地獲取、驗證和分析資料。

解題步驟：

1. 回顧既有案例（若有印象）：

   • 案例一：台灣空氣品質監測 (PM2.5)： 台灣環境保護署雖有官方監測站，但民間團體（如「台灣健康空氣行動聯盟」）曾推動民眾自行安裝或利用微型感測器，將空氣品質數據回傳，形成更密集的監測網。記者可利用這些數據，分析特定區域（如學校周邊、工業區附近）的空氣污染狀況，並與官方數據比對，揭示潛在問題。
     • 資料取得： 民眾自行安裝的感測器數據、手機 App 回報的空氣品質指數 (AQI)。
     • 結果： 報導特定地區的空氣污染熱點、影響範圍，以及與官方監測站的差異，促使政府關注。
   • 案例二：路況回報 (Google Maps / Waze)： 雖然非嚴格意義上的「新聞」，但這是最廣為人知的群眾外包案例。使用者回報交通事故、測速照相等資訊，匯集成即時路況地圖。新聞機構可以利用這些資料，分析特定路段的事故頻率，或報導因交通壅塞導致的社會經濟影響。
     • 資料取得： 使用者透過 App 回報的事故、塞車、施工等資訊。
     • 結果： 提供即時交通資訊，或用於分析交通安全問題。
   • 案例三：選舉資訊收集 (如本題情境)： 候選人看板、文宣的拍攝與標記，用於分析選舉資源投入、文宣內容。
     • 資料取得： 民眾拍攝並標記的候選人看板照片。
     • 結果： 分析不同候選人在不同區域的看板數量、文宣內容的差異。

2. 構思新的 Crowd Sourcing 資料新聞點子：

   主題： 「社區淹水黑點圖」與「鄰里防災韌性地圖」

   新聞主題背景： 隨著極端氣候事件頻繁，台灣許多地區面臨更嚴峻的淹水威脅。官方的淹水潛勢圖通常較為宏觀，難以精確反映社區巷弄的實際淹水情況。透過群眾的即時回報和長期觀察，可以建構更貼近民眾生活的淹水資訊。

   資料收集方式：

   • 建立專屬 App 或網頁平台：
     • 「淹水回報」功能： 當民眾在自家或附近區域遇到淹水時，可透過 App 拍照（包含 GPS 定位資訊）、填寫淹水深度（如：淹到腳踝、膝蓋、腰部）、淹水時間、淹水原因（如：豪雨、排水不良、溪水暴漲）、影響範圍（如：某幾條街、某個社區）。
     • 「長期觀察」功能： 鼓勵民眾長期記錄自家門前的淹水紀錄，即使是輕微積水（如：水窪），也可累積成資料，以了解社區的「慢性淹水」問題。
     • 「防災資源」標記： 邀請民眾標記社區內的防災資源點，如：避難所位置、高地、緊急聯絡電話、社區志工聯絡方式等。
     • 「受災照片」上傳： 收集豪雨或颱風過後，民眾拍攝的災情照片，輔助判斷災情嚴重程度。
   • 結合官方資料： 匯入中央氣象署的雨量數據、地方政府的排水系統資訊、地形圖等，與群眾回報的淹水點進行交叉比對，驗證資料準確性。
   • 鼓勵在地社群參與： 與地方里長、社區發展協會、環保志工團體合作，推廣此平台。

   可能的解釋變項 (Attributes to Collect & Analyze):

   • 地理資訊： GPS 座標、行政區、里鄰。
   • 時間資訊： 回報時間、淹水持續時間、發生事件的日期。
   • 淹水程度： 淹水深度（數值或等級）、淹水範圍。
   • 原因： 豪雨強度、排水系統問題、河川潰堤、地勢低窪。

本題考察的是對「標題黨」現象的理解，以及如何從新聞學和資訊科學的角度分析標題與內文的差異，並提出技術偵測方法。

核心觀念：

1. 標題黨 (Clickbait)： 指使用聳動、誇張、誤導性的標題來吸引讀者點擊，但內容可能與標題不符。
2. 新聞標題與內文的關係： 標題應準確反映內文主旨，但有時為了吸引注意力會有所取捨。
3. 自然語言處理 (NLP)： 用於文本分析、主題提取、語義相似度比較。
4. 機器學習： 可用於訓練模型來辨識標題與內文的差異程度。

Part A: 新聞標題與內文的差異性分析

核心概念： 標題與內文的關係可以是「一致」、「部分一致」或「不一致」。這種差異性是標題黨的關鍵特徵。

分析：

1. 一致的情形 (Consistent)：

   • 直接概括： 標題準確、簡潔地概括了內文最核心、最重要的訊息。例如：
     • 標題：「台灣央行升息半碼，預計將影響房貸族」
     • 內文：詳細解釋升息原因、幅度，並分析對房貸、股市、通膨的預期影響。
   • 引導閱讀，但不誤導： 標題提出一個問題或強調一個關鍵點，引導讀者進入內文尋找答案或更深入的資訊，但提供的資訊與內文是相符的。例如：
     • 標題：「為什麼這個台灣品牌能在國際市場上脫穎而出？」
     • 內文：分析該品牌的創新策略、產品特色、市場定位等，解釋其成功原因。

2. 不一致的情形 (Inconsistent / Clickbait)：

   • 誇大其詞 (Exaggeration)： 標題使用極端、聳動的詞語，但內文的內容並未達到標題所暗示的程度。
     • 例如：標題：「震驚！台灣驚傳史上最大規模食安風暴！」
     • 內文：可能僅是某一家小餐廳的幾位顧客反映身體不適，或僅是接獲檢舉，尚未證實。
   • 斷章取義 (Misrepresentation/Out of Context)： 標題擷取內文中的某個片段或說法，但忽略了上下文，導致意思被扭曲。
     • 例如：標題：「某官員：『這項政策絕對不行！』」
     • 內文：該官員可能是在討論某項政策的「某個執行細節」不可行，但整體政策是支持的，或是在反駁某個錯誤的說法。
   • 製造懸念，但不揭露 (Unfulfilled Curiosity)： 標題提出一個極具吸引力的問題或情境，讓讀者好奇，但內文卻避而不談關鍵資訊，或以模糊不清的方式帶過，甚至沒有答案。
     • 例如：標題：「她消失了十年，結果竟然是因為這個原因…」
     • 內文：可能只是描述她去環遊世界，原因就是「想放鬆」，但並未達到標題所暗示的戲劇性。
   • 標題與內文主題不符 (Topic Mismatch)： 標題和內文討論的是完全不同的主題，標題只是為了吸引流量。
     • 例如：標題：「周杰倫新歌MV曝光！粉絲淚崩！」
     • 內文：可能是在討論某個過氣的明星，MV 根本不是周杰倫的，只是為了蹭流量。
   • 模糊不清的承諾 (Vague Promises)： 標題暗示能提供某種神奇效果或解決方案，但內文內容空泛，缺乏實質資訊。
     • 例如：標題：「學會這招，讓你財富自由！」
     • 內文：可能只是講一些勵志語錄或非常普遍的理財觀念。

總結 A：
標題與內文的關係，理想情況是「精確概括、引導深入」。然而，線上媒體為了追求點閱率，常出現「誇大」、「斷章取義」、「懸念未解」、「主題不符」等不一致情況，這也是「標題黨」的核心特徵。這些不一致的部分，通常是利用了讀者的好奇心、情緒或認知偏誤。

Part B: 技術偵測新聞標題與內文主題一致性

核心概念：

1. 文本表示 (Text Representation)： 將文本轉換為機器可以理解的向量表示（如 TF-IDF, Word Embeddings, Sentence Embeddings）。
2. 主題模型 (Topic Modeling)： 如 LDA (Latent Dirichlet Allocation)，用於從大量文本中提取潛在主題。
3. 語義相似度 (Semantic Similarity)： 計算兩個文本在語義上的接近程度。
4. 長度差異處理： 由於標題極短而內文極長，直接比較可能存在困難，需要採用能處理不同長度文本的技術。

技術偵測流程圖（文字描述）：

graph TD
    A[輸入：新聞標題 (Title), 新聞內文 (Body)] --> B{文本預處理};
    B --> C[提取標題主題/關鍵詞];
    B --> D[提取內文主題/關鍵詞];
    C --> E{計算標題與內文的主題相似度};
    D --> E;
    E --> F{設定閾值};
    F -- 相似度 > 閾值 --> G[標題與內文主題一致];
    F -- 相似度 <= 閾值 --> H[標題與內文主題不一致 (潛在標題黨)];

    subgraph 文本預處理
        B1[分詞 (Tokenization)]
        B2[去除停用詞 (Stopword Removal)]
        B3[詞形還原/詞幹提取 (Lemmatization/Stemming)]
    end
    B --> B1 --> B2 --> B3;

    subgraph 提取標題主題/關鍵詞
        C1[TF-IDF 權重計算]
        C2[關鍵詞提取 (e.g., RAKE, YAKE)]
        C3[標題嵌入 (Sentence Embedding)]
    end
    C --> C1 --> C2; C --> C3;

    subgraph 提取內文主題/關鍵詞
        D1[TF-IDF 權重計算]
        D2[關鍵詞提取 (e.g., TextRank)]
        D3[段落/句子嵌入 (Sentence/Paragraph Embedding)]
        D4[主題模型 (e.g., LDA)]
    end
    D --> D1 --> D2; D --> D3; D --> D4;

    subgraph 計算標題與內文的主題相似度
        E1[基於關鍵詞的 Jaccard 相似度]
        E2[基於詞向量的餘弦相似度 (Average word vectors)]
        E3[基於句子嵌入的餘弦相似度]
        E4[基於主題模型的 KL 散度/Jensen-Shannon 散度]
    end
    E --> E1; E --> E2; E --> E3; E --> E4;

    subgraph 解決長度差異問題
        I[分段處理內文 (Chunking)]
        J[對比標題與內文各段的相似度]
        K[聚合各段相似度得分 (e.g., Average, Max)]
    end
    D -.-> I; I --> J; J --> K; K --> E;

詳細說明與長度差異處理：

1. 文本預處理：

   • 分詞 (Tokenization)： 將標題和內文分割成單詞或詞語。
   • 去除停用詞 (Stopword Removal)： 移除常見但意義不大的詞語（如「的」、「是」、「在」）。
   • 詞形還原/詞幹提取： 將單詞統一為基本形式（如「running」->「run」）。

2. 主題/關鍵詞提取：

   • 標題：
     • TF-IDF： 計算標題中詞語的 TF-IDF 值，取權重較高的詞作為關鍵詞。

本題考察資料視覺化的核心概念，特別是「標準化」在呈現數據時的重要性，以及如何根據數據特性和分析目的選擇合適的視覺化方法。

核心觀念：

1. 絕對數值 vs. 相對數值： 絕對數值（如總案件數）可能受到樣本大小（如人口數、面積）的影響，相對數值（如發生率）更能反映真實的風險或密度。
2. 標準化 (Normalization/Standardization)： 將原始數據轉換為可比較的形式，以消除不同樣本大小的影響。
3. 視覺化選擇： 根據數據類型、分析目的和受眾來選擇最有效的視覺化方法。
4. 地圖視覺化： 在地圖上呈現地理空間數據，常用於犯罪率、傳染病、人口分佈等。

解題步驟：

1. 住宅竊盜點位資訊：哪種方法最適合？為什麼？

• 方法一：案件量 (Counts)

  • 說明： 直接在地圖上顯示每個行政區的總竊盜案件數。
  • 優點： 直觀，容易理解總體案件數。
  • 缺點： 容易產生誤導。人口較多或面積較大的行政區，即使犯罪率不高，其案件總數也可能很高。這使得讀者可能誤認為這些區域的「風險」最高，但實際上可能是「風險最低」的區域（因為人口基數大）。
  • 例如： 如果一個行政區有 100 萬人，發生 100 件竊案；另一個有 10 萬人，發生 50 件竊案。方法一會顯示前者案件數較多，但後者的「案件發生率」 (50/100,000 = 0.05%) 比前者 (100/1,000,000 = 0.01%) 高得多。

• 方法二：案件量 / 人口數 (Risk = counts / pop-at-risk)

  • 說明： 計算每個行政區的「每單位人口竊盜發生率」。
  • 優點： 能夠較好地反映「個人」面臨的竊盜風險。它消除了人口數量的影響，使得不同大小的行政區可以進行有意義的比較。這能幫助民眾了解在特定區域居住的相對風險。
  • 缺點： 如果人口分佈非常不均勻（例如，有些區域是商業區，白天人口多，晚上人少；有些是住宅區，晚上人口多），單純以「總人口」做分母可能不夠精確。但對於「住宅竊盜」來說，通常與「居住人口」的關聯性較高。

• 方法三：案件量 / 面積 (Density = counts / area)

  • 說明： 計算每個行政區的「每單位面積竊盜案件密度」。
  • 優點： 反映了在一個區域內，單位面積的犯罪集中程度。對於城市規劃、警力部署的考量可能有用，例如知道哪些區域的「犯罪密度」高，需要加強巡邏。
  • 缺點： 對於「住宅竊盜」來說，單純以面積作為分母，可能不如人口來得直接相關。例如，一個面積很大但人口稀少的郊區，其案件密度可能很低，但如果人口集中在某個小區域，該小區域的實際風險可能很高。

• 結論：
  對於「住宅竊盜點位資訊」，方法二（案件量 / 人口數） 通常是最適合的。因為住宅竊盜的風險與居住在那裡的人口數直接相關。它能更準確地衡量個人或家庭在特定行政區面臨的相對風險，避免了因行政區大小或人口多寡造成的視覺誤導。方法一（絕對數值）容易讓人忽略風險的相對性，方法三（面積密度）則與「住宅」竊盜的「居住風險」關聯性較弱。

2. 近期 COVID-19 初期傳染：哪種方法較適合？為什麼？

• COVID-19 初期傳染的特性：

  • 傳染病傳播的關鍵因素是「接觸」與「密度」。
  • 初期傳染的重點在於「疫情蔓延的速度」和「單位的潛在傳播風險」。
  • 人口密度是傳播的關鍵驅動因素之一，人口越多，潛在的接觸點越多，傳播越快。

• 分析：

  • 方法一（案件數）： 在初期，病例數會快速增加。顯示總病例數可以快速了解疫情的嚴重程度和規模，例如哪個地區「總病例數」最高。
  • 方法二（案件數 / 人口數）： 這能計算出「感染率」或「發生率」。在疫情初期，這非常重要，因為它能告訴我們哪個區域的「個人」面臨的感染風險最高。例如，一個有 100 萬人口的城市出現 1000 例，另一個有 10 萬人口的城市出現 500 例。方法二能顯示後者 (500/100,000 = 0.5%) 的感染率遠高於前者 (1000/1,000,000 = 0.1%)，這意味著後者可能存在更嚴重的社區傳播或更早爆發。
  • 方法三（案件數 / 面積）： 這可以衡量「單位面積的傳播密度」。在人口稠密的城市區域，即使總人口數不多，但如果病例數集中在一個小區域，其密度會很高。這有助於識別高傳播風險的「熱點」區域，例如人口密集但衛生條件較差的區域，或特定場所（如辦公室、學校）的局部爆發。