這篇文章延續作者先前對 DuckDB 的介紹，焦點放在 DuckDB 的全文搜尋 (FTS, Full-Text Search)。作者指出，DuckDB 很適合把資料來源快速變成可用 SQL (Structured Query Language，結構化查詢語言) 查詢的表格，但在歷史出版品、電子郵件等大量文字資料中，單靠 =、ILIKE 或正規表示式會很快碰到限制。FTS 能進行更有彈性的文字查詢與排序，DuckDB 的 FTS 擴充套件提供詞幹化 (stemming，把 walk、walks、walked 歸到共同詞根)、停用詞移除、重音符號正規化，以及 Okapi BM25 (常見資訊檢索相關性排序演算法) 評分；其中 k₁ 控制詞頻的重要性，b 控制文件長度正規化。

目前 DuckDB FTS 比 Postgres 或 Elasticsearch 精簡，尚缺少片語查詢、向量搜尋、可替換同義詞字典，以及像 Postgres 的 ts_headline 那樣標示命中詞所在位置的能力。作者在實驗中也提到 Snowball (用於建立詞幹化演算法的專案) 可協助排查詞形問題，例如 running 能歸到 run，但 mice 不一定會與 mouse 被視為同一詞。實作上，FTS 不是 DuckDB 預設內含功能，需要安裝並載入 fts 擴充套件。

範例使用 13,010 封 .eml 郵件，先用 Python、uv 與 BeautifulSoup 將純文字或 HTML 信件本文抽出，保留寄件者、收件者、主旨、日期與 List-Unsubscribe、Precedence 等標頭，並輸出成 JSON (JavaScript Object Notation，常用輕量資料交換格式)。接著用 DuckDB read_json 匯入成 emails 表格，補上 id 欄位，在 subject 與 body 建立 FTS 索引，再用 match_bm25 依相關性排序。查詢 talk 會找出 Talking、talks、talked 等變化；conjunctive 參數可要求所有搜尋詞都命中；b = 1 會懲罰冗長電子報，b = 0 則忽略長度；提高 k₁ 會讓多次出現 budget 的郵件排名高於只提一次的郵件。作者結論是，DuckDB FTS 功能不如 Postgres 或 Elasticsearch 完整，但對探索式分析多半已足夠，必要時也能再轉往更完整的搜尋系統。

Hacker News 討論延伸到把信箱公開成可瀏覽、可搜尋資料庫的需求。有人想把公務機關資訊公開請求取得的政府員工信件，做成一般民眾能自行搜尋與瀏覽的網站；也有人提到企業的 SnapLogic 資料管線只靠電子郵件寄送錯誤通知，累積數萬封後難以稽核。可行工具方面，msgvault 被認為 TUI (Text User Interface，文字使用者介面) 快速、FTS5 (SQLite 的全文搜尋功能) 搜尋好用，但缺少網頁版與內嵌圖片顯示；另有人推薦 Simon Willison 的 Datasette 搭配 mbox-to-sqlite，將 mbox 郵件封存轉成 SQLite 後發布成可查詢網站。

更廣泛的回應則顯示，開發者欣賞 DuckDB 能直接指向檔案、S3 (Amazon Simple Storage Service，物件儲存服務) 或附加 MySQL、PostgreSQL 等資料庫後查詢與聯結資料，甚至有人用 DuckDB-WASM (WebAssembly 版本，可在瀏覽器端執行) 做互動式 LLM (Large Language Model，大型語言模型) SQL 評測，也有人把紀錄檔輸出成 Parquet (欄式資料檔案格式) 放在 S3，再用本機 DuckDB 查詢，取代 CloudWatch 或 Loki 等紀錄檔搜尋服務。不過疑慮也集中在擴充套件機制與生態成熟度：DuckDB 某些功能會在使用時自動下載並執行擴充套件，被認為有供應鏈風險；回覆者補充核心擴充套件有簽章，也可設定為停用自動下載、預先下載並從本機路徑載入。另有使用者提醒，DuckDB 更像 OLAP (Online Analytical Processing，線上分析處理) 工具，不是 SQLite 的直接替代品；其擴充套件生態仍年輕，遇到編譯與版本落差並不罕見。

Microsoft 的 VS Code（Visual Studio Code，程式碼編輯器）PR（Pull Request，程式碼變更請求）#310226 在 2026 年 4 月 16 日合併到 main 分支，核心變更是把 Git 擴充功能的 `git.addAICoAuthor` 預設值從 `off` 改為 `all`。依 Copilot 審查摘要，這代表當 VS Code 判定有 AI 產生的程式碼貢獻時，Git commit 訊息會預設自動加入 `Co-authored-by` 尾註（trailer），把 Copilot 標為共同作者。

這個 PR 本身沒有說明文字，只改了兩個檔案、共 2 行增減。Copilot 的 AI 審查指出，設定綱要的預設值已改成 `all`，但執行階段在 `repository.ts` 的備援值仍是 `off`，可能在部分測試或 host 環境中造成行為不一致；後續提交把備援值也更新一致，並由 Microsoft 成員核准後合併，列入 VS Code 1.117.0 里程碑。

合併後，GitHub PR 下方湧入大量負面回應。多名使用者表示，這項變更不應在未明確告知下成為預設行為，尤其有人回報即使設定了 `chat.disableAIFeatures: true`、沒有使用 Copilot、甚至手寫 commit 訊息，仍被加入 Copilot 共同作者尾註。部分留言把這形容為破壞 commit 訊息的可信度，並指出至少在 VS Code 的 Git 介面中，使用者應該看到實際將送出的完整 commit 內容；目前可透過把 `git.addAICoAuthor` 設為 `off` 停用。

