การสนทนาใหม่ทุกครั้งจะเริ่มด้วยเอเจนต์ที่ลืมเอกสารของคุณแล้ว มันสามารถอ่านใหม่ได้ แต่ต้องเสียเวลาและบริบท หรือมันสามารถปรึกษาสิ่งที่จำได้ GroupDocs.Search.Mcp จะเก็บดัชนีข้อความเต็มที่มีชื่อบนดิสก์แบบโลคัล ซึ่งคงอยู่ระหว่างเซสชันและการรีสตาร์ทคอนเทนเนอร์ ดังนั้น Claude Desktop, Cursor หรือ Copilot จะเริ่มแต่ละเซสชันโดยมีเอกสารของโครงการพร้อมค้นหาแล้วและทำการรีเฟรชด้วยการเรียกหนึ่งครั้งเมื่อไฟล์มีการเปลี่ยนแปลง:

ฉันได้แก้ไขสัญญาบางฉบับ รีเฟรชดัชนีสัญญา แล้วบอกฉันว่าตอนนี้สัญญาใดบ้างที่กล่าวถึงการลงโทษ

เวอร์ชันขั้นตอนต่อขั้นตอนพร้อมการกำหนดค่าและการแก้ไขปัญหาอยู่ในเอกสาร: วิธีทำให้ดัชนีเอกสารเป็นปัจจุบันเมื่อไฟล์เปลี่ยนแปลง.

ความหมายของ “memory” สำหรับเอเจนต์คืออะไร

โดยปฏิบัติแล้ว มีสองสิ่ง: สถานะที่คงอยู่เหนือการสนทนา และวิธีที่ประหยัดในการทำให้สถานะนั้นเป็นจริง ประวัติการแชทล้มเหลวในทั้งสองด้าน: มันสิ้นสุดเมื่อเซสชันจบลง และไม่มีอะไรอัปเดตเมื่อเอกสารมีการเปลี่ยนแปลง ดัชนีการค้นหาเป็นตัวเลือกที่ดีกว่าสำหรับเอกสาร มันอยู่บนดิสก์ข้างๆ เอกสาร, มันตอบว่า “ไฟล์ใดบอกว่า X” โดยไม่ต้องโหลดไฟล์เหล่านั้น, และสามารถรีเฟรชแบบเพิ่มส่วนได้

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

การทำงานของการรีเฟรชเป็นอย่างไร

update_index เปรียบเทียบดัชนีกับไฟล์บนดิสก์และอ่านใหม่เฉพาะสิ่งที่เปลี่ยนแปลง นี่คือผลลัพธ์ที่เซิร์ฟเวอร์ส่งกลับในการทดสอบของเรา หลังจากสัญญาหนึ่งฉบับมีการเพิ่มข้อกำหนดการลงโทษระหว่างสองการเรียก:

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

จำนวนที่แสดงบอกว่ามีอะไรเกิดขึ้น: มีการอ่านไฟล์หนึ่งไฟล์ใหม่, ไม่มีสิ่งอื่นถูกแก้ไข ไฟล์ที่ถูกลบจะหายไปในการเรียกเดียวกัน

ทำไมต้องมีดัชนีหนึ่งอันต่อโครงการ

เพราะคอร์ปัสที่แยกกันควรได้คำตอบที่แยกกัน คำถามเกี่ยวกับสัญญาของปีนี้ไม่ควรแสดงร่างของปีที่แล้ว, และเอกสารของลูกค้าหนึ่งไม่ควรผสมกับของลูกค้าอื่น ชื่อดัชนีมีค่าใช้จ่ายต่ำ:

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

แต่ละดัชนีเป็นโฟลเดอร์ภายใต้ /data/.groupdocs-search-index และ get_index_info ที่ไม่มีชื่อจะรายการทั้งหมด คุณแทบไม่จำเป็นต้องใช้ create_index อย่างชัดเจน เพราะ add_to_index จะสร้างดัชนีเมื่อใช้ครั้งแรก, แต่การตั้งชื่ออย่างตั้งใจคือสิ่งที่ทำให้ “ดัชนี” กลายเป็น “หน่วยความจำของโครงการนี้”

กฎเดียวเกี่ยวกับการลบ

เอนจินจะลบเส้นทางที่ถูกเพิ่มเข้ามา, ไม่ใช่ไฟล์เดี่ยวภายในเส้นทางนั้น เซิร์ฟเวอร์จะแจ้งอย่างชัดเจนเมื่อคุณลอง:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

ดังนั้นออกแบบให้สอดคล้อง: หากคุณคาดว่าจะลบส่วนของคอร์ปัสในภายหลัง เช่น ปี, ลูกค้า หรือร่างต่างๆ ให้ทำการจัดทำดัชนีส่วนเหล่านั้นเป็นเส้นทางแยก (contracts/2025, contracts/2026) และแต่ละส่วนสามารถลบได้ด้วยตนเอง การลบไฟล์บนดิสก์และรัน update_index ก็จะลบไฟล์นั้นด้วย

