# 如何寫好論文與嚴謹的科學研究，研究方法
https://jyywiki.cn/ISER/2024/experiment-design.pdf

## 研究公式

在制定研究計畫這一件事情通常是和寫論文一起進行的，舉例來說，論文中要寫的內容通常在做實驗的時候或是在做研究的時候就要考慮了

### 關於論文的術語以及名詞使用
盡量使用一致性的術語以及名詞
ex: experiment/evaluation, technique/approach ...

使用任何概念之前應該要先進行定義
- 每一個關鍵的概念或是名詞都應該被定義，如果有未定義的概念就應該被丟棄
- 每一個概念或是關鍵名詞在整篇論文中都應該具有相同的意義，假設論文中有程式碼等等，則程式碼中的變數應該也要具有相同的意義
- 每一個定義的概念都應該是數學上可以表達或是機器可計算的

### 論文問題研究
我在這個工作中我應該要解決的問題，也就是定義問題的 Scope，什麼問題是我可以解決的，我能解決的東西適合應用在什麼樣的場景，是在怎樣的 workload 下，這個 workload 是否真實存在，什麼問題是我不能解決的，也就是我的解法的限制

切勿誇大

對於研究的問題，需要提供具體的證據說明為什麼我們需要新的努力

範例: 必須提供具體的證據說明，現有的技術或是方法為什麼不足，並強調需要新的研究努力
例如: 可以找到現有方法的缺陷，像是效能不足，或是不是用於某一些新出現的 workload，資源浪費等等，或是用數據，實驗結果說明問題的嚴重性

避免出現不具體，空泛的說明，例如避免出現 在某種情況下可能會出現問題 這種模糊的說法，而是要具體明確的描述在哪一些情況下會出現問題

通常對於問題應該放在引言的地方，幫助讀者快速的了解研究背景以及核心問題，在引言中，通常以簡潔的方式呈現，突出問題並吸引注意力

如果我們提出的問題涉及多個技術的比較或是需要深入討論，應該要獨立出一個章節，像是 Case Study 之類的，在 Case Study 中分析上面提到的技術的優缺點

### 關於洞察力
指的是研究提案中最具有價值的核心觀點或是新穎的發現，需要解釋為什麼你的方法可以有效的解決研究問題，而現有的工作無法做到

洞察力的根本源自於對於研究問題的深入理解，概念上就如同第一性原理一樣，例如發現到某個被忽視的重要模式或是趨勢，提出一種視角去看待問題，從而突破現有方法的限制

洞察力應該直接和核心的研究問題相關，展示如何對問題的本質進行處理，而不是僅僅在應用層面進行改進

洞察力應該關注於研究方法上的創新，而不是技術時線上的細節或是工程面的改進，如新的方法論如何更好的處理問題，而不是說明如何優化程式碼或是提高效率。洞察力一般會體現在研究方法的進展上，例如提出新的框架，理論或是模型等等，而這一些東西應該要可以回答為什麼這個提案是有效的

## 常見論文錯誤
- 選擇一個表面上看起來沒有人研究過得題目，但實際上可能是因為這個題目並沒有研究價值，或是在技術上很難去解決，因此沒有被深入研究
- 應對方法: 深入了解問題，查閱相關文獻，確保你的題目是一個未被解決的問題，而不是被忽視的低價值問題
- 問問自己 為什麼這個問題之前沒有人解決？如果是因為技術挑戰太大或是需要龐大的資源，需要展示如何去克服這一些問題

- 在論文中提出自己的貢獻以及結論時，沒有提供足夠的證據或是數據來支持這一些說法，會讓人覺得實驗不夠嚴謹
- 應對方法: 提供實驗結果，數據分析或是理論推導作為證據，說明自己的方法有效並且優於現有的方法
- 在論文中明確說明如何支持你的主張

- 把理論框架和具體實做混為一談，或是依賴於實做細節來支撐整個提案，這會導致論文的理論基礎方面不夠扎實
- 應對方法: 確保提案在理論框架層面是健全且合理的
- 框架應該要有明確的數學證明以及推導，理論依據等等，實現並不重要，實現只是用驗證框架的方法
- 強調方法論，例如新的模型或是演算法，說明如何解決問題，而不是展示實驗結果而已

## 關於實驗
- 實驗不是列出結果而已，不是單純的描述實驗步驟和列出結果，缺乏深度的設計和分析，這樣實驗內容並無法說服讀者，也無法展現研究的嚴謹性
- 正確作法: 明確描述實驗目的悍藥回答的核心問題
- 闡述如何通過實驗設計來驗證假設，控制變量來檢測變量的影響，或是比較不同方法的結果
- 實驗設計應該明確定義實驗問題，如方法 A 是否比方法 B 有效，設計實驗回答這一些問題，而不是單純收集數據
- 定義清楚獨立變量，也就是實驗操作的因素，以及依賴變量，也就是測量的結果，控制干擾因素，也就是混搖變量，保證實驗結果的精確性

