คู่มือโมเดลตระกูล GPT‑6

GPT‑6 คือชุดโมเดลที่ล้ำหน้าที่สุดของเราในขณะนี้ โดยมีโมเดลให้เลือกใช้ตามลักษณะงานที่แตกต่างกัน

ไม่ว่าคุณจะนำไอเดียมาสร้างต้นแบบที่ใช้งานได้จริง พัฒนาและทดสอบฟีเจอร์ หรือจัดการงานหลายขั้นตอนที่ต้องใช้ทั้ง Repository ฐานข้อมูล และ API ภายนอก คู่มือนี้จะช่วยให้คุณเลือกโมเดล GPT‑6 ได้เหมาะกับงาน สั่งงานได้อย่างมีประสิทธิภาพ จัดการงานที่ใช้เวลานาน และเตรียมพร้อมสำหรับการใช้งานจริง

• เพิ่มประสิทธิภาพเมื่อนำไปใช้งานจริง จัดการบริบทและค่าใช้จ่ายด้วยการแคช⁠(เปิดในหน้าต่างใหม่)และการย่อบริบท⁠(เปิดในหน้าต่างใหม่) ประเมินว่างานสำเร็จตามเป้าหมายหรือไม่และใช้เวลาตอบสนองเท่าใด พร้อมวางแผนตรวจสอบการทำงานและควบคุมข้อมูล

• เลือกโมเดลให้เหมาะกับงาน เลือกโมเดล ระดับการให้เหตุผล⁠(เปิดในหน้าต่างใหม่) และความเร็วให้เหมาะกับงาน โดยคำนึงถึงสมดุลระหว่างความสามารถ ค่าใช้จ่าย และเวลาตอบสนอง

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

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

ก่อนนำไปใช้งาน ควรเตรียมการตรวจสอบและแนวทางปฏิบัติที่ดีหลายอย่างให้พร้อม

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

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

• สำหรับบทสนทนาที่ยาวขึ้น การย่อบริบท⁠(เปิดในหน้าต่างใหม่)จะลดขนาดบริบท แต่ยังเก็บสถานะที่จำเป็นต่อการทำงานต่อไว้

• กำหนดวิธีติดตามพฤติกรรมการทำงาน⁠(เปิดในหน้าต่างใหม่) พร้อมตรวจดูการตั้งค่าควบคุมข้อมูล⁠(เปิดในหน้าต่างใหม่)ของแอปพลิเคชัน

• ทดสอบก่อนเริ่มใช้งานจริง: ทดลองทำงานที่สะท้อนลักษณะการใช้งานจริง แล้วประเมินว่างานสำเร็จตามเป้าหมายหรือไม่ ใช้เวลาตอบสนองเท่าใด และมีค่าใช้จ่ายเท่าใดต่อหนึ่งงานที่สำเร็จ ดูรายการตรวจสอบก่อนนำ API ไปใช้งานจริง⁠(เปิดในหน้าต่างใหม่)ของเรา

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

• โมเดล:

  • GPT‑6 Astra⁠(เปิดในหน้าต่างใหม่) สำหรับงานที่ต้องใช้การให้เหตุผลซับซ้อนที่สุดและต้องการความสามารถสูงสุดของโมเดล

  • GPT‑6.1 Sol⁠(เปิดในหน้าต่างใหม่) สำหรับการเขียนโค้ดที่ซับซ้อน การวิจัย และการใช้คอมพิวเตอร์

  • GPT‑6 Luna⁠(เปิดในหน้าต่างใหม่) สำหรับงานเฉพาะทางปริมาณมากและงานประจำที่ทำซ้ำโดยมีเป้าหมายชัดเจน เช่น ดึงข้อมูลจากช่องต่างๆ ในใบแจ้งหนี้ จัดประเภทคำขอ หรือสร้างสรุปแบบมีโครงสร้าง

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

