หน้าต่างบริบท AI Agent: ลดการตอบสนอง API ที่มากเกินไป

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

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

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

Apidog ช่วยในด้านการวัดผล: คุณสามารถดูขนาดการตอบกลับจริงของทุกปลายทาง (endpoint) ก่อนที่ตัวแทนจะเรียกใช้ และจำลองรูปแบบที่คุณต้องการได้ก่อนที่ทีม API จะเผยแพร่

โทเค็นหายไปไหน

การตอบกลับที่ออกแบบมาสำหรับเบราว์เซอร์และแดชบอร์ดมีข้อมูลจำนวนมากที่ทำให้ตัวแทนต้องเสียค่าใช้จ่ายจริง

ซองจดหมายที่ซับซ้อน (Verbose envelopes). การห่อหุ้มออบเจกต์ที่มีห้าฟิลด์ด้วย data, meta, links, included สามารถเพิ่มขนาด payload เป็นสองเท่าได้ ลิงก์ Hypermedia มีประโยชน์สำหรับไคลเอนต์ที่ติดตามลิงก์เหล่านั้น ตัวแทนแทบไม่เคยทำเช่นนั้น และทุก URL ก็คือโทเค็น

คีย์ที่ซ้ำกัน (Repeated keys). JSON จะทำซ้ำชื่อฟิลด์ทุกรายการในทุกองค์ประกอบอาร์เรย์ รายการ 200 รายการที่มี 15 ฟิลด์ต่อรายการจะต้องเสียค่าใช้จ่ายสำหรับสตริงคีย์ 3,000 รายการ นี่คือสาเหตุที่ปลายทาง (endpoint) ที่เป็นรายการ (list) ใช้บริบทส่วนใหญ่

การขยายแบบซ้อนกันโดยค่าเริ่มต้น (Nested expansion by default). ปลายทางที่ผนวกทรัพยากรที่เกี่ยวข้องเข้ามาในตัว (inline related resources) จะสะดวกจนกว่าตัวแทนจะเรียกใช้ ลูกค้าหนึ่งคนพร้อมคำสั่งซื้อและรายการสินค้าคือโครงสร้างแบบต้นไม้ และโครงสร้างแบบต้นไม้ก็เติบโตอย่างรวดเร็ว

รูปแบบที่ซ้ำซ้อน (Redundant formats). created_at, created_at_unix และ created_at_human ในออบเจกต์เดียวกันคือค่าใช้จ่ายสามเท่าสำหรับค่าเดียว

ค่าว่างและค่าเปล่า (Nulls and empties). ตัวซีเรียลไลเซอร์ (serializer) จำนวนมากจะปล่อยฟิลด์ทุกรายการออกมาแม้จะไม่ได้ตั้งค่าไว้ การมี null ยี่สิบครั้งต่อระเบียนคือการสิ้นเปลืองโดยเปล่าประโยชน์

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

กฎข้อที่หนึ่ง: ส่งคืนฟิลด์ ไม่ใช่ทรัพยากร

การเปลี่ยนแปลงที่มีค่าสูงสุดเพียงอย่างเดียวคือการให้ผู้เรียกสามารถร้องขอสิ่งที่ต้องการ

GET /v1/customers/8812?fields=id,email,plan,status

{ "id": "8812", "email": "dana@example.com", "plan": "pro", "status": "active" }

นั่นคือการลดลง 90 เปอร์เซ็นต์เมื่อเทียบกับข้อมูลทั้งหมดบน API ส่วนใหญ่ และใช้เวลาช่วงบ่ายในการเพิ่ม คู่มือการออกแบบ API ของ Google ได้บันทึกรูปแบบ field-mask ไว้ หากคุณต้องการเวอร์ชันที่มีกรณีตัวอย่าง และ GraphQL ก็แก้ปัญหาเดียวกันโดยทำให้การเลือกเป็นสิ่งที่ต้องทำ

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

จากนั้นเปิดเผยพารามิเตอร์ให้โมเดลทราบในคำอธิบายเครื่องมือ โดยระบุฟิลด์อย่างชัดเจน:

{
  "name": "getCustomer",
  "description": "Fetch a customer by ID. Always pass `fields` with only what you need. Available: id, email, name, plan, status, created_at, billing_address, order_count.",
  "input_schema": {
    "type": "object",
    "required": ["customerId", "fields"],
    "properties": {
      "customerId": { "type": "string" },
      "fields": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Field names to return. Keep this list minimal."
      }
    }
  }
}

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

กฎข้อที่สอง: จำกัดรายการเสมอ