- 實驗最後重要的部份，是討論潛在的威脅
- 概念深度: 實驗是否正確的量測研究問題的核心，是否存在操作上的偏差，例如如果研究算法的效率，那麼運用的測試集是不是能夠真實的反應目標使用場景
- 內部深度: 實驗結果受到其他為控制變量的影響，如硬體配置，軟體版本等等，未控制的變量是否影響結果
- 外部參度: 實驗結果是否可以推廣到其他情境或是其他的資料集，結果是否適合在其他不同的應用場景
- 結論效度: 結論是否基於合理的統計分析和數據？是否有數據不足或是過度推論的問題

對於電腦科學，我們大部份進行的都是比較的實驗

獨立變數 (Independent Variables): 可控的因素，如不同工具或是算法選擇
依賴變數 (Dependent Variables): 測量結果，例如效率，準確性，資源使用量
混搖變數 (Confounding Variables): 可能影響結果但是沒有控制的變數，如硬體環境或是數據集的特性


### 對於實驗的靈魂拷問，A 是否比 B 更好？
- Why would we expect it to be better? 解釋為什麼有理由相信 A 比 B 好，回答重點放在基於理論，過去的研究，或是工具的設計以及特性，說明 A 的優勢，如 A 使用什麼算法，在理論上能更高效的處理數據
- Better at doing what? 需要明確表示 A 在什麼方面比較好，如在準確性比較好之類的
- Why do we need to know? 闡述研究的價值以及意義，回答重點放在解釋這個比較的實際應用或是學術貢獻，如選擇更優的工具降低生產成本，有助於理解不同技術的使用場景
- Better in what way? 具體化 A 的優勢所在，例如運算速度提昇 20%，所需要資源減少一半等等
- What will we do with the answer 確認比較結果或是比較的用途，然後根據這個用途決定下一步行為，如我們會根據這個結果...
- Better in what situations 界定使用範圍 如在高併發情況好，或是適合處理結構化資料等等

設計實驗時，還需要考慮樣本問題
- 對於研究樣本，這個樣本是否有代表性？是否可以明確說明樣本來自於哪一個群體，例如選取該樣本來自於全球工程師的代表性資料，或是解釋或什麼選擇該樣本，如該群體最能夠反映出目標使用場景
- 對於樣本是否有代表性，需要說明，如果不具有全面性，需要表示樣本僅來自於特定國家，不完全代表全球趨勢，或是樣本如何產生，如隨機抽樣等等

### 研究範例
學生名子: stu
主題: Merging stakeholder views in model-driven development
學生狀態: 2 years into his PhD study, Has built a tool, Needs evaluation

這個主題的意義
- 挑戰: 模型驅動開發涉及多方利益相關者，例如開發者，客戶，設計師等等，他們的需求和視角可能存在衝突或是差異
- 目標: 無論是基於方法論或是工具，目標都是協助整合這一些不同的視角，從而開發出真正有用的產品以及增加產品開發的效率

學生狀態: 博士班研究已經進行兩年，處於工具開發完成，進行結果評估的階段
- 挑戰: 研究進入中後期，通常需要將理論或是工具應用於實際的應用場景去驗證工具的價值，需要說服讀者或是審稿人工具的有效性以及實用性

#### 關於 stu 開發的工具如何進行評估
- 獨立變數: Stu-merge 與 Rational Architect (RA)，探索 Stu-merge 是否在特定任務上優於 RA
- 依賴變數: 正確性，測量工具生成的合併結果是否正確。速度，完成合併任務需要多少時間。評估，測量使用者對工具的喜好程度以及滿意度
- 控制變數: 任務，內容是兩個利益相關者模型中的合併圖，對於合併圖，需要固定任務類型以排除其他變數對於結果的影響。接著是受試人的選擇，需要選擇相關背景的受試者，在 stu 的測試中選擇是軟體工程的研究生

以下為 stu 針對他的工具提出得假設，假設都是根據依賴變數進行驗證的

- H1: 期望 Stu-merge 的結果在正確性方面超越 RA，驗證的結果為真，確實超越了
- H2: 期望 Stu-merge 幫助用戶更高效的完成合併任務，驗證結果為 Stu 的速度沒有超越 RA，可能因為這個工具的學習曲線較高，導致學習曲線較高的原因可能是因為圖形界面設計等等
- H3: 希望用戶更偏好在應用場景中使用 Stu-merge，驗證結果為用戶選擇 RA，原因和 H2 相同

收集結果，也就是對依賴變數的驗證結果

