วางข้อเท็จจริงที่เปลี่ยนได้ไว้ในที่แก้ไขได้

แค็ตตาล็อกสินค้าหรือข้อกำหนดทางเทคนิคของ API เปลี่ยนได้ หากอยู่ในพรอมป์ต์เอเจนต์ ทุกการแก้จะกลายเป็นการแก้พรอมป์ต์ และทุกการเรียกต้องอ่านซ้ำ

agent knowledge retrieval

คำตอบสั้น ๆ คืออะไร?

พรอมป์ต์ควรบอกพฤติกรรมที่คงทน ข้อเท็จจริงที่เปลี่ยนต้องอยู่ในแหล่งที่อัปเดต จำกัดขอบเขต และอ้างอิงได้เมื่อใช้ หากเอเจนต์ตอบเรื่องฟิลด์ผู้ให้บริการผิด ให้ตรวจข้อกำหนดทางเทคนิคที่ค้นคืนมาก่อนแก้พรอมป์ต์หรือฝึกโมเดลเพิ่ม ส่วนกฎสิทธิ์และการเขียนแบบกำหนดแน่นอนควรอยู่ในโค้ด

เรียนรู้เพิ่มเติม
ในหน้านี้

ลองนึกถึงแค็ตตาล็อกสินค้าที่เปลี่ยนวันจันทร์ พรอมป์ต์ของผู้ช่วยยังมีรายการวันศุกร์ ทีมแก้พรอมป์ต์ แต่สำเนารายการเก่าอีกชุดอยู่ในตัวอย่างที่ใช้ฝึกโมเดล ผู้ช่วยจึงให้คำตอบปัจจุบันหนึ่งครั้งและคำตอบล้าสมัยอีกครั้งในเซสชันเดียว

นี่คือความล้มเหลวสมมติ แต่กลไกพบได้ทั่วไป: ข้อเท็จจริงเดียวมีบ้านมากกว่าหนึ่งแห่ง

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

พรอมป์ต์ไม่เหมาะเป็นแค็ตตาล็อก

พรอมป์ต์น่าดึงดูดเพราะแก้ง่าย เพิ่มย่อหน้าแล้วคำขอถัดไปก็พกมันไป ความสะดวกนี้ซ่อนต้นทุนสองอย่าง ข้อเท็จจริงถูกส่งทุกการเรียกแม้ไม่เกี่ยวข้อง และพรอมป์ต์ขนาดใหญ่ทำให้รู้ยากว่าโมเดลใช้กฎสำเนาไหน

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

คู่มือคอนเน็กเตอร์ Brevo แสดงว่าทำไมนิยามฟิลด์สำคัญต่อการซิงค์รายชื่อ หากยังไม่ได้ประกาศแอตทริบิวต์ในบัญชีปลายทาง การแมปที่ดูสมเหตุผลจากชื่ออาจไม่สร้างฟิลด์ตามต้องการ เอเจนต์ควรตรวจข้อกำหนดทางเทคนิคปัจจุบันของบัญชี ไม่ใช่จำรายการฟิลด์ทั่วไปจากการฝึก

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

ค้นข้อเท็จจริงพร้อมขอบเขต

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

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

แต่ละกรณีซ่อมต่างกัน แก้พรอมป์ต์ไม่อาจแก้ตัวกรองค้นคืนที่ข้ามขอบเขตลูกค้า โมเดลใหญ่ขึ้นก็สร้างนิยามแอตทริบิวต์ที่ไม่เคยถูกดึงมาไม่ได้

คำอธิบาย MCP กล่าวถึงวิธีเอเจนต์ค้นผ่านเครื่องมือ เครื่องมือควรคืนข้อกำหนดทางเทคนิคที่เกี่ยวข้อง ส่วนแอปบังคับว่าใครเห็นได้ คำสั่งข้อความว่า “อย่าเผยข้อมูลลูกค้ารายอื่น” แทนการค้นแบบจำกัดขอบเขตไม่ได้

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

  1. คำสั่งคงทน

    ผู้ช่วยควรทำตัวอย่างไร

  2. ค้นแบบจำกัดขอบเขต บัญชี · รุ่น · เวลา

    อะไรจริงตอนนี้

  3. ตัดสินการแมป

    ใช้ข้อเท็จจริงปัจจุบันกับงานนี้

  4. การเขียนที่บังคับกฎ

    โค้ดตรวจสิทธิ์และขอบเขต

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

สอนรูปแบบเมื่อมันนิ่งแล้ว

ข้อโต้แย้งที่ยุติธรรมคือ “ถ้าข้อเท็จจริงถูกใช้บ่อย ทำไมไม่ฝึกเข้าโมเดลเล็ก” การใช้ซ้ำอย่างเดียวไม่พอ ข้อเท็จจริงต้องถูกตลอดช่วงระหว่างอัปเดตโมเดล และโมเดลต้องแยกบริบทได้

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

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

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

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

ข้อกำหนดทางเทคนิคที่เปลี่ยนได้ไม่ควรต้องรอให้โมเดลลืม

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

อะไรควรอยู่ในพรอมป์ต์เอเจนต์?

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

ทำไมไม่ปรับแต่งโมเดลด้วยเอกสารปัจจุบัน?

การปรับแต่งอาจฝังข้อเท็จจริงที่เปลี่ยนไว้ในน้ำหนักซึ่งตรวจและอัปเดตยาก ก่อนอื่นให้แน่ใจว่าค้นและอ้างเอกสารที่ถูก ณ เวลาตัดสิน

จะแก้คำตอบข้อเท็จจริงที่ผิดอย่างไร?

ตรวจเอกสารต้นทาง รุ่น ตัวกรองการค้นคืน และข้อความที่คืน แก้ข้อเท็จจริงหรือเส้นทางค้นคืนก่อนเปลี่ยนโมเดล

ขอสิทธิ์ใช้งานล่วงหน้า

กรอกชื่อและที่อยู่อีเมลที่ทำงานของคุณ เราจะส่งลิงก์เพื่อยืนยันคำขอเข้าใช้งาน Tajo ทางอีเมล

รับ Brevo