RAG 錯答怎麼查：切段、相似度、版本與適用條件

同樣問「正式環境的訂單要保留多久」，系統找到一段寫著 30 天的文件，答案也照著說 30 天。問題是，那份文件屬於測試環境，正式環境的規則在另一段。這是一個用來說明失敗條件的假設案例，不是本站的真實資料或效能測試。

檢索可以每次都穩定找到同一段，答案卻每次都錯。要診斷這種問題，先分開三件事：距離計算是否正確、取回的資料是否適用，以及生成答案是否忠於資料。把它們全稱為「機率性」，會找錯修正方向。

相似度排名不等於業務正確性

pgvector 官方文件區分精確最近鄰與近似最近鄰搜尋。前者找出距離最近的項目；後者用召回率換取搜尋速度。精確搜尋的召回率指向量距離的結果，不是答案的事實正確率。固定向量、距離函數、資料與同分排序，可以得到可重現的精確排名，不能因此保證拿到的是目前有效的規則。

舊文把向量檢索概括為「機率性的」，這裡更正為「相似度與適用條件可能不一致」。測試時應保留查詢、候選文件 ID、分數、版本與篩選條件。先問正確文件是否進入候選，再查排名；不要直接把錯答歸因於生成模型。

切段要保留回答所需的上下文

長文件常會切段後建立向量，但短文件也可以整份表示，不是所有向量檢索都必須先切碎文件。真正要檢查的是：一段能否保留讀者理解它需要的標題、表格欄名、單位與適用範圍。

沿用保留天數的案例，若段落只有「訂單：30 天」，卻把「測試環境」放在上一段，後面的檢索很難自行補回限制。可把章節路徑與環境欄位一起保存，或先找子段，再取回父章節。使用 OKF 管理來源有助於整理這些資訊，但切段程式仍可能丟掉它們；換檔案格式不會自動修好索引。

用小資料集把錯誤拆開

下面的範例使用人工指定的二維向量，模擬一個過期或錯環境文件排在前面的情況。它只示範距離排名與資料篩選的差別，不是 embedding 模型評測，也沒有呼叫 LLM。儲存成 retrieval-check.mjs，以 Node.js 22 執行。

import assert from 'node:assert/strict';
const query = [1, 0];
const docs = [
  { id: 'test-v1', env: 'test', rev: 1, days: 30, v: [1, 0] },
  { id: 'prod-v1', env: 'prod', rev: 1, days: 90, v: [0.99, 0.01] },
  { id: 'prod-v2', env: 'prod', rev: 2, days: 180, v: [0.9, 0.1] },
];
const rank = rows => rows.map(d => ({ ...d,
  distance: Math.hypot(...d.v.map((x, i) => x - query[i]))
})).sort((a, b) => a.distance - b.distance || a.id.localeCompare(b.id));
const unfiltered = rank(docs)[0];
const scoped = rank(docs.filter(d => d.env === 'prod' && d.rev === 2))[0];
assert.equal(unfiltered.id, 'test-v1');
assert.equal(scoped.id, 'prod-v2');
console.log({ unfiltered: unfiltered.days, scoped: scoped.days });
// { unfiltered: 30, scoped: 180 }

更新資料時，也要處理舊版本

來源改了，索引不一定已更新。需要重算哪些向量，取決於變更的是文字、切段方式、embedding 模型，還是只用於篩選的 metadata。刪除文件也必須傳遞到索引；只新增新版，會讓新舊規則同時成為候選。

可以先建立新索引版本，檢查必要文件與固定問答，再切換讀取端。保留舊版本供回復，但查詢時限制單一有效版本。要追查錯答，至少記錄來源版本與索引版本；只有答案文字，通常無法分辨是來源、同步、排名還是生成出了問題。

多跳關係需要自己的取回流程

找相似文件不會自動完成「訂單屬於哪個方案，該方案適用哪一版規則」的關聯查詢。可以讓流程依 ID 查表、走明確連結，或分次檢索並驗證每一步。這些方法也能與向量搜尋並用，不能據此說 RAG 一律不適合結構化資料。

下一次遇到錯答，先留下正確來源 ID，檢查它在哪一步消失。來源根本沒入庫、被條件排除、排名太後、取回後被模型忽略，四種情況需要四種修法。