- 正確性: Stu-merge 在正確性方面確實超越 RA，證明方法論上，理論方法的有效性，正確性也是這個研究中的關鍵指標，H1 被接受這為工具繼續開發有了關鍵的支持
- 速度: Stu-merge 效率不如 RA，需要檢討算法性能或是是否在過於複雜的操作
- 用戶偏好: 用戶沒有比較偏好 Stu-merge，原因可能在於界面不夠直觀，加上速度上的提昇可能不明顯，誘因沒有大於用戶學習新工具的學習成本

下一步

- 短期改進: 優化界面，加入輔助功能
- 長期: 進一步測試，跨大樣本，檢查是不是有其他實際存在的 workload 可以發揮這個工具的優勢，或是考慮納入其他領域的受試者

### 關於實驗的有效性驗證模型
一個實驗中，通常有四種有效性類型，並分成兩個層面，分別為理論層面以及觀察層面


1. 結論有效性
涉及結論結果的統計結論是否是正確的？
- 威脅: 樣本數不足，或是數據噪聲以及統計方法的不正確導致錯誤的結論
- 屬於觀察層，處理實驗操作後的數據以及結論
2. 內部有效性
涉及因果關係的正確性，是否可以證明獨立變數的變化是否造成了相依變數的變化，而非其他外部因素的干擾
- 威脅: 實驗中未控制的變數可能干擾因果判斷
- 屬於觀察層，從上面的處理到結果
3. 概念有效性
研究中的概念是否有準確反應到實際測量的目標？
- 威脅: 操作定義不清楚或是測量方法不當可能導致概念偏離
- 屬於理論層面，關注於探討因果概念與實驗操作之間的對應性
4. 外部有效性
涉及研究結果是否可推廣到其他情境或是樣本群體
- 威脅: 受試者的選擇或實驗情境的限制可能會導致實驗的結果無法推廣
- 屬於理論層面，處理因果概念問題

- 理論層: 涉及因果概念以及效果概念，研究目的本質上是在探討理論上的因果關係是否可以通過實驗進行驗證
- 觀察層: 涉及實際的實驗操作，包含如何處理以及實驗結果。自變量是否可以真實反應概念，依賴變數是否可以準確描述實驗結果

兩者之間的連結為從理論到觀察的過度是否合理，也就是驗證概念有效性，以及從觀察到理論推論的準確性，也就是上面定義的內部有效性，證明獨立變數的變化是否造成了相依變數的變化

#### 概念有效性 (Construct Validity)
如何在實驗設計中正確的定義概念，並避免可能影響實驗結論的誤差

關於概念有效性，存在下面這幾個問題
- What do we mean by a merge? What is correctness，這個問題是關於 merge 的定義問題，具體來說 merge 究竟指的是什麼？
- merge: 指的是把兩個不同利益相關人的類圖模型合併成一個整合模型
- 正確性: 需要名確定異正確的合併結果是什麼，例如是否保留了所有原始模型的語意和結構，並且沒有邏輯衝突
- 1-5 point scale for subjective assessment，在許多研究中都會使用這樣的量化評估方法
- 評估分數範圍是 1 到 5，但這種主觀評估可能缺乏足夠的區分力，更精確的來說就是 1-5 point 抽象掉太多細節，導致不同工具的評估分數相似，難以顯示真實的差異
- 從結果顯示 Stu-merge 和 RA 得分都非常低，進一步突顯了評估方法的問題

關於威脅的改善建議:

概念有效性威脅:
- 工具的定義模糊，例如正確性的具體標準不明確，可能導致實驗數據可信度降低
- 主觀評估方法的分辨度不足，難以區分工具性能

#### 內部有效性 (Internal Validity)
定義為涉及因果關係的正確性，是否可以證明獨立變數的變化是否造成了相依變數的變化，而非其他外部因素的干擾，也就是實驗可能存在混淆變數，會影響到結果的因果解釋

內部有效性問題
- Time taken to learn the tool，在實驗中受試者對於兩個工具的熟悉程度不一樣，RA 熟悉工具，Stu-merge 不熟悉，如果我們直接合併兩張圖，會抽象到熟悉度這個指標，而這個指標顯然是會對工具性能有影響的，直接合併的結果可能反應的就不是工具效能的影響，而是熟悉程度，對於這張圖，熟悉程度就是混淆變數了

#### 外部有效性 (External Validity)
討論是否可以推廣到更廣泛的情境或是人群中

任務是否有代表性？
- 實驗使用的任務為 toy problem，這個簡單問題代表性不足，很有可能不是真實世界的 workload
- 簡單任務可能會低估或是高估工具的真實性能，使實驗結果無法有效推廣到現實的軟體工程中
- toy problem 降低複雜度，也提高實驗可控性，但這會讓實驗的代表性受到限制，所以重點是要找到 workload

