โมเดล บริบท และคำตอบที่ผิด

แยกความสามารถออกจากข้อมูลที่มี

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

“Frontier model” อธิบายระดับความสามารถที่เปลี่ยนแปลงตามเวลา คำนี้ไม่ได้พิสูจน์ว่าโมเดลอ่าน repository ของคุณแล้ว ไม่ได้แสดงว่าโมเดลรู้เวอร์ชัน dependency หรือกฎธุรกิจที่ไม่ได้เขียนไว้ สภาพแวดล้อมของงานต้องให้ข้อเท็จจริงเหล่านี้

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

การเปลี่ยนโมเดลอาจช่วยแก้ปัญหาข้อแรก ส่วนการให้ policy ที่ขาดไปหรือการตรวจสอบ dependency อาจแก้ปัญหาข้อที่สองได้

กำหนดบริบทของงานนี้

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

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

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

พิจารณาฟีเจอร์ตั้งค่าบัญชีสมมติ ให้ route, middleware สำหรับตรวจสอบสิทธิ์, data model ที่เกี่ยวข้อง และ test ที่มีอยู่ เพิ่มข้อจำกัดที่เจาะจงว่า “สมาชิกเปลี่ยนชื่อที่แสดงของตนได้ สมาชิกเปลี่ยนบทบาทของตนในองค์กรไม่ได้” ตอนนี้โมเดลมีกฎที่ชัดเจนซึ่งต้องรักษาไว้

ตรวจสอบข้อกล่าวอ้างในคำอธิบาย

คำตอบอาจระบุว่า endpoint ปลอดภัยเพราะ middleware ตรวจสอบความเป็นเจ้าของ ตรวจสอบแต่ละส่วนของข้อกล่าวอ้างนี้

1. ตรวจสอบว่า endpoint ใช้ middleware ที่ระบุ
2. ตรวจสอบว่า middleware ตรวจสอบความเป็นเจ้าของ ไม่ใช่เพียงยืนยันตัวตน
3. ระบุแหล่งที่มาของตัวตนผู้ใช้
4. ทดสอบกรณีที่ต้องถูกปฏิเสธโดยใช้ผู้ใช้อีกคน

การอ้างอิง repository ระบุจุดที่ต้องดู แต่ไม่ได้พิสูจน์ว่าคำอธิบายตรงกับโค้ด

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

เปลี่ยนความไม่แน่นอนเป็นการตรวจสอบ

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

ตัวอย่างเช่น “เรายังไม่ได้ตรวจสอบการแยก tenant สำหรับ endpoint นี้ ตรวจดู request handler เพิ่ม test ที่ผู้ใช้จาก tenant อื่นขอระเบียนเดียวกัน” คำสั่งนี้ให้งานสืบค้นที่เจาะจงและผลลัพธ์ที่สังเกตได้แก่ agent

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

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