ปลายทาง (endpoint) รายการที่ไม่มีขีดจำกัดเป็นแหล่งที่มาสำคัญอันดับสองของปัญหาใหญ่ ตัวแทนร้องขอ "คำสั่งซื้อล่าสุด" และได้รับทุกอย่างตั้งแต่ปี 2019

กำหนดขีดสูงสุดที่ฝั่งเซิร์ฟเวอร์อย่างเข้มงวด ไม่ใช่แค่ค่าเริ่มต้น หากตัวแทนส่ง limit=5000 ให้ส่งคืน 100 รายการและแจ้งให้ทราบ คู่มือของเราเรื่อง การแบ่งหน้า REST API และ การออกแบบการแบ่งหน้าสำหรับข้อมูลหลายล้านรายการ ครอบคลุมกลไก; กฎเฉพาะสำหรับตัวแทนจะแคบลง:

• จำกัดหน้าให้อยู่ในขอบเขตที่โมเดลสามารถอ่านได้ โดยประมาณ 20 ถึง 50 รายการสำหรับระเบียนทั่วไป
• ส่งคืนจำนวนรวมเพื่อให้ตัวแทนสามารถบอกได้ว่าได้เห็นทุกอย่างแล้วหรือไม่ โดยไม่ต้องแบ่งหน้าเพื่อค้นหา
• ใช้การแบ่งหน้าแบบ cursor (cursor pagination). ออฟเซ็ตอาจเคลื่อนที่เมื่อข้อมูลเปลี่ยนแปลงระหว่างการรัน และตัวแทนที่แบ่งหน้าช้าๆ จะประสบปัญหานั้น
• รวมข้อความธรรมดาในการตอบกลับ เช่น "truncated": true เพื่อให้โมเดลทราบว่ายังมีข้อมูลอีก โมเดลมักจะประเมินความสมบูรณ์ผิดพลาดจากการความยาวของอาร์เรย์เพียงอย่างเดียว

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

กฎข้อที่สาม: ลดขนาดในเลเยอร์เครื่องมือเมื่อ API ไม่ใช่ของคุณ

API ของบุคคลที่สามจะไม่เพิ่มการเลือกฟิลด์เพียงเพราะคุณร้องขอ ให้ลดขนาดในตัวดำเนินการ (executor) ของคุณแทน ระหว่างการตอบกลับ HTTP และโมเดล

KEEP = {
    "getCustomer": ["id", "email", "plan", "status"],
    "listOrders": ["id", "total", "status", "created_at"],
}

def project(tool_name, payload):
    keep = KEEP.get(tool_name)
    if keep is None:
        return payload
    if isinstance(payload, list):
        return [{k: item.get(k) for k in keep if k in item} for item in payload]
    return {k: payload.get(k) for k in keep if k in payload}

การปรับปรุงสามประการทำให้สิ่งนี้สามารถใช้งานได้จริง

• จัดเก็บการตอบกลับทั้งหมดและส่งโมเดลส่วนที่ฉาย (projection). เก็บ payload ที่ไม่ได้ถูกตัดทอนไว้ในบันทึกการรันของคุณ เพื่อให้ยังสามารถดีบั๊กได้ โพสต์ของเราเรื่อง การติดตามการเรียกใช้เครื่องมือของตัวแทน AI ครอบคลุมสิ่งที่จะบันทึก
• แจ้งโมเดลว่าคุณได้ลบอะไรไป บรรทัดเช่น "_omitted": ["billing_address", "notes", "metadata"] จะช่วยให้โมเดลสามารถขอระเบียนทั้งหมดเมื่อมันต้องการจริงๆ แทนที่จะสรุปว่าข้อมูลไม่มีอยู่จริง
• แปลงรายการให้อยู่ในรูปแบบที่กะทัดรัด สำหรับผลลัพธ์ที่เป็นตาราง CSV หรือตาราง markdown ใช้โทเค็นน้อยกว่า JSON มาก เนื่องจากชื่อฟิลด์ปรากฏเพียงครั้งเดียวแทนที่จะเป็นต่อแถว โมเดลอ่านได้ทั้งคู่ดี

id,total,status,created_at
ord_91,4900,paid,2026-08-21
ord_92,1200,refunded,2026-08-22

กฎข้อที่สี่: สรุปบนเซิร์ฟเวอร์สำหรับกรณีที่หนักหน่วง

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

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

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

วัดผลก่อนและหลัง

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

