Code Review Agent Benchmark: วิธีประเมินผู้รีวิว และรัน c-CRAB บนโค้ดของคุณเอง

คุณจะบอกได้อย่างไรว่าเอเจนต์ตรวจสอบโค้ดตัวหนึ่งดีหรือไม่? ในประวัติศาสตร์อันสั้นของสาขานี้ คำตอบส่วนใหญ่คือ “วัดว่าความเห็นของมันใกล้เคียงกับความเห็นของมนุษย์ผู้ตรวจสอบแค่ไหน” — ซึ่งฟังดูสมเหตุสมผลจนกว่าคุณจะลองทำจริง เพราะผู้ตรวจสอบสองคนอาจชี้ปัญหาเดียวกันด้วยถ้อยคำที่ต่างกันโดยสิ้นเชิง Code Review Agent Benchmark — ตัวบทความคือ arXiv:2603.23448 และชุดข้อมูลคือ c-CRAB — คือความพยายามจริงจังครั้งแรกที่จะให้คะแนนรีวิวจากผลลัพธ์ของการลงมือทำตามความเห็นนั้น มากกว่าจากถ้อยคำที่ใช้ เบนช์มาร์กนี้แปลงความเห็นรีวิวของมนุษย์ 234 รายการให้เป็นเทสต์ที่รันได้ นำผู้ตรวจสอบที่ใช้กันแพร่หลายสี่ตัวมาทดสอบ — PR-Agent, Devin, Claude Code และ Codex — แล้วพบว่าเมื่อรวมทั้งสี่ตัวเข้าด้วยกัน ผ่านเทสต์เหล่านั้นเพียง 41.5% ซึ่ง “ก็แค่ราว 40%” ในคำพูดของตัวบทความเอง หน้านี้คือคู่มือ: วิธีอ่านผลลัพธ์นั้นโดยไม่บิดเบือน วิธีรัน c-CRAB ด้วยตัวเอง และสิ่งที่ควรทำเมื่อโค้ดเบสของคุณไม่ได้อยู่ในเบนช์มาร์กนี้เลย

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

ทำไมเมตริกที่เห็นได้ชัดจึงใช้ไม่ได้

ก่อน c-CRAB การประเมินเอเจนต์ตรวจสอบโค้ด (code review agents) แบ่งออกเป็นไม่กี่ตระกูล และตารางเปรียบเทียบของบทความเอง (ตารางที่ 1) ก็แสดงลำดับเครือญาตินั้นไว้ วิธีที่เก่าแก่ที่สุดคือการทับซ้อนของข้อความ — BLEU, ROUGE, chrF และพวกพ้อง ซึ่งใช้ในเบนช์มาร์กอย่าง CodeReviewer และ ContextCRBench แนวคิดคือความคิดเห็นของเอเจนต์จะถือว่าดีเมื่อ n-grams ของมันตรงกับของมนุษย์ แนวคิดนี้พังทลายในกรณีประเภทหนึ่งที่พบได้ทั่วไปในการตรวจสอบโค้ด: ข้อบกพร่องเดียวกันแต่อธิบายด้วยคำต่างกัน