การทำให้เป็นปัจจุบันโดยไม่ต้องถาม

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

สามวิธีปฏิบัติเพื่อทำให้การรีเฟรชเป็นอัตโนมัติ:

  1. ในคำแนะนำของเอเจนต์ บรรทัดใน CLAUDE.md หรือ AGENTS.md ที่ระบุว่า “เรียก update_index สำหรับดัชนีของโครงการนี้ก่อนตอบถ้าไฟล์อาจมีการเปลี่ยนแปลง” จะทำให้เอเจนต์ทำเช่นนั้นเมื่อเริ่มเซสชัน
  2. ตามกำหนดเวลา การทำอัตโนมัติที่รองรับ MCP ใดๆ ก็สามารถเรียก update_index ทุกคืน; เมื่อมีการเปลี่ยนแปลงน้อย การเรียกจะเร็ว
  3. หลังจากคัดลอกเป็นกลุ่ม การเรียกหนึ่งครั้งจะดึงไฟล์ที่เพิ่มเข้ามาทั้งหมด

ดัชนียังคงอยู่หลังการอัปเกรด: ดัชนีที่สร้างโดย GroupDocs.Search 22.7 ถึง 26.8 จะถูกแปลงในการใช้ครั้งแรก, พร้อมสำรองที่เก็บไว้ข้างๆ

สิ่งที่เอเจนต์ตัดสินใจและสิ่งที่ดัชนีทำ

สิ่งที่เอเจนต์ตัดสินใจ สิ่งที่ดัชนีทำ
คำถามควรใช้ดัชนีใด เก็บแต่ละดัชนีที่มีชื่อไว้ในโฟลเดอร์ของมันเอง
เมื่อไฟล์อาจมีการเปลี่ยนแปลง อ่านใหม่เฉพาะไฟล์ที่เปลี่ยน, เพิ่ม, หรือลบ
คำที่ต้องค้นหาและรูปแบบที่ลอง จับคู่คำ, วลี, ช่วง; รายงานคำที่พบ
จำนวนบริบทที่ต้องอ้างอิง คืนส่วนข้อความพร้อมจำนวนคำที่ร้องขอรอบๆ
สิ่งที่บอกคุณ ไม่มีอะไร: มันคืนจำนวน, เส้นทางและข้อความ, ไม่ได้สรุปผล

การแยกนี้ทำโดยเจตนา การตัดสินใจยังคงอยู่กับโมเดล, และข้อเท็จจริงที่มันอ้างอิงมาจากเครื่องมือที่คุณสามารถตรวจสอบผลลัพธ์ได้

ข้อจำกัดที่ตรงไปตรงมา

  • ในโหมดประเมิน ดัชนีจะเก็บได้สูงสุด 100 เอกสารและการค้นหาจะคืนผลสูงสุด 10 รายการ เรียก get_license_status ก่อนพึ่งพาดัชนีเป็นแหล่งความจริง
  • ดัชนีจะคงอยู่เฉพาะเมื่อ /data (หรือโวลุ่มดัชนี) เป็นโฟลเดอร์โฮสต์ที่เมานท์; มิฉะนั้นมันจะหายไปพร้อมกับคอนเทนเนอร์
  • ดัชนีมีข้อความของเอกสาร: ปกป้องและทำลายมันเช่นเดียวกับเอกสาร
  • ใช้เฉพาะ Docker; บน Linux ให้เพิ่ม --user "$(id -u):$(id -g)" เพื่อให้คอนเทนเนอร์เขียนดัชนีได้

คำถามที่พบบ่อย

เอเจนต์จำเอกสารของฉันระหว่างเซสชันได้หรือไม่?
ด้วยดัชนีที่คงอยู่, ใช่: ดัชนีอยู่บนดิสก์และเซสชันถัดไปจะค้นหาจากดัชนีโดยไม่ต้องอ่านใหม่

ฉันต้องสร้างดัชนีใหม่เมื่อไฟล์มีการเปลี่ยนแปลงหรือไม่?
ไม่. update_index จะอ่านใหม่เฉพาะไฟล์ที่เปลี่ยน, เพิ่ม, หรือลบ

ฉันสามารถเก็บดัชนีแยกจากเอกสารแบบอ่านอย่างเดียวได้หรือไม่?
ได้. เมานท์เอกสารแบบอ่านอย่างเดียว, เมานท์โฟลเดอร์ที่เขียนได้ที่ /index, และตั้งค่า GROUPDOCS_MCP_INDEX_PATH=/index

ไปให้ลึกขึ้น