員工手冊的回答，要引述章節與版本

摘要（TL;DR）。 一份知識套件（knowledge pack）是一套處理配方：保持每條政策條文完整、清楚引述章節與版本日期，並在手冊改版時重新索引（re-index）。我們今天能展示的，是以虛構公司 Acme 示範的這套配方——包括一份範例手冊、一項知識庫檢索測試，以及與你一起載入檔案的先導項目（pilot）。

會議室裏那句「直接上載就可以」

負責人事與營運（People Ops）的同事，常會聽到一種聽起來已經大功告成的推銷：只要把員工手冊放進系統，聊天機械人就能回答年假、福利，以至「這樣做合規嗎？」。

要生成一段通順的文字很容易；但要給出一個可以放心貼進員工電郵的答案，就需要明確的章節與版本日期。真正管用的，是一套針對單一知識庫的處理配方：手冊怎樣切分、出處引用長什麼模樣，以及在政策改版的那個星期，團隊要做什麼。

建立在 Library 上的處理配方

OrchAI Library 是整套產品的記憶——相當於團隊內部文件的私人 Google，每個答案都附帶出處引用。HR 知識套件就建立在這個 Library 之上。產品名稱仍然是 Portal、Library、Agents 與 Eval。

真正在會議室裏落地時，關鍵有三件事：

1. 切分每項政策，保持整條條文完整。
2. 引述手冊的章節與版本日期——或者福利指南的頁碼。
3. 版本更新時，重新索引。

我們可以用虛構公司 Acme 來示範這三個步驟。範例中的員工手冊版本是 2026-04-01，範例福利指南則是 2026-03-15。Acme 是我們為這次演示製作的範例語料，範例中的員工手冊屬於這間虛構公司。

保持整條條文完整

休假規定通常會在同一個章節裏，同時寫明「日數」與「例外情況」。如果把章節從中切開，回答時便可能只引述了日數，卻漏掉了例外情況。

這套 HR 配方會按章節切分範例：每一個手冊章節獨立成段，每段上限 400 words，段落之間零重疊。福利指南的標題亦採用同樣方式處理。整條政策要整段一起被讀到。

這種切分方式，正是範例的準備方法。在專門針對上載檔案的章節切分器就緒之前，一般上載的 PDF 仍會被切分為普通段落。把員工手冊整理成完整的章節，本身就是配方的一部分；直接放進資料夾的 PDF，依然需要經過這道切分工序。

出處引用應該長什麼模樣

在 Acme 範例中，有關休假的回答會引述章節與版本：

Handbook §3.2 (version 2026-04-01)

我們用來演示的問題是：「未放取的年假，最多可以帶多少日到下一年？」範例會指向 §3.2、5 days、版本 2026-04-01。這五日是虛構公司 Acme 為這次演示而設的規則。先導項目（pilot）則會採用你所帶來檔案中的政策。

至於福利查詢，回答會引述福利供應商文件及頁碼，格式如下： Acme Benefits Medical plan p.4。

休假與入職（onboarding）相關的提問，都會透過這個套件處理並附上這項出處引用。如果答案缺少了章節與版本——或者缺少了供應商文件與頁碼——請暫緩把該回覆放進員工電郵。模型要麼指向套件裏的具體段落，要麼就此停步。

手冊改版時，更新知識套件

只有當知識套件跟著手冊一起更新，引用裏的版本日期才算得上誠實。每當政策修改，請為該知識庫重新攝取並重新索引（re-ingest and re-index），讓出處引用反映最新的版本日期。

套件讀取的是你交給它的檔案。員工通訊錄同步（staff-directory sync）屬於這套配方以外的範疇。休假或出糧試算表可以按範例格式作為檔案讀取；範例會將該檔案視為一份文件來讀取，而接通即時出糧系統則是另一項獨立的工作。

在寫進採購項目之前，先把這幾點說清楚

今天可以確切說明的事	仍需另行確認的事項
這套配方會按章節切分手冊、引述 Handbook §3.2 與版本日期，並在檔案改版時重新索引。	「你們的員工手冊已經在生產環境上線。」
目前的範例是虛構公司 Acme。真正的先導項目（pilot），是由我們與你一起載入你們的檔案並重新索引。	「這是一款可以直接購買的 HR copilot 產品。」
在 Acme 範例上，檢索測試要求正確章節出現在前五名結果中（recall@5 至少達 0.8），且出處引用相符（準確率至少達 0.9）。	「OrchAI Eval 已經完成驗收簽署。」這項 HR 評測仍待完成。目前的範例檢查是針對範例種子的知識庫測試；法律審查則是另一個獨立步驟。
誰有權打開這個知識集合，是另一個獨立開關。在部署了 Portal 的環境下，機構角色與權限依然由 Portal 管理。	「因為套件標示了 HR，所以只有 HR 團隊才看得到。」
匯入文件目前仍會用到 Portal 介面。現行支援的路徑依然包含這些畫面。	「只要在 Library 上載 PDF 就大功告成。」

這在整個產品體系裏的位置

我們早前曾撰文解釋，為什麼有管治的文件庫會引述所召回的段落。雲端硬碟負責存放檔案；文件庫則負責召回段落並附上出處。有了這座文件庫之後，處理 HR 員工手冊依然需要上述配方：保持條文完整、附上具版本的出處引用，以及在政策改動時重新索引。

OrchAI Library 負責承載這份記憶。OrchAI Agents 是同事日常登入使用的前門。OrchAI Eval 是在你需要量化評分報告時的品質閘門，而這個 HR 套件在 Eval 的評分項目目前仍待完成。OrchAI Portal 則是整棟大樓，包括管理機構內誰有權打開哪些內容。

如果你們下一場對話正好是「有人叫我們直接把員工手冊上載上去」，歡迎**與我們聯絡**。請帶上你們實際在用的手冊版本，我們會為先導項目載入這份檔案。至於 Acme 範例，就讓它繼續作為演示範例。

常見問題

聊天機械人懂得僱傭及勞工法例嗎？ 它會根據套件內的員工手冊章節與版本來回答。出處引用會列明該章節與版本日期。如果你載入的檔案缺少了相關條文，套件便會停步。

我們的員工手冊已經在產品裏面了嗎？ 目前的範例來自虛構公司 Acme（手冊版本為 2026-04-01，福利指南為 2026-03-15）。你們的手冊屬於先導項目（pilot）：我們會與你的團隊一起載入檔案並重新索引。

如果下個月政策 PDF 改版了，會怎樣處理？ 請為該知識庫重新攝取（re-ingest）並重新索引（re-index），讓出處引用顯示新的版本日期。在共用雲端硬碟或 HR 系統裏作出的修改，會在你執行這項更新時同步至知識套件。

我們可以將它作為附帶 Eval 驗收簽署的 HR copilot 購買嗎？ 你可以使用這套 Library 配方與虛構範例。這個套件是建立在 OrchAI Library 上的處理配方。OrchAI Eval 尚待為這個套件評分。文中的 0.8 與 0.9 數字，是這項知識庫測試中的範例檢索門檻。