# ตรวจสอบชุดข้อมูลก่อนตรวจตัวอย่าง

**บันทึกวิจัย · 7 กันยายน 2026 · เวิร์กโฟลว์การสุ่มตัวอย่างเป็นข้อเสนอ ไม่ใช่บริการตรวจสอบที่เปิดใช้แล้ว**

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

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

## กำหนดประชากรก่อนจับฉลาก

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

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

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

## การผูกมัดปกป้องชุด ไม่ใช่ความเกี่ยวข้องของชุด

การผูกมัดแบบ Merkle สามารถผูกข้อมูลกลุ่มหนึ่ง และหลักฐานการรวมสามารถแสดงว่าระเบียนอยู่ในโครงสร้างที่ผูกมัดนั้นภายใต้กติกาที่เลือก RFC 9162 ของ Certificate Transparency เป็นตัวอย่างต้นทางของกลไกพิสูจน์การรวมและความสอดคล้องแบบ Merkle ที่ระบุอย่างละเอียด แต่มันไม่ได้ทำให้ชุดข้อมูลแอปพลิเคชันใด ๆ ครบถ้วน และการอ้างถึงมันไม่ได้ทำให้ Proof21 เป็นการติดตั้งใช้งาน Certificate Transparency [1]

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

การผูกมัดยังต้องมีขอบเขตลำดับก่อนหลังเทียบกับแหล่งที่ใช้สุ่ม หากผู้ดำเนินการเห็นแหล่งการเลือกก่อน แล้วจึงสร้างชุดที่เข้าข้างตน การผูกมัดทีหลังไม่ช่วยแก้ขั้นตอนนั้น บทความเรื่อง [การเลือกโดยไม่สุ่มใหม่](https://proof21.xyz/th/journal/choice-without-rerolls/) อธิบายเงื่อนไขวงจรชีวิตนี้

## ใส่ตัวเลขให้คำถามที่มีขอบเขต

พิจารณาประชากรคงที่ในตัวอย่างจำนวน 1,000 ระเบียน ซึ่งมีระเบียนบกพร่องแน่นอน 20 รายการ เลือก 100 ระเบียนที่ไม่ซ้ำกันอย่างสม่ำเสมอโดยไม่ใส่คืน และสมมติว่าการประเมินตรวจพบข้อบกพร่องทุกอย่างในระเบียนที่เลือก ความน่าจะเป็นที่จะพบอย่างน้อยหนึ่งระเบียนบกพร่องคือ:

```text
1 - C(980, 100) / C(1000, 100) = 0.8809980814752082
```

ที่นี่ `C(n, k)` คือจำนวนวิธีเลือกแบบจัดหมู่ การคำนวณนี้อนุมานสำหรับตัวอย่าง ไม่ใช่ประสิทธิภาพ Proof21 ที่วัดจริง แม้อยู่ภายใต้สมมติฐานที่เอื้อเช่นนี้ โอกาสพลาดระเบียนบกพร่องทั้ง 20 รายการยังประมาณ 11.90% หากไม่ทราบจำนวนข้อบกพร่องจริง การคำนวณนี้ไม่ได้เปิดเผยจำนวนนั้นอย่างมหัศจรรย์ หากการประเมินตรวจพลาดหรือการเลือกไม่สม่ำเสมอ สมมติฐานก็ไม่เป็นจริงแล้ว

คำแนะนำการสุ่มเพื่อยอมรับของ NIST แยกแผนการสุ่มที่กำหนดไว้และการตัดสินใจต่อชุดออกจากการรับประกันคุณภาพทั่วไป ขนาดตัวอย่าง เกณฑ์ตัดสิน และความเสี่ยงที่ยอมรับได้เป็นส่วนของแผน คำว่า “เราสุ่มสิบเปอร์เซ็นต์” ไม่ใช่นโยบายที่ครบถ้วน [2][3] การจัดงานที่เกี่ยวข้องเป็นกลุ่มยังเปลี่ยนสิ่งที่ตัวอย่างบอกได้ การเลือกกลุ่มเดียวที่มีระเบียนคล้ายกันไม่ใช่แบบเดียวกับการเลือกแต่ละระเบียนอย่างอิสระทั่วประชากร

## ประเมินผู้ตรวจด้วย ไม่ใช่แค่การคัดเลือก

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

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

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

## รายงานที่ช่วยให้ผู้ใช้ผลตัดสินใจ

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

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

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

### ราก Merkle พิสูจน์ว่ามีทุกงานที่เข้าเกณฑ์หรือไม่?

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

### ตัวอย่างสะอาดพิสูจน์ว่าทั้งชุดไม่มีข้อบกพร่องหรือไม่?

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

### ผู้ดำเนินการแทนระเบียนที่ถูกเลือกแต่หาไม่ได้ได้หรือไม่?

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

## เอกสารต้นทางและอ่านต่อ

- [1: RFC 9162 — Certificate Transparency Version 2.0](https://www.rfc-editor.org/rfc/rfc9162.html)
- [2: NIST — การสุ่มเพื่อยอมรับคืออะไร](https://www.itl.nist.gov/div898/handbook/pmc/section2/pmc21.htm)
- [3: NIST — การเลือกแผนสุ่มครั้งเดียว](https://www.itl.nist.gov/div898/handbook/pmc/section2/pmc23.htm)
- [Proof21 Choice และ Sample](https://proof21.xyz/th/docs/capabilities/choice/)