受試人選擇
- 如果都是研究生，他們的背景很有可能不代表真實開發團隊的成員
- 如果研究生的實驗結果推廣到業界工程師等等，可能就會產生偏差

#### 結論有效性 (Conclusion Validity)
實驗結果或是數據分析是否具有可靠性，以及是否可以得出正確的結論

偏差來源1: 受試者認知偏差
- 受試者知道 Stu-merge 是由研究生開發的工具
- 由於他們背景，可能讓他們產生出偏好性評價，從而影響實驗客觀性
- 最好方式就是提高指標的維度，如正確性，完成任務所需時間等等

## 結論
使用上面提供的框架，對實驗進行總結

要回答的問題: 這個實驗重點是在評估兩個工具，Stu-merge 和 RA 在合併類圖任務中的表現與可用性，針對以下問題進行研究
- 這些工具在產生正確的合併圖的有效性
- 產生圖需要多少時間
- 使用者評價？

選擇受試者
- 確保樣本多樣性，避免因為特定群體倒置偏差影響結果

實驗變數
- 獨立變數: 使用的工具，Stu-merge vs RA
- 依賴變數:
- 正確性: 合併圖正確度，例如與標準答案的匹配程度
- 速度: 完成合併任務需要的時間
- 使用者評價: 基於 1-5 分評價
- 控制變數:
- 任務: 所有受試者執行相同任務
- 實驗環境: 相同電腦，相同硬體
- 培訓: 兩個工具需要提供統一且標準化的培訓
- 評估標準: 統一的正確性評分
- 避免混淆變數: 確保兩種工具訓練時間相同，避免因為熟悉度導致實驗誤差

- 結構效度
- 威脅: 對正確性和可用性定義不足會導致沒辦法反應工具性能
- 對策: 提供清晰的正確性定義，確保主觀可用性評估經過驗證，具備足夠區分能力
- 內部效度
- 威脅: 受試者對於 RA 的熟悉程度可能導致 Stu-merge 學習曲線劣勢
- 對策: 分配相同學習時間
- 外部效度
- 威脅: 實驗中使用玩具問題以及受試者選擇無法反應真實 workload
- 對策: 尋找真實世界的 workload
- 結構效度
- 威脅: 受試人知道 Stu-merge 是由研究生開發的，產生偏見
- 對策: 讓受試人不知實驗目的，工具來源

## 常見論文架構
### Abstract 摘要
介紹這一篇論文是要解決什麼問題，我們提出了什麼方法，這個方法比現在方法好多少，大約使用 200~300 字的篇幅介紹

### Introduction 簡介
前半段部分類似於研究背景，介紹這一篇論文研究問題的背景知識，目前其他人已經做出了什麼努力，以及目前遇到的問題大部分人是如何解決的，解決方向是什麼，而我們的方向是什麼? 為什麼他是有效的? 以及我們使用什麼樣的 workload 進行驗證

最後條列出我們的論文做出哪一些貢獻，以下範例
- 我們推出 XXX 工具可以用來了解記憶體消耗 ...
- 我們的研究目前已經使用於 XXX
- 比目前的 XXX 高出 XX% 的效能

### Motivation
目前遇到什麼問題，如資料庫對記憶體需求增加，或是目前技術有什麼限制，例如目前解決方法的 scalability 不好等等，簡單介紹一下目前使用的技術，如 CXL 是什麼，CXL 用於 Tiered-Memory System 是如何使用，有什麼優勢或是特徵

### 專注的問題
描述這一篇研究要專注的問題，例如使用某些工具去蒐集資料等等，怎麼蒐集的等等，以及說明要使用的 workload，workload 有什麼特徵，
### Method 研究方法
說明研究方法，或是開發的工具，這個工具需要考慮什麼問題，設計上需要考慮什麼，需要和前面說的專注的問題有關，如果前面指出如偵測記憶體頁面在偵測冷熱有效率問題，那麼在開發工具這邊就要說明我們是如何偵測頁面溫度的，以工具來說，需要說明工具背後設計原理以及做出的權衡
### Evaluation 研究結果評估
需要指出我們如何評估的，以下舉例
- XXX 方法在如記憶體分配或是提高應用程式效能方面有多高效 (如減少記憶體存取延遲或是提高 throughput)
- XXX 與目前最先進的方法相比表現如何

### Discussion and Future Research 未來研究與討論
我們發明的工具，或是我們提出的概念可以應用在哪裡
### Related Work 相關工作
和我們研究有關的其他研究，以 CXL 來說，會涉及的工具包含 Tiered Memory System, Page Placement for Tiered Memory 等等
### Conclusion 結論
總結我們實驗或是我們提出的方法帶來的貢獻，我們發明了什麼? 我們提出了什麼? 比現有好多少，提出數據即可
### Acknowledgments 致謝
### References