• ระดับการให้เหตุผล: เมื่อใช้งานผ่าน API คุณเลือกได้ว่าจะให้โมเดลใช้ความพยายามในการคิดมากน้อยเพียงใดเพื่อทำงานนั้น

  • Low: งานทั่วไป เช่น ดึงข้อเท็จจริงหรือแก้ไขเล็กน้อย

  • Medium: งานที่ต้องใช้วิจารณญาณ เช่น วางแผนฟีเจอร์หรือเปรียบเทียบตัวเลือก

  • High: แก้บั๊กที่ซับซ้อน วิเคราะห์เชิงลึก หรือการตรวจทานอย่างละเอียด

  • Extra High / Max: หากระดับ High ยังให้ผลไม่ดีพอ ให้ลองใช้ระดับนี้กับโมเดลที่รองรับ และใช้ต่อเมื่อผลลัพธ์ที่ดีขึ้นคุ้มกับเวลาและค่าใช้จ่ายที่เพิ่มขึ้น

ใน API คุณสามารถเปลี่ยนระดับการให้เหตุผลระหว่างบทสนทนา⁠(เปิดในหน้าต่างใหม่)ได้โดยยังใช้แคชเดิมได้

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

• ความเร็ว:

  • เมื่อใช้ API ให้เลือกโหมด Fast⁠(เปิดในหน้าต่างใหม่) หากต้องการการตอบสนองที่รวดเร็ว เช่น ในแอปแชตหรือเครื่องมือเขียนโค้ด โหมดนี้ตอบสนองได้เร็วขึ้นและใช้เวลาสม่ำเสมอกว่า แต่มีค่าใช้จ่ายต่อโทเค็นสูงกว่าการประมวลผลแบบ Standard

  • เมื่อใช้ Codex หรือ API ให้เลือก Ultrafast⁠(เปิดในหน้าต่างใหม่) หากคุณยินดีจ่ายเพิ่มเพื่อให้ได้คำตอบเร็วขึ้น เช่น ในการเขียนโค้ดที่ต้องทดลองและปรับแก้บ่อยๆ โหมดนี้ช่วยให้สร้างโทเค็นได้เร็วขึ้น โดยไม่ขึ้นกับระดับการให้เหตุผลที่เลือก รองรับ GPT‑6 Astra⁠(เปิดในหน้าต่างใหม่)

เริ่มด้วยการมอบหมายงานให้ชัดเจน โดยระบุผลลัพธ์ที่ต้องการ กลุ่มเป้าหมาย บริบทและข้อจำกัดที่เกี่ยวข้อง รวมถึงเกณฑ์ที่ใช้ตัดสินว่างานเสร็จสมบูรณ์ จากนั้นทบทวนสี่ด้านต่อไปนี้ ซึ่งสรุปจากทบทวนแนวทางการใช้ทักษะและพรอมต์สำหรับ GPT‑6 Astra⁠(เปิดในหน้าต่างใหม่) เพื่อทำความเข้าใจวิธีปรับปรุงคำสั่งให้ลึกขึ้น

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

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

• กำหนดขอบเขตการตัดสินใจ: ระบุให้ชัดว่าการดำเนินการใดทำได้เอง และการดำเนินการใดต้องขออนุมัติ แทนการใช้กฎครอบคลุมทุกกรณีว่า “ต้องถามก่อนเสมอ”

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

ดูคำแนะนำเพิ่มเติมได้ที่แนวทางปฏิบัติที่ดีด้านการให้เหตุผล⁠(เปิดในหน้าต่างใหม่)

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

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

ตอนนี้โมเดลตระกูล GPT‑6 ช่วยให้คุณสามารถจัดการงานที่ใช้เวลาหลายชั่วโมงหรือหลายวันได้ ใช้ฟีเจอร์ต่อไปนี้เพื่อจัดการเอเจนต์ในงานที่ใช้เวลานานได้ดีขึ้น

ใน API ให้ใช้การกำกับทิศทาง เครื่องมือแบบอะซิงโครนัส และการทำงานแบบขนาน เพื่อให้งานที่ใช้เวลานานเดินหน้าต่อได้

