Dikaya Pro: เทียบคู่มือหลายฉบับโดยไม่ทำข้อยกเว้นหาย

ตัวอย่าง API ขั้นต่ำ

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

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro",
    max_tokens=512,
    messages=[{"role": "user", "content": "สร้างรายการตรวจสอบสำหรับงานของฉัน แยกข้อเท็จจริงจากแหล่งข้อมูลออกจากสมมติฐาน"}],
)
print(response.choices[0].message.content)

สร้างทะเบียนฉบับที่ต้องการเปรียบเทียบ

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

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

จับคู่หัวข้อตามความหมายไม่ใช่เลขหน้า

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

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

อ่านเงื่อนไขย่อยแยกจากข้อกำหนดทั่วไป

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

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

พิสูจน์ขอบเขตการอ่านด้วยรหัสหัวข้อ

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

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

เตรียมข้อความและการเรียกใช้อย่างมีขอบเขต

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

ส่งรหัส seller-pro และกำหนดเพดานคำตอบให้เหมาะกับตารางที่ต้องการ ไม่เติม low, high หรือ max ให้ Pro จากข้อเท็จจริงที่ว่าบางโมเดลอื่นประกาศรองรับ ระดับแบรนด์นี้ไม่มีข้อมูลพื้นฐานที่ยืนยันในคู่มือ จึงไม่ควรยกคุณสมบัติหรือที่มาของ Pro 2 มาใช้แทนเพราะชื่ออยู่ใกล้กัน

เก็บงานที่ยังไม่เสร็จและส่งต่อให้คนอนุมัติ

สำหรับ SDK Python ตั้ง max_retries=0 เพื่อไม่ให้การส่งซ้ำเกิดโดยไม่ตั้งใจ แยก HTTP ที่ปฏิเสธชัดเจนจากการเชื่อมต่อขาดซึ่งผลยังไม่แน่ชัด คู่มือ MDN อธิบายว่าต้องตรวจ status ของ Fetch ด้วย การหยุดรับหรือหมดเวลารอไม่ได้ยืนยันว่าไม่บันทึกหรือไม่คิดค่าใช้จ่าย ตรวจประวัติก่อนเริ่มงานเปรียบเทียบซ้ำ

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

คำถามและคำตอบ

ถ้าขนาดบริบทใหญ่ จะส่งคู่มือทั้งหมดผ่านแชตได้แน่นอนหรือไม่?

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

การย้ายข้อไปอีกบทควรถูกนับว่าเป็นข้อใหม่หรือไม่?

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

Pro มีพื้นฐาน GLM-5.3 เหมือน Pro 2 ใช่หรือไม่?

คู่มือนี้ไม่มีข้อมูลยืนยันเช่นนั้น การเปิดเผยว่าเป็นรุ่นปรับแก้บนพื้นฐาน GLM-5.3 ใช้กับ Pro 2 เท่านั้น ไม่ควรขยายไปยัง Pro หรือ Flash ให้เก็บชื่อแบรนด์และรหัสจริงไว้โดยไม่แต่งข้อมูลพื้นฐานที่ยังไม่ประกาศ

โมเดลควรตัดสินข้อขัดแย้งในคู่มือแทนเจ้าของโครงการหรือไม่?

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

แหล่งข้อมูล

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

• Dikaya: รายการโมเดลและเงื่อนไขการเลือกใช้งาน
  dikaya.cc
• Dikaya: คู่มือ API และขอบเขตของคำขอ
  dikaya.cc
• Dikaya: ราคาสาธารณะสำหรับตรวจสอบเงื่อนไข
  dikaya.cc
• เอกสาร Python SDK: ข้อผิดพลาดและการปิดส่งคำขอซ้ำ
  github.com
• คู่มือ MDN: สถานะ HTTP การอ่านผลและยกเลิก Fetch
  developer.mozilla.org