Hacker News 的討論多半把此事視為一種行銷或指標操作，類比早年的「Sent from my iPhone」電子郵件簽名、Tapatalk 論壇簽名，以及 Outlook 行動版簽名；差別在於開發者未必想替 Copilot 做公開背書。也有人猜測這可能讓內部「Copilot 共同作者 commit 比例」之類的 KPI（Key Performance Indicator，關鍵績效指標）變好看，並批評這是「劣化式商業化」（enshittification）的例子，進一步傷害 Microsoft 與 GitHub 近年累積的開發者信任。

討論中也有較細緻的看法：若 commit 真的包含大型語言模型（LLM, Large Language Model）協助完成的程式碼，標註 AI 參與可作為透明揭露，甚至是辨識 AI 程式碼風險的警示；但若只是因為使用 VS Code 的 Git 功能就加入尾註，`Co-authored-by` 這類中繼資料（metadata）的識別價值會被稀釋。另有人延伸到著作權與 GPL（GNU General Public License，自由軟體授權條款）疑慮，擔心非人類作者標註會讓權利歸屬更混亂；也有留言認為錯誤尾註本身不會改變實際著作權狀態。實務上，部分開發者表示會改用 Zed 或其他編輯器、加上 commit-msg hook 阻擋多行尾註，或在既有 commit 中手動 amend 移除該行。

這篇 NeurIPS 2024 論文研究聊天型大型語言模型（LLM, Large Language Model）為何會對有害請求拒答。作者分析 13 個開放權重聊天模型，涵蓋 Qwen、Yi、Gemma、Llama-2、Llama-3，規模最高到 720 億參數，發現拒答行為在每個模型中都可由殘差流（residual stream，Transformer 內部逐層累積表示的通道）裡的一個一維方向所中介。研究團隊用有害與無害指令的對照資料，透過平均差（difference-in-means）找出這個「拒答方向」：把這個方向從模型活化值中抹除，模型就大幅降低對有害請求的拒答；反過來把這個方向加入活化值，即使是瑜伽好處、文法、投票年齡等無害問題，也可能被模型誤判為危險而拒答。

作者進一步把這個現象轉成一種白箱越獄（white-box jailbreak，攻擊者能取得模型權重）的權重修改方法，稱為權重正交化（weight orthogonalization）。做法是直接修改會寫入殘差流的權重矩陣，讓模型無法再寫入那個拒答方向；這在效果上等同於推論時的方向消融（directional ablation），但不需要逐次介入活化值，也不需要梯度式最佳化或有害回答範例，只要有有害指令與模型權重即可。在 HarmBench（有害請求與越獄評估基準）上，這種方法在 Qwen 7B、14B、72B 的攻擊成功率（ASR, Attack Success Rate）約落在 78% 到 84%；Llama-2 在使用預設安全系統提示詞時成功率較低，但拿掉系統提示詞後大幅升高。一般能力評估方面，MMLU（大規模多任務語言理解測驗）、ARC（AI2 推理挑戰）、GSM8K（小學數學文字題基準）多數變化不大，但 TruthfulQA（評估回答真實性的基準）分數普遍下降，顯示拒答機制與部分敏感真實性任務可能有重疊。

論文也分析常見的提示詞式越獄：對抗後綴（adversarial suffix，附加在提示詞末尾、用來誘導模型越過安全防線的字串）。在 Qwen 1.8B Chat 的案例中，對抗後綴會壓低拒答方向的表現，使模型內部狀態更像是在處理無害請求；進一步觀察注意力頭（attention head，Transformer 中分配注意力的子元件）後，作者發現原本會關注有害指令區段並寫入拒答方向的注意力頭，會被後綴「劫持」，轉而關注後綴詞元（token）區域。附錄還指出，對應的基礎模型在尚未聊天微調前，面對有害與無害指令時也已呈現類似方向差異，暗示安全微調可能不是從零創造拒答特徵，而是把既有的「危險／有害」表徵接到拒答行為上。作者也承認限制：結果未必能外推到更大規模或專有模型，對抗後綴分析只涵蓋單一模型與單一後綴，且「拒答方向」的語義本身仍未完全釐清。

Hacker News 討論多半把這篇研究連到「abliteration」（以消融移除拒答或審查機制的做法）與 Heretic 等開放權重模型改造工具。有留言者認為，對開放權重模型而言，移除審查幾乎已成常態，新模型發布後通常很快會有人做出較少拒答的版本，因此安全微調更像是降低法律與公關風險，而非真正阻止濫用；也有人提醒這篇是 2024 年成果，近期模型可能已嘗試把拒答表徵分散到更高維的子空間，讓單一方向消融失效。不過反方指出，只要拒答仍落在可辨識子空間，仍可能透過聚類或多方向消融移除；更有效的防線也許需要大量獨立拒答迴路，或讓其他能力依賴拒答機制正常運作。

討論串也呈現實務上的分歧：一些人表示消融後的模型確實更少拒答，但常伴隨精準度下降、幻覺增加，或在敏感請求上產生低品質內容；另一些人則說較新的保範數或雙投影做法已改善不少，尤其量化太低時才更容易出現輸出品質問題。政策與倫理面上，部分留言者厭倦過度拒答，主張模型只應在極少數高危情境拒答；相對地，也有人認為 LLM 會降低核武、生化、惡意程式等知識的操作門檻，即使相關資料公開存在，模型逐步協助仍值得設下阻力。另有留言提到 Qwen、DeepSeek 等模型在政治敏感議題與一般資安問題上的回覆差異，以及商業服務可能因多次觸發拒答而標記帳號，反映「安全」與「審查」在使用者經驗中常被混在一起，也凸顯目前拒答機制既脆弱又容易過度延伸。