ไบต์ต่อการตอบกลับ ต่อปลายทาง (endpoint). ส่งคำขอที่สมจริงไปยังแต่ละเครื่องมือที่ตัวแทนของคุณสามารถเรียกใช้ได้ และบันทึกขนาด payload อะไรก็ตามที่เกินสองสามกิโลไบต์เป็นผู้สมัคร ใน Apidog คุณสามารถรันแต่ละปลายทางได้ครั้งเดียวและอ่านขนาดได้จากผลตอบกลับโดยตรง จากนั้นบันทึกคำขอเพื่อให้การตรวจสอบซ้ำเมื่อ API เปลี่ยนแปลง

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

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

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

สิ่งที่ดูดีเป็นอย่างไร

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

{
  "customer": { "id": "8812", "email": "dana@example.com", "plan": "pro" },
  "recent_orders": [
    { "id": "ord_91", "total_cents": 4900, "status": "paid" },
    { "id": "ord_92", "total_cents": 1200, "status": "refunded" }
  ],
  "recent_orders_total": 47,
  "truncated": true,
  "_omitted": ["billing_address", "metadata", "order_line_items"]
}

น้อยกว่า 200 โทเค็น มันตอบคำถามทั่วไป มันบอกว่ามีคำสั่งซื้อ 47 รายการ แทนที่จะบอกเป็นนัยว่ามีแค่สองรายการ และมันบอกโมเดลว่าสามารถถามอะไรต่อไปได้

เริ่มต้นด้วยปลายทาง (endpoint) ที่มีการใช้งานมากที่สุดของคุณ วัดผล เพิ่มการเลือกฟิลด์ จำกัดรายการ และรันตัวแทนอีกครั้ง ช่องว่างระหว่างตัวเลขทั้งสองมักจะใหญ่พอที่จะทำให้งานส่วนที่เหลือมีความชอบธรรม ดาวน์โหลด Apidog หากคุณต้องการการวัดผลและ mock ในโปรเจกต์เดียวกัน

สามสถานการณ์ที่สิ่งนี้ปรากฏ

• การคัดแยกงานสนับสนุน (Support triage). ตัวแทนอ่านตั๋ว ดึงข้อมูลลูกค้า และตัดสินใจว่าจะส่งต่อหรือไม่ เวอร์ชันที่ซื่อๆ จะดึงออบเจกต์ลูกค้าทั้งหมดและตั๋ว 50 ใบสุดท้าย เผาผลาญโทเค็น 30,000 รายการก่อนที่จะอ่านข้อร้องเรียนจริง เวอร์ชันที่แก้ไขแล้วจะเรียกใช้ปลายทางสรุปที่ส่งคืนแผน สถานะ จำนวนตั๋วที่เปิดอยู่ และวันที่ติดต่อล่าสุด ประมาณ 80 โทเค็น และการตัดสินใจส่งต่อจะดีขึ้นเนื่องจากข้อเท็จจริงที่เกี่ยวข้องไม่ได้ถูกซ่อนไว้
• ตัวแทนปฏิบัติการภายใน (Internal ops agents). ตัวแทนการปรับใช้ตรวจสอบสถานะสุขภาพของบริการต่างๆ 40 รายการ ออบเจกต์สถานะเต็มรูปแบบจะทำให้หน้าต่างบริบทเกินขีดจำกัดเมื่อถึงบริการที่ 12 การรวมข้อมูลที่ส่งคืนหนึ่งบรรทัดต่อบริการ, ชื่อพร้อมสถานะและอัตราข้อผิดพลาด จะสามารถใส่ทั้ง 40 รายการได้ในไม่กี่ร้อยโทเค็น และช่วยให้ตัวแทนสามารถพิจารณาข้อมูลทั่วทั้งระบบได้โดยไม่ลืมข้อมูลครึ่งแรก
• การป้อนข้อมูลและการกระทบยอด (Data-entry and reconciliation). ตัวแทนจับคู่ใบแจ้งหนี้กับการชำระเงิน การส่งคืนเอกสารใบแจ้งหนี้แบบเต็มทำให้ล้มเหลวหลังจากผ่านไปไม่กี่สิบระเบียน การส่งคืน id, amount_cents, date และ reference ในรูปแบบ CSV ช่วยให้จัดการได้หลายร้อยรายการในการประมวลผลครั้งเดียว เนื่องจากมีการใช้เพียงสี่ฟิลด์ในการเปรียบเทียบ

รูปแบบที่พบในทั้งสามกรณี: ตัวแทนต้องการพื้นผิวสำหรับการตัดสินใจ และ API มอบเอกสารให้มัน

คุณต้องมีประวัติการรันเพื่อดูรูปแบบ

การรันเพียงครั้งเดียวจะบอกคุณว่าการตอบกลับมีขนาดใหญ่ รูปแบบที่ปลายทาง (endpoint) ใดใช้เกินงบประมาณและบ่อยแค่ไหน จะปรากฏให้เห็นเมื่อพิจารณาจากการรันหลายครั้ง

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

กำหนดงบประมาณต่อเครื่องมือ ไม่ใช่แค่ต่อการรัน

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

กำหนดเพดานสำหรับแต่ละเครื่องมือ เช่น 1,500 โทเค็น เมื่อการตอบกลับเกินขีดจำกัด ตัวดำเนินการจะตัดทอนตาม projection เพิ่มตัวบ่งชี้ฟิลด์ที่ถูกละไว้ และบันทึกการเกินขีดจำกัด ตอนนี้คุณมีรายการปลายทาง (endpoint) ที่เกินงบประมาณเป็นประจำ โดยจัดอันดับตามความถี่ที่ตัวแทนเรียกใช้ ซึ่งเป็นคิวงานของคุณ

งบประมาณยังช่วยปกป้องคุณจากปลายทาง (endpoint) ที่มีขนาดเล็กในการทดสอบ แต่ใหญ่โตมหาศาลสำหรับลูกค้ารายเดียวในสถานการณ์จริง การกระจายข้อมูลมีส่วนท้ายที่ยาว และบัญชีที่มีคำสั่งซื้อ 4,000 รายการคือบัญชีที่จะทำให้การรันล้มเหลวตอนตี 2 การจำกัดอย่างเข้มงวดจะเปลี่ยนสิ่งนั้นให้เป็นการตอบกลับที่ถูกตัดทอน แทนที่จะเป็นงานที่ล้มเหลว

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

• การตัดทอนการตอบกลับมีความเสี่ยงหรือไม่ หากตัวแทนต้องการข้อมูลที่หายไป? มีความเสี่ยงเฉพาะในกรณีที่คุณซ่อนการตัดทอนเท่านั้น ใส่เครื่องหมายที่ชัดเจนและรายการฟิลด์ที่ถูกละไว้เพื่อให้โมเดลสามารถร้องขอได้ การตัดทอนอย่างเงียบๆ คือสาเหตุที่ทำให้เกิดคำตอบผิด ไม่ใช่การลดขนาดเอง
• ฉันควรใช้ GraphQL สำหรับตัวแทนแทนหรือไม่? GraphQL ทำให้การเลือกฟิลด์เป็นสิ่งที่ต้องทำ ซึ่งช่วยแก้ปัญหานี้ได้อย่างหมดจด แต่มันเพิ่มความซับซ้อนในการสร้าง query และโมเดลมักจะเขียน query ที่ไม่ถูกต้องบ่อยกว่าการใช้รายการฟิลด์ผิด การเพิ่ม fields ไปยังปลายทาง REST มักจะเป็นการเปลี่ยนแปลงที่เล็กกว่า
• การตอบกลับของเครื่องมือควรมีขนาดเล็กแค่ไหน? ตั้งเป้าให้น้อยกว่า 1,000 โทเค็นสำหรับการอ่านระเบียนเดียว และน้อยกว่า 2,000 โทเค็นสำหรับรายการ หากเกินกว่านั้น ให้ถามว่าตัวแทนต้องการระเบียนหรือคำตอบ
• การแคช prompt ช่วยแก้ปัญหานี้ได้หรือไม่? มันช่วยลดค่าใช้จ่ายของบริบทที่ซ้ำกัน ไม่ใช่พื้นที่ที่มันครอบครอง การตอบกลับ 40,000 โทเค็นที่ถูกแคชยังคงเติมเต็มหน้าต่าง ดังนั้นการแคชช่วยลดค่าใช้จ่ายในขณะที่ยังคงมีปัญหาเรื่องความน่าเชื่อถืออยู่
• แล้วการตอบกลับแบบไบนารีและไฟล์ล่ะ? อย่าใส่ไว้ในบริบทเด็ดขาด จัดเก็บไฟล์ ส่งให้ตัวแทนอ้างอิงและคำอธิบายสั้นๆ และให้เครื่องมือแยกต่างหากเพื่อดึงเฉพาะสิ่งที่ต้องการเท่านั้น
• การลดขนาดควรอยู่ที่ใด ใน API หรือใน tool wrapper? ใน API เมื่อคุณเป็นเจ้าของ เพราะผู้เรียกทุกคนจะได้รับประโยชน์และไบต์จะไม่ข้ามเครือข่าย ใน wrapper เมื่อคุณไม่ได้เป็นเจ้าของ การทำทั้งสองอย่างก็ใช้ได้