กรณีศึกษาของบทความนี้คือตัวอย่างที่ชัดเจนที่สุด ใน pull request ของ python-telegram-bot (PR #3514) ผู้ตรวจสอบที่เป็นมนุษย์และ Codex ต่างชี้บั๊กเดียวกันเกี่ยวกับความทนทานของการทำ nested indexing บทวิจารณ์ของ Codex ถูกต้องในเชิงพฤติกรรม — เอเจนต์เขียนโค้ดที่ปฏิบัติตามนั้นสร้างการแก้ไขที่ผ่านการทดสอบที่รันได้จริง ทว่าเมตริกข้อความให้คะแนนมันเป็น BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 และ embedding similarity 54.59 การทับซ้อนของ n-gram เป็นศูนย์ แต่บทวิจารณ์กลับถูกต้อง ข้อกังวลเดียวกัน แต่ใช้คนละคำ: เมตริกแบบสตริงมองไม่เห็นมัน embedding similarity เป็นการก้าวขึ้นบางส่วน — 54.59 เทียบกับการผ่านที่ยืนยันแล้วก็ยังห่างไกลจากเกณฑ์ที่ใช้งานได้ — และมันสืบทอดปัญหาเดียวกันในรูปแบบที่เบาลง

LLM-as-judge ซึ่งโมเดลเปรียบเทียบรีวิวของเอเจนต์กับของมนุษย์แล้วลงคะแนน ช่วยแก้ปัญหาคำศัพท์ได้ แต่นำปัญหาสามอย่างใหม่เข้ามา ซึ่งบทความระบุชื่อไว้โดยตรง: อคติ (bias), ความไม่เสถียร (instability), และความไวต่อการออกแบบพรอมป์ต์ (sensitivity to prompt design) เปรียบเทียบแบบเดียวกันสองครั้ง ผู้ตัดสินอาจให้ผลตัดสินที่ต่างกัน; เปลี่ยนถ้อยคำของพรอมป์ต์ตัดสิน ลำดับการจัดอันดับก็ขยับ เมื่อคุณต้องเลือกระหว่างผู้รีวิวสองคนที่ห่างกันสามคะแนนบนเกณฑ์มาตรฐานเดียวกัน ผู้ตัดสินที่มีความแปรปรวนเช่นนั้นไม่สามารถสนับสนุนการตัดสินใจได้ — และคะแนนที่คุณไม่สามารถทำซ้ำได้ก็ไม่ใช่คะแนน

โอราเคิลที่รันได้ให้อะไรกับคุณ — และแลกด้วยอะไร

แนวคิดที่ c-CRAB สร้างขึ้นมานั้นทั้งเรียบง่ายและสุดโต่งในเวลาเดียวกัน: แทนที่จะถามว่า "รีวิวฟังดูเหมือนที่มนุษย์เขียนหรือไม่?" ให้ถามว่า "ถ้าคุณทำตามรีวิว โค้ดจะได้รับการแก้ไขหรือไม่?" ความคิดเห็นรีวิวของมนุษย์ที่ถูกเก็บไว้แต่ละอันจะถูกแปลงเป็นเทสต์ที่สามารถรันได้เพื่อจับประเด็นที่ซ่อนอยู่ ความคิดเห็นรีวิวจะนับว่าถูกต้องก็ต่อเมื่อการทำตามนั้นก่อให้เกิดการแก้ไขที่ถูกต้องในเชิงพฤติกรรมและทำให้เทสต์ผ่าน — และทุกอินสแตนซ์มาพร้อมกับสภาพแวดล้อม Docker ที่รันได้ ดังนั้น "ทำให้เทสต์ผ่าน" จึงเป็นข้อเท็จจริง ไม่ใช่การตัดสิน

บทความนี้ให้คำนิยามของการทดสอบสองประเภท การทดสอบเชิงพฤติกรรม "นำเข้าและรันโค้ดที่ทดสอบในขณะรันไทม์" เรียกใช้ฟังก์ชัน "ด้วยอินพุตเฉพาะ" และตรวจสอบ "เอาต์พุตหรือยืนยันข้อยกเว้น" ส่วนการทดสอบเชิงโครงสร้าง "ตรวจสอบข้อความของซอร์สโค้ด จับคู่รูปแบบ และตรวจสอบพื้นผิว API เพื่อพิจารณาว่ามีการเปลี่ยนแปลงโค้ดที่ต้องการหรือไม่" การแบ่งขั้นสุดท้ายคือการทดสอบเชิงพฤติกรรม 42 รายการ (17.9%) และเชิงโครงสร้าง 192 รายการ (82.1%) — และความเบ้ดังกล่าวสมควรได้รับประโยคที่ตรงไปตรงมา: ส่วนใหญ่ของออราเคิลนี้คือการจับคู่รูปแบบบนข้อความซอร์ส ไม่ใช่การรันโค้ด มาตรฐานทองคำคือการทดสอบเชิงพฤติกรรม แต่ข้อมูลส่วนใหญ่คือเวอร์ชันเชิงปฏิบัติของมัน

การสร้างออราเคิลเป็นกรวยสี่ขั้นตอน และทุกขั้นตอนทิ้งสิ่งต่างๆ ออกไป:

• ชุดข้อมูลเริ่มต้น — 671 PRs, ความเห็นรีวิว 1,313 รายการ

{{1}}การกรองรีวิว{{/1}} — {{2}}410 PRs, 595 ความคิดเห็น{{/2}} {{3}}ตัวแยกประเภท LLM{{/3}} ที่ถูกปรับเทียบกับ{{4}}ชุดอ้างอิง (gold set) ของความคิดเห็น 100 รายการที่ถูก annotate ด้วยมือ{{/4}} จะเก็บเฉพาะ{{5}}ประเด็นที่ตรวจสอบได้อย่างเป็นกลาง{{/5}} และกรองทิ้ง{{6}}ความคิดเห็นเชิงสนทนาหรือเชิงอัตวิสัย{{/6}}

• การสร้างสภาพแวดล้อมที่รันได้ — 410 PR, 595 ความคิดเห็น หนึ่ง Docker image ต่อหนึ่ง PR โดยการแก้ไข dependency จะถอยกลับไปใช้ coding agent เมื่อระบบอัตโนมัติล้มเหลว

• การแปลงความคิดเห็นภาษาธรรมชาติเป็นเทสต์ — 339 PRs, 481 ความคิดเห็น สร้างด้วย GPT-5.2 ภายใต้ลูปการปรับปรุงที่นำทางการดำเนินการ (สูงสุดสามครั้ง); เทสต์จะถูกเก็บไว้ก็ต่อเมื่อมันล้มเหลวในเวอร์ชันก่อนหน้าและผ่านในเวอร์ชันหลัง

• การตรวจสอบกับเอเจนต์เขียนโค้ด — 184 PR, 234 ความคิดเห็น (รอบสุดท้าย) Claude Code บนแบ็กเอนด์ Sonnet-4.6 พยายามแก้ไขโค้ดโดยได้รับเพียงความคิดเห็นรีวิวจากมนุษย์เท่านั้น; กรณีที่ไม่สามารถทำให้เทสต์ผ่านได้จะถูกคัดทิ้ง

ประมาณ 27% ของ pull requests เริ่มต้นที่อยู่รอด จงกล่าวอย่างตรงไปตรงมา เพราะนี่คือราคาที่แท้จริงของออราเคิลที่อิงการทดสอบ: ถ้าความคิดเห็นไม่สามารถนำไปปฏิบัติได้พอที่จะกลายเป็นเทสต์ที่ล้มเหลว หรือสภาพแวดล้อมไม่สามารถสร้างได้ หรือเอเจนต์เขียนโค้ดที่มีความสามารถไม่สามารถแก้ไขโค้ดจากความคิดเห็นเพียงอย่างเดียว อินสแตนซ์นั้นจะถูกทิ้ง นี่คือเหตุผลที่เบนช์มาร์กมีขนาดเล็ก 184 PR instances และ 234 ความคิดเห็นที่ผ่านการตรวจสอบเป็นชุดข้อมูลที่คุณสามารถอ่านได้ ไม่ใช่คลังข้อมูลที่คุณจะจมอยู่ในนั้น — และสำหรับออราเคิลที่ต้องรันสภาพแวดล้อม Docker จริง ความเล็กเป็นจุดเด่น

เพื่อให้เห็นภาพ: อินสแตนซ์โดยเฉลี่ยเกี่ยวข้องกับบรรทัดที่ถูกแก้ไข 418.1 บรรทัด การทดสอบเฉลี่ย 31.8 บรรทัด และมีการทดสอบ 1.27 ครั้งต่ออินสแตนซ์ ผู้ให้คำอธิบายประกอบสองคนเห็นพ้องกัน 84% ของเวลา — จากอินสแตนซ์ที่สุ่มตัวอย่าง 50 รายการ — ว่าการทดสอบที่สร้างขึ้นจับประเด็นที่ผู้วิจารณ์มนุษย์กังวลได้อย่างซื่อสัตย์หรือไม่

จุดตำหนิทางบรรณานุกรมประการหนึ่งที่คุณจะพบหากไปอ่านบทความด้วยตัวเอง: ตารางชุดข้อมูล (ตารางที่ 4) ระบุคลังเก็บ 67 แห่ง ขณะที่ส่วนภัยคุกคามต่อความสมเหตุสมผล (Threats to Validity) กล่าวถึง "อินสแตนซ์ของ pull request 184 รายการ พร้อมออราเคิลที่ตรวจสอบได้ 234 รายการ จากคลังเก็บ 56 แห่ง" บทความให้ตัวเลขทั้งสองนี้ในสถานที่ต่างกันและไม่ได้ปรับให้สอดคล้องกัน อย่าเลือกข้างและอย่าหาค่าเฉลี่ย — ให้อ้างอิงแต่ละตัวเลขในตำแหน่งที่ปรากฏ ความคลาดเคลื่อนเช่นนี้คือรายละเอียดที่ผู้อ่านใช้ตัดสินว่า benchmark นั้นคุ้มค่ากับเวลาหรือไม่

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

วิธีอ่านสกอร์บน c-CRAB โดยไม่กล่าวอ้างผิดๆ

ตัวชี้วัดหลักคืออัตราการผ่าน: ต่ออินสแตนซ์คือสัดส่วนของเทสต์ของ PR นั้นที่ผ่าน โดยเฉลี่ยจากทั้งหมด 184 อินสแตนซ์ นี่คือตารางผลลัพธ์เต็มรูปแบบจากบทความ หนึ่งบรรทัดต่อผู้รีวิวหนึ่งคน แถวของมนุษย์เป็นตัววัดระดับ (scale marker) ไม่ใช่คู่แข่ง — เพราะมนุษย์เป็นคนเขียน oracle พวกเขาจึงได้คะแนน 100% โดยโครงสร้าง:

• Claude Code — 1,336 ความคิดเห็น, 7.3 ต่อ PR, โดยรวม 32.1% (เชิงพฤติกรรม 38.1%, เชิงโครงสร้าง 30.7%)

• Devin — 1,344 ความคิดเห็น, 7.3 ต่อ PR, โดยรวม 24.8% (เชิงพฤติกรรม 31.0%, เชิงโครงสร้าง 23.4%)

• PR-Agent — 524 ความคิดเห็น, 2.8 ต่อ PR, โดยรวม 23.1% (พฤติกรรม 38.1%, โครงสร้าง 19.8%)

• Codex — 324 ความคิดเห็น, 1.8 ต่อ PR, โดยรวม 20.1% (พฤติกรรม 38.1%, โครงสร้าง 16.1%)

• มนุษย์ — 234 ความคิดเห็น, 1.3 ต่อ PR, 100% โดยโครงสร้าง

การแก้ไขสามประการ เพราะตัวเลข "เพียงประมาณ 40%" ในบทคัดย่อเป็นตัวเลขที่ถูกอ้างถึงผิดมากที่สุดในวงสนทนาเกี่ยวกับนักเขียนโค้ด AI ในตอนนี้ ประการแรก ตัวเลข 41.5% — 97 จาก 234 การทดสอบที่ผ่านโดยเครื่องมืออย่างน้อยหนึ่งตัว — เป็นยูเนียนของผู้ประเมินทั้งสี่คน: การทดสอบหนึ่งครั้งจะนับเพียงครั้งเดียวหากเอเจนต์ใดก็ตามผ่านการทดสอบนั้น ไม่มีเอเจนต์ใดได้คะแนน 41.5% คะแนนเดี่ยวสูงสุดคือ Claude Code ที่ 32.1% ประการที่สอง แถวของมนุษย์คือออราเคิล ไม่ใช่ผู้เข้าแข่งขัน การนำมาพูดซ้ำว่า "มนุษย์ชนะบอต" เป็นความผิดพลาดเชิงหมวดหมู่ ประการที่สาม และสำคัญที่สุด: c-CRAB ไม่ให้เครดิตสำหรับปัญหาที่ถูกต้องซึ่งผู้ตรวจคนไม่เคยหยิบยกขึ้นมา ออราเคิลคือเจตนาของการตรวจสอบโดยมนุษย์ เอเจนต์ที่พบบั๊กจริงที่ไม่มีใครเอ่ยถึงจะได้คะแนนเป็นศูนย์สำหรับบั๊กนั้น ดังนั้น "เอเจนต์ตรวจสอบ AI จับบั๊กได้เพียง 40%" จึงผิดสามชั้น — มันเป็นยูเนียน ไม่ใช่อัตราการจับบั๊ก และมันวัดความสอดคล้องกับผู้ตรวจคน ไม่ใช่ความถูกต้องโดยรวม

ปริมาณความคิดเห็นคือกับดัก

ตัวเลขที่น่าสนใจที่สุดในผลลัพธ์ไม่ใช่ผู้ชนะ Claude Code และ Devin ต่างโพสต์ความคิดเห็นมากกว่า 1,300 รายการ — ประมาณ 7.3 รายการต่อ PR — เพื่อไปถึง 32.1% และ 24.8% ขณะที่ Codex โพสต์ 324 รายการ ประมาณ 1.8 รายการต่อ PR และไปถึง 20.1% ค่าพื้นฐานของมนุษย์คือ 1.3 ความคิดเห็นต่อ PR ปริมาณไม่ใช่ความครอบคลุม: ความคิดเห็นที่มากกว่าประมาณห้าเท่าให้อัตราการผ่านน้อยกว่าสองเท่า หากคุณกำลังเลือกผู้ตรวจทาน ต้นทุนที่แท้จริงของความคิดเห็นพิเศษทั้งหมดคือความเหนื่อยล้าในการตรวจทานของมนุษย์ — ทุกความคิดเห็นที่เอเจนต์โพสต์คือการตัดสินใจที่บุคคลต้องคัดกรอง

ข้อค้นพบด้านความมีประโยชน์กลับชี้ไปอีกทางหนึ่ง และเป็นส่วนที่ทำให้เรื่องนี้ไม่ใช่เรื่องเล่าแบบง่ายๆ ว่า "บอทส่งเสียงรบกวน" ผู้เขียนตรวจสอบด้วยตนเอง 92 ความคิดเห็นจาก 6 PR และประเมินว่า 84% (77/92) มีประโยชน์ — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78% ดังนั้น ความคิดเห็นส่วนใหญ่ที่ไม่ผ่านการทดสอบจึงไม่ใช่เสียงรบกวน แต่เป็นเรื่องที่ผู้ตรวจทานซึ่งเป็นมนุษย์ไม่ได้หยิบยกขึ้นมา กลุ่มตัวอย่างมีขนาดเล็ก — 92 ความคิดเห็น 6 PR — และสมควรกล่าวถึงควบคู่กับตัวเลขเปอร์เซ็นต์

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

ผู้ปฏิบัติที่ได้ทำงานผ่านสิ่งนี้มาจะพบกับข้อสรุปเดียวกัน งานเขียนรายละเอียดโดย Daniel Vaughan ซึ่งเรียกงานนี้ว่า CR-bench ได้ข้อสรุปเดียวกันและเปลี่ยนเป็นขั้นตอนการทำงาน: ให้เอเจนต์ทำการสำรวจความทนทานและความถูกต้อง คงมนุษย์ไว้กับงานออกแบบ ธรรมเนียมปฏิบัติ และสถาปัตยกรรม — หมวดหมู่ที่เอเจนต์ทำคะแนนได้แย่ที่สุด — และควบคุมเอเจนต์ด้วยคำแนะนำการตรวจทานที่ระบุหมวดหมู่ที่อ่อนแอ ข้อควรระวังที่มีประโยชน์ที่สุดของเขาสำหรับผู้ที่อ่านลีดเดอร์บอร์ด: "ความมีประโยชน์ไม่ใช่สิ่งเดียวกันกับอัตราการผ่าน" เพราะชุดทดสอบกำหนดให้ต้องตรงกับการแก้ไขที่มนุษย์ตั้งใจไว้ และการแก้ไขทางเลือกที่ถูกต้องจะสอบไม่ผ่าน เส้นทางจาก 20% ไปสู่คะแนนที่สูงขึ้นอย่างมีความหมาย ในความเห็นของเขา ไม่ใช่การอัปเกรดโมเดล — แต่เป็นการปรับการกำหนดค่า

การรัน c-CRAB ด้วยตนเอง

ทั้งหมดที่กล่าวมาข้างต้นคือการอ่านผลลัพธ์ของผู้อื่น แพ็กเกจการทำซ้ำทำให้เบนช์มาร์กรันได้ — มันอยู่ที่ c-CRAB-Benchmark/dataset บน GitHub — และ README ก็บอกตามตรงถึงสิ่งที่ต้องใช้.

ข้อกำหนด: code>uv sync/code>; Docker; และอย่างใดอย่างหนึ่งระหว่าง code>OPENAI_API_KEY/code> หรือ code>ANTHROPIC_API_KEY/code> (Claude Code อ่านข้อมูลประจำตัวเพิ่มเติมจาก code>~/.claude/.credentials.json/code>, ซึ่งถูกเมานต์เข้าไปในคอนเทนเนอร์โดยค่าเริ่มต้น). โครงสร้างมีห้าไดเรกทอรี: code>pipeline//code> (ตรรกะไปป์ไลน์และพรอมต์), code>execution//code> (ตัวสร้างอิมเมจ Docker และตัวช่วยรันไทม์), code>results_preprocessed//code> (ชุดย่อยของ benchmark ที่เผยแพร่), code>results_pipeline_funnel//code> (ไฟล์ JSONL ของ stage0–stage4 และสรุปฟันเนล), และ code>raw_results_compressed//code> (ผลลัพธ์การทดลองดิบ). ห้าขั้นตอนตามลำดับ:

1. สร้างสภาพแวดล้อม Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. นอกจากนี้ ยังมีอิมเมจที่สร้างไว้ล่วงหน้าเผยแพร่อยู่ภายใต้ GitHub packages org ของ c-CRAB-Benchmark หากคุณต้องการข้ามการ build

2. สร้างการทดสอบ — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. รวบรวมบทวิจารณ์พื้นฐาน — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. กำหนดค่าข้อมูลประจำตัวของเครื่องมือภายนอกที่เกี่ยวข้องก่อนขั้นตอนนี้

4. รันการแก้ไขเอเจนต์ — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. ประเมิน — ทำซ้ำหนึ่งครั้งต่อเครื่องมือ: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

มีสองสิ่งที่ README ไม่ได้กล่าวถึง การเพิ่มผู้ตรวจสอบคนที่ห้าหมายถึงการแก้ไข code>run_batch_baselines.py/code> — นั่นคือที่ที่ prompts การตรวจสอบ baseline ของแต่ละเครื่องมือตั้งอยู่ ไม่มีอินเทอร์เฟซปลั๊กอิน และ README ก็ไม่ได้ระบุจุดขยายที่สะอาดกว่านี้ อีกทั้งที่เก็บโค้ดนี้ไม่มีไฟล์ใบอนุญาตที่ชัดเจน ดังนั้นอย่าถือเอาเองว่าโค้ดเป็น MIT หรือ Apache — บทความเป็น CC BY 4.0 ส่วนข้อกำหนดของตัวโค้ดเองนั้นไม่ได้ถูกระบุไว้

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

เมื่อคุณไม่สามารถจัดหาออราเคิลที่ปฏิบัติการได้

จุดยืนที่ตรงไปตรงมาของทีมส่วนใหญ่คือ: เกณฑ์ชี้วัดถูกต้องที่ว่า LLM judge ไม่สามารถให้คะแนนรีวิวได้ แต่การสร้าง oracle ที่อิงจากการทดสอบสำหรับ PR ของคุณเองนั้นเป็นงานที่ใหญ่ ความแตกต่างที่ควรแยกแยะคือระหว่าง LLM judge ในฐานะผู้ให้คะแนนกับ LLM judge ในฐานะตัวกรอง การที่ c-CRAB ปฏิเสธการใช้ judge เป็น oracle ไม่ได้ทำให้ judge ไร้ประโยชน์ภายในตัวรีวิว — judge ที่จัดกลุ่มข้อค้นพบที่ซ้ำกันและตัดข้อที่อ่อนแอออกยังคงเพิ่มความแม่นยำได้ รูปแบบความล้มเหลวที่ต้องออกแบบเพื่อป้องกันคือความเป็นอิสระ

ตัวตัดสินที่ทำงานบนโมเดลเดียวกับตัวตรวจสอบจะเห็นด้วยกับตัวเอง: มันอ่านรีวิว เห็นว่าน่าเชื่อถือ แล้วรายงานว่าผ่าน โดยไม่เปลี่ยนแปลงอะไรเลย ตัวตัดสินจากผู้ให้บริการรายอื่นช่วยลดการเห็นด้วยกับตัวเองนั้น — มันไม่ได้ทำให้ตัวตัดสินกลายเป็นการทดสอบ แต่มันหยุดการรับรองแบบไม่ตรวจสอบ เราสามารถแสดงตัวอย่างที่เป็นรูปธรรมและตรวจสอบได้ของกลไกป้องกันนี้ เพราะชุดทดสอบของเราเองเปิดเป็นโอเพนซอร์ส: Orca-Code-Reviewบน GitHub ใช้สัญญาอนุญาต MIT และสูตรการจัดเส้นทางของมันระบุกฎไว้ในคำพูดของรีโพเอง — ตัวตัดสิน “ห้ามระบุชื่อโมเดลค่าเริ่มต้น” เพราะ “บนโมเดลเดียวกับตัวตรวจสอบ มันจะเห็นด้วยกับตัวเอง ขั้นตอนการตัดสินจึงไร้ผลในขณะที่ยังรายงานว่าสำเร็จ” แอคชันไม่เคยระบุชื่อโมเดล; สูตรเป็นผู้ตัดสิน ตามการจัดเตรียม ค่าเริ่มต้นของตัวตรวจสอบคือ deepseek/deepseek-v4-flash-0731 และกฎที่ตรงกับ code>x-cr-lens: judge/code> เฮดเดอร์จะส่งขั้นตอนตัวตัดสินไปยัง z-ai/glm-5.3 — ผู้ให้บริการรายอื่น นั่นคือความขนานเชิงออกแบบกับข้อโต้แย้งของ c-CRAB ไม่ใช่ผลลัพธ์: เราไม่ได้อยู่ในเกณฑ์ชี้วัด และไม่มีคะแนน c-CRAB สำหรับตัวตรวจสอบของเรา แต่นี่คือมาตรการบรรเทาผลกระทบเชิงปฏิบัติที่ใครก็ตามที่สร้างออราเคิลที่ปฏิบัติการได้ไม่ได้ก็สามารถใช้ได้ และมันถูกเมื่อตัวตัดสินและตัวตรวจสอบสามารถอยู่บนผู้ให้บริการต่างกันภายใต้คีย์เดียว — ซึ่งเป็นหน้าที่ของเราเตอร์ บน OrcaRouter ตัวตรวจสอบและตัวตัดสินของมันคือสองบรรทัดใน routing DSL และคุณจ่ายตามราคารายการของผู้ให้บริการโดยไม่มีมาร์กอัป

เมื่อโค้ดของคุณไม่ได้อยู่ใน benchmark

184 PRs ในที่เก็บโค้ดสาธารณะ 56 หรือ 67 แห่ง ไม่ใช่โค้ดเบสของคุณ และมันไม่เคยจะเป็นเช่นนั้น ส่วนที่ถ่ายทอดได้คือวิธีการ และคุณสามารถรันมันบนประวัติของคุณเองในขนาดที่เล็กกว่ามาก เลือก PR ที่ถูก merge แล้วซึ่งมีความคิดเห็นจากมนุษย์ในการรีวิว สำหรับตัวอย่างความเห็นเหล่านั้น ให้เขียนเทสต์ที่ล้มเหลวก่อนที่จะมีการดำเนินการตามรีวิว และผ่านหลังจากนั้น — คุณสมบัติ fail-then-pass คือหัวใจของเกมทั้งหมด รันตัวรีวิวที่คุณเสนอ บน diff ก่อนการรีวิว จากนั้นตรวจสอบว่าการลงมือทำตามความคิดเห็นของมันทำให้เทสต์ผ่านหรือไม่ สิ่งที่คุณได้คือตัวเลขที่คำนวณจากโค้ดที่คุณส่งจริง ซึ่งมีค่ามากกว่าตำแหน่งบนลีดเดอร์บอร์ด สิ่งที่มันเสียไปคือกำแพงเดียวกับที่งานวิจัยชนเข้า: คุณต้องมีสภาพแวดล้อมที่จำลองซ้ำได้ในแต่ละ PR เพราะเทสต์ที่ผ่านเฉพาะบนแล็ปท็อปของคุณไม่ใช่ oracle

คุณไม่จำเป็นต้องมีการทดสอบ 234 อย่าง การเลือกมาเพียงหนึ่งโหลที่คัดสรรมาอย่างดีบน PR ที่ทีมของคุณเคยถกเถียงกันจริง ๆ จะบอกคุณเกี่ยวกับผู้รีวิวได้มากกว่าคะแนน benchmark เสียอีก และการวิเคราะห์โดยผู้ปฏิบัติงานคู่ขนานต่อตระกูล benchmark นี้ก็พูดตรง ๆ เกี่ยวกับจุดคัดกรอง: ความแม่นยำของตัวแยกประเภท LLM ในการตัดสินว่าความเห็นเป็นปัญหาที่ถูกต้องและตรวจสอบได้หรือไม่นั้นอยู่ระหว่าง 66% ถึง 85% ดังนั้นจงถือว่าการกรองด้วยเครื่องเป็นเพียงรายการสั้น ๆ และคงขั้นตอนการตัดสินโดยมนุษย์ไว้ก่อนที่สิ่งใดจะกลายเป็นแบบทดสอบ บทความเดียวกันนี้ยังชี้ว่า ReviewBench ของ LangChain ซึ่งสร้างขึ้นอย่างอิสระบนแนวคิด comment-to-test แบบเดียวกัน เรียกคืนปัญหาในชุดพื้นฐานได้ประมาณ 30% อย่างดีที่สุด — ซึ่งเป็นระดับใกล้เคียงกับ 20–32% ของ c-CRAB และเป็นเครื่องเตือนใจว่าความต่างของคะแนนบนลีดเดอร์บอร์ดระดับหลักเดียวระหว่างเครื่องมือต่าง ๆ มักจะเล็กกว่า noise ในการตั้งค่าของคุณเอง

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

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

41.5% คือคะแนนที่ดีที่สุดของเอเจนต์หรือไม่ ไม่ใช่ 41.5% คือยูเนียนของเครื่องมือทั้งสี่ — การทดสอบจะถูกนับเพียงครั้งเดียวหากเครื่องมือใดเครื่องมือหนึ่งผ่าน คะแนนเดี่ยวที่ดีที่สุดคือ 32.1% ของ Claude Code

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

ผู้ตรวจสอบที่เป็นมนุษย์ "เอาชนะ" บอตได้หรือไม่ แถวที่เป็นมนุษย์ 100% คือตัวออราเคิลเอง — มนุษย์เป็นคนเขียนชุดทดสอบ — ดังนั้นมันจึงเป็นตัวชี้วัดระดับ ไม่ใช่คู่แข่ง

c-CRAB กับ CR-bench เป็นสิ่งเดียวกันหรือไม่? ใช่ ชุดข้อมูลคือ c-CRAB; สื่อภายนอกบางแห่งเรียกมันว่า CR-bench แต่ที่นี่มี benchmark เพียงตัวเดียวเท่านั้น

การรันมันมีค่าใช้จ่ายเท่าไร? รายงานไม่ได้เปิดเผยตัวเลขค่าใช้จ่าย หนึ่ง Docker image ต่อ PR ใน 184 อินสแตนซ์ บวกกับขั้นตอนการแก้ไขโดยเอเจนต์ บ่งบอกถึงพลังประมวลผลจริงๆ — ไม่ใช่ขนาดที่แล็ปท็อปจะประมวลผลเสร็จในบ่ายวันเดียว

บรรทัดล่าง

การมีส่วนร่วมของ c-CRAB ไม่ใช่ลีดเดอร์บอร์ด — แต่เป็นการสาธิตว่าบทวิจารณ์สามารถให้คะแนนได้โดยการปฏิบัติตามคำแนะนำของมัน และว่ารูปแบบความคล้ายคลึงของข้อความและการตัดสินโดย LLM ที่มีมาก่อนหน้านั้นให้คะแนนสิ่งที่ผิด หากคุณจะจดจำสิ่งหนึ่งจากนี้ จงจำการแก้ไขสามส่วนนี้: 41.5% คือยูเนียน, แถวของมนุษย์คือออราเคิล, และเกณฑ์ชี้วัดไม่ได้ให้คะแนนสำหรับข้อบกพร่องที่มนุษย์ไม่เคยหยิบยกขึ้นมา และถ้าคุณต้องการตัวเลขที่นำไปใช้ได้ วิธีการนี้ถ่ายโอนไปใช้ได้ — การทดสอบที่ล้มเหลวก่อนแล้วผ่านบน PR ที่คุณรวมเข้าด้วยกันเอง, ขั้นตอนการตัดสินโดยมนุษย์, และถ้าคุณไม่สามารถสร้างออราเคิลที่ปฏิบัติการได้ อย่างน้อยก็ผู้ตัดสินที่โมเดลเป็นอิสระจากโมเดลของผู้วิจารณ์

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