RAG 看起來像「把文件丟進去就能問」。實務上，失敗多半發生在邊界：過期 SOP 與正式規章混在一起、個人筆記被當成公司答案、機密與公開資料沒有分開。
資料邊界要先回答四件事：哪些來源可以進索引、誰負責更新、回答是否必須附來源、以及模型能不能看到這批資料。這四題會決定權限、稽核與之後能不能換模型。
NARIWORKS 會在開發前先把知識責任寫進架構，再做搜尋與問答。可以先做一個小範圍的內部問答，但邊界仍要清楚。這樣本地或雲端模型才是可替換的選擇，而不是一次賭上全部資料。
知識系統
知識庫與 RAG，為什麼先要資料邊界
還沒決定哪些文件可以進系統、誰負責更新、回答要不要附來源，就上向量搜尋，之後幾乎一定要拆掉重來。