• อัปเดตคำสั่งระหว่างทำงาน: การกำกับทิศทางระหว่างรอบการตอบ⁠(เปิดในหน้าต่างใหม่)ช่วยให้คุณส่งคำสั่งแก้ไขผ่าน Responses WebSocket API⁠(เปิดในหน้าต่างใหม่) ได้ขณะโมเดลทำงาน คำสั่งอัปเดตจะเข้าคิว โดยไม่ยกเลิกเครื่องมือที่กำลังทำงานหรือย้อนกลับการกระทำที่เสร็จแล้ว

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

• แบ่งงานย่อยที่ทำแยกกันได้: GPT‑6.1 Sol รองรับการทำงานร่วมกันของเอเจนต์หลายตัวใน Responses API⁠(เปิดในหน้าต่างใหม่) โดยมอบหมายงานที่ไม่ต้องรอผลจากกันและกันให้เอเจนต์ย่อยได้ เช่น ตรวจสอบส่วนต่างๆ ของโค้ด แล้วนำสิ่งที่แต่ละเอเจนต์พบมารวมเป็นคำตอบสุดท้าย ขณะนี้การทำงานแบบหลายเอเจนต์อยู่ในรุ่นเบต้า

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

• ตอบคำถามระหว่างที่งานคืบหน้า: เมื่อใช้ GPT‑6 Astra นั้น Codex สามารถขอคำชี้แจงขณะทำงานได้⁠(เปิดในหน้าต่างใหม่) ตอบคำถามที่มีผลต่อขั้นตอนถัดไป และระบุว่างานใดที่ไม่ขึ้นต่อกันสามารถทำต่อได้ระหว่างรอคุณตัดสินใจ หากคุณจะไม่อยู่ ให้บอก Codex ว่างานใดทำต่อได้และเมื่อใดควรหยุดรอคำตอบจากคุณ

• ปรับทิศทางงานเมื่อข้อกำหนดเปลี่ยน: กำกับทิศทางงานที่กำลังทำ⁠(เปิดในหน้าต่างใหม่)ด้วยข้อมูลใหม่ โดยอธิบายว่าสิ่งใดควรเปลี่ยนและสิ่งใดควรคงเดิม วิธีนี้ช่วยให้ไม่เสียเวลาเพิ่มไปกับแนวทางที่ไม่ตอบโจทย์คุณแล้ว

การใช้คอมพิวเตอร์⁠(เปิดในหน้าต่างใหม่)ช่วยให้ GPT‑6 Astra, GPT‑6.1 Sol และ GPT‑6 Luna โต้ตอบกับเว็บไซต์และแอปเดสก์ท็อปได้โดยตรง แม้แอปนั้นจะไม่มี API ตัวอย่างเช่น คุณอาจให้โมเดลตรวจหาสาเหตุของบั๊ก แก้โค้ด แล้วเปิดผลิตภัณฑ์ของคุณในเบราว์เซอร์เพื่อตรวจสอบว่าแก้ปัญหาได้จริง

เลือกวิธีที่ง่ายที่สุดและเชื่อถือได้สำหรับแต่ละขั้นตอน:

• ใช้ API หรือเครื่องมือที่เชื่อมต่อไว้ หากทำงานนั้นได้โดยตรง

• ใช้ความสามารถด้านการใช้คอมพิวเตอร์เมื่อโมเดลต้องอ่านหน้าจอ คลิกปุ่ม หรือกรอกแบบฟอร์มให้คุณ

เมื่อต้องการให้โมเดลใช้งานคอมพิวเตอร์ผ่านแอปของคุณได้ ให้เตรียมเครื่องมือที่โมเดลใช้รันโค้ดเพื่อควบคุมเบราว์เซอร์หรือเดสก์ท็อปได้ Playwright ใช้กับเบราว์เซอร์⁠(เปิดในหน้าต่างใหม่) และ PyAutoGUI ใช้กับแอปบนเดสก์ท็อป