做 ResearchForge 到現在，我越來越確定一件事：
研究報告最早出錯的地方，往往不是 AI 開始寫文章的時候，而是搜尋的第一秒。
假設今天我輸入一個題目：
塑膠微粒對海洋生物的影響
最直覺的做法，大概就是把這句話丟進搜尋引擎，再把前幾篇結果交給 AI。
乍看之下很合理。
但如果 ResearchForge 真的這樣做，那它最後產生的報告再漂亮，我可能都不敢相信。
因為一個「研究題目」，其實從來都不是一個搜尋字串。
「塑膠微粒對海洋生物的影響」看起來只有一句話，但拆開之後，可能至少包含：
甚至「影響」本身就很模糊。
到底是在問：
生理影響？
繁殖能力？
死亡率？
行為改變？
食物鏈累積？
還是整個生態系的長期效應？
如果搜尋系統只拿原始題目搜尋一次，那它拿到的不是「這個研究問題的文獻」，而比較像是：
剛好和這句話長得最像的搜尋結果。
這兩件事情差很多。
ResearchForge 裡我現在想建立的，不再是：
Topic
↓
Search
↓
Papers
而是：
Topic
↓
Research Intent
↓
Concept Expansion
↓
Sub-questions
↓
Search Queries
↓
Multiple Academic Sources
↓
Deduplication
↓
Evidence
也就是說，使用者輸入的題目只是起點。
系統必須先理解：
「這個題目真正想知道的是什麼？」
接著才能決定：
「我要用哪些字去找答案？」
這就是我最近一直在處理的 Query Expansion。
Query Expansion 聽起來很簡單。
例如原本搜尋：
microplastics marine organisms
擴展成：
microplastic toxicity marine organisms
microplastic ingestion fish
microplastic oxidative stress bivalves
microplastic reproductive effects marine species
microplastic trophic transfer ocean ecosystem
搜尋量立刻變多。
但「找到更多東西」不代表「研究變好了」。
因為擴展得太自由，很容易發生 semantic drift。
例如原本研究：
塑膠微粒對海洋生物的影響
模型一路擴展後，可能開始找到：
這些東西都和「塑膠微粒」有關。
但它們已經不是原本的研究問題。
這也是我覺得 AI 搜尋最危險的地方之一：
它很容易找到「相關的東西」，卻不一定找到「能回答問題的東西」。
我現在比較喜歡把 Query Expansion 想成：
在一個有邊界的研究空間裡增加搜尋路徑。
例如原始題目：
塑膠微粒對海洋生物的影響
可以先建立幾個 anchor：
核心實體：
microplastics
marine organisms
再建立研究面向：
physiological effects
reproduction
growth
mortality
oxidative stress
bioaccumulation
trophic transfer
接著建立研究對象：
fish
bivalves
crustaceans
zooplankton
marine invertebrates
最後才排列組合成搜尋 query。
但是同時也要存在 exclusion：
human health
drinking water
waste management
plastic recycling
這樣 Query Expansion 才不是：
AI，請幫我想到更多關鍵字。
而比較像：
在不離開研究問題的前提下，系統性探索這個問題可能存在的證據空間。
這兩種設計得到的結果會差非常多。
這也是 ResearchForge 必須處理的事情。
我平常輸入的題目幾乎都是中文。
可是很多學術資料庫裡，主要論文仍然是英文。
所以：
塑膠微粒對海洋生物的影響
不能只是翻譯成：
Effects of microplastics on marine organisms
然後結束。
真正有用的做法應該是：
中文研究問題
↓
概念辨識
↓
英文學術術語
↓
同義詞／相關術語
↓
子問題
↓
多組 query
而且我不希望系統把原本中文問題丟掉。
因為「原始問題」應該永遠被保存。
後面產生的英文關鍵字、延伸詞與搜尋式，都只是衍生資料。
這其實和 ResearchForge 很重要的一個原則是一樣的：
原始資料不能被 AI 的加工結果取代。
即使 Query 完全一樣，不同學術來源得到的結果也可能不同。
例如 ResearchForge 的資料來源設計中，我一直在考慮：
甚至針對語言學與 NLP，還會有更專門的來源。
原因很簡單。
如果我只搜尋一個資料庫，我最後得到的「研究現況」，很可能其實只是：
這個資料庫看得到的研究現況。
而不是：
真正完整的研究現況。
這又是另一個我以前低估的問題。
假設系統找到 100 篇文獻。
不代表這 100 篇都應該進報告。
還要繼續處理：
搜尋結果
↓
Metadata normalization
↓
DOI / title 去重
↓
來源品質
↓
研究相關度
↓
全文可取得性
↓
Evidence extraction
↓
Evidence Card
↓
Accepted Evidence
ResearchForge 的資料設計裡，我一直希望保留：
query_used
provider
title
authors
year
doi
abstract
relevance_score
source_quality_score
accepted_by_user
因為這樣未來當某一段報告出現問題時，我才能往回追。
不是只追到：
這句話來自哪一篇論文？
而是可以繼續追：
為什麼當初會找到這篇論文？
這對我來說才真正算「可追溯」。
以前我想像中的證據鏈大概是：
Paper
↓
Evidence
↓
Claim
↓
Paragraph
現在我覺得它其實應該更長：
Research Question
↓
Expanded Query
↓
Search Provider
↓
Search Result
↓
Source
↓
Evidence Card
↓
Claim
↓
Paragraph
↓
Report
這個改變對我來說很重要。
因為如果只有最後的 citation 是可追溯的，我其實只驗證了：
AI 有沒有替這句話放來源。
但我沒有驗證：
為什麼系統從一開始就選到了這些來源？
而一份研究報告真正的偏差，很可能早在 citation 出現以前就已經形成。
這是今天做 ResearchForge 最大的收穫。
我以前會把搜尋想成一個工具：
需要資料
→ 搜尋
→ 得到資料
現在我比較把它理解成：
搜尋策略本身，就是研究方法的一部分。
你用了哪些詞？
排除了哪些詞？
搜尋哪些資料庫？
搜尋到哪一年？
有沒有追 citation？
有沒有納入不同語言？
什麼結果被接受？
什麼結果被排除？
這些選擇全部都會改變最後的結論。
所以一個真正想做「可驗證研究報告」的系統，不能只保存最後寫出的文章。
它還必須保存：
文章是怎麼被找出來的。
這幾天我一直碰到同一個問題。
如果目標只是：
輸入一個題目，生成一篇看起來完整的報告。
其實現在的大型語言模型早就做得到。
甚至幾分鐘就能做完。
但 ResearchForge 真正想處理的是另一個問題：
我能不能知道這份報告為什麼值得相信？
而 Query Expansion 就是這條路上非常前面、卻非常容易被忽略的一環。
因為如果搜尋一開始就歪了：
後面的摘要可以很漂亮。
Evidence Card 可以很完整。
引用格式可以完全正確。
PDF 也可以排得很好看。
但它們只是在非常精確地整理一批 原本就找錯的資料。
所以今天我給自己的結論是：
搜尋不是「找到越多越好」，而是要知道自己為什麼找、找了什麼，以及為什麼沒有搜歪。
而如果 ResearchForge 最後真的能做到這件事，我希望它提供的不只是一篇報告。
而是一條從：
「我想研究什麼」
一路走到：
「我為什麼相信這個結論」
都能重新走一次的路。
今天處理的是 Query Expansion 與研究搜尋邊界。
下一步則會繼續往搜尋結果後面走：
找到一篇論文，不代表它就有資格成為證據。
也就是 ResearchForge 裡我非常重視的下一層：
Evidence Card、來源品質，以及「什麼資料有資格進入報告」。
標籤：
ResearchForge、生成式AI、RAG、Query Expansion、學術搜尋、資訊檢索、AI工程、iThome鐵人賽
iThome鐵人賽
看影片追技術