אמת מידה לסוכן ביקורת קוד: כיצד להעריך מבקר, ולהריץ את 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, הערכות של סוכני ביקורת קוד נחלקו למספר קטן של משפחות, וטבלת ההשוואה של המאמר עצמו (טבלה 1) מציגה את השושלת. העתיקה ביותר היא חפיפת טקסט — BLEU, ROUGE, chrF וכדומה, המשמשות אמות מידה כמו CodeReviewer ו-ContextCRBench. הרעיון הוא שהערת סוכן טובה כאשר ה-n-grams שלה תואמים את אלה של אדם. הרעיון קורס במקרה האחד שמופיע בכל מקום בביקורת קוד: אותו פגם המתואר במילים שונות.

מקרה המבחן של המאמר הוא הדוגמה המובהקת ביותר. ב-pull request בפרויקט python-telegram-bot (PR #3514), המבקר האנושי ו-Codex ציינו שניהם את אותה בעיית חוסן באינדוקס מקונן. הביקורת של Codex הייתה נכונה מבחינה התנהגותית — סוכן קידוד שפעל לפיה הפיק תיקון שעבר את הבדיקה הניתנת להרצה. עם זאת, מדדי הטקסט העניקו לה ציון BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, ודמיון embedding של 54.59. אפס חפיפה של n-grams, והביקורת הייתה צודקת. אותו חשש, מילים שונות: מדדי המחרוזות לא הצליחו לראות זאת. דמיון embedding הוא שיפור חלקי — 54.59 אל מול מעבר מאושר עדיין רחוק מאוד מסף שמיש — והוא יורש את אותה בעיה בצורה רכה יותר.

ה-LLM בתפקיד שופט, שבו מודל משווה את הביקורת של הסוכן לזו של האדם ומצביע, פותר את בעיית אוצר המילים אבל מייבא שלוש חדשות, שהמאמר שם עליהן את האצבע: הטיה, חוסר יציבות, ורגישות לעיצוב ההנחיה. תריץ את אותה השוואה פעמיים, ושופט עלול להחזיר לך פסקי דין שונים; נסח מחדש את הנחיית השיפוט, והדירוגים זזים. כשאתה בוחר בין שני מבקרים שהפרש ביניהם שלוש נקודות על אותו מדד, שופט עם שונות כזו לא יכול לתמוך בהחלטה — וציון שאי אפשר לשחזר אינו ציון.

מה אורקל בר-הרצה קונה — ומה הוא עולה

הרעיון שעליו בנוי c-CRAB הוא פשוט ומהפכני בעת ובעונה אחת: במקום לשאול "האם הביקורת נשמעת כמו של האדם?", שאל "אם תפעל על פי הביקורת, האם הקוד מתוקן?". כל הערת ביקורת אנושית שנשמרת מומרת לבדיקה ניתנת להרצה הלוכדת את הבעיה הבסיסית. הערת ביקורת נחשבת לנכונה אם פעולה על פיה מפיקה תיקון נכון התנהגותית שגורם לבדיקה לעבור — וכל מופע מגיע עם סביבת Docker ניתנת להרצה, כך ש"הבדיקה עוברת" הוא עובדה ולא שיפוט.

המאמר מגדיר שני סוגי מבחנים. בדיקות התנהגותיות "מייבאות ומריצות את הקוד הנבדק בזמן ריצה", קוראות לפונקציות "עם קלטים ספציפיים" ובודקות "פלטים או מאמתות חריגות". בדיקות מבניות "בוחנות את טקסט קוד המקור, תואמות תבניות, ובודקות משטחי API כדי לקבוע האם בוצעו השינויים הרצויים בקוד". החלוקה הסופית היא 42 בדיקות התנהגותיות (17.9%) ו-192 מבניות (82.1%) — וההטיה הזו ראויה למשפט כן: רובו של אורקל זה הוא התאמת תבניות על טקסט המקור, לא הרצת הקוד. תקן הזהב הוא הבדיקה ההתנהגותית; רוב מערך הנתונים הוא הגרסה המעשית שלה.

בניית האורקל היא משפך בן ארבעה שלבים, וכל שלב זורק דברים:

• מערך נתונים ראשוני — 671 PRs, 1,313 הערות סקירה.

• סינון ביקורות — 410 PRs, 595 תגובות. מסווג LLM, המכויל כנגד קבוצת זהב של 100 תגובות שסומנו ידנית, משאיר רק בעיות הניתנות לאימות אובייקטיבי ומסיר משוב שיחתי או סובייקטיבי.

• בניית סביבת הרצה — 410 PRs, 595 תגובות. תמונת Docker אחת לכל PR, ופתרון התלויות מתבצע באמצעות סוכן קידוד כגיבוי כאשר האוטומציה נכשלת.

• המרת הערות NL לבדיקות — 339 PRs, 481 הערות. נוצר עם GPT-5.2 תחת לולאת עידון מונחית-ביצוע (עד שלושה ניסיונות); בדיקה נשמרת רק אם היא נכשלת בגרסה שלפני ועוברת בגרסה שאחרי.

• אימות עם סוכן קידוד — 184 PRs, 234 הערות (סופי). Claude Code על backend של Sonnet-4.6 מנסה לתקן את הקוד בהינתן רק הערת הביקורת האנושית; מקרים שבהם אינו מצליח להעביר את הבדיקה נמחקים.

כ-27% מבקשות המשיכה הראשוניות שורדות. צריך לומר זאת בפשטות, כי זה המחיר הכנה של אורקל מבוסס בדיקות: אם תגובה אינה ניתנת לביצוע מספיק כדי להפוך לבדיקה שנכשלת, או שלא ניתן לבנות את הסביבה, או שסוכן קידוד כשיר אינו יכול לתקן את הקוד מהתגובה בלבד — המופע נמחק. זו גם הסיבה שהבֶּנצ'מארק קטן. 184 מופעי PR ו-234 תגובות מאומתות הם מערך נתונים שאפשר לקרוא, לא קורפוס שאפשר לטבוע בו — ובשביל אורקל שצריך להריץ סביבות Docker אמיתיות, הקטנות היא תכונה.

לקנה מידה: מופע ממוצע נוגע ב-418.1 שורות ששונו, בדיקות ממוצעות של 31.8 שורות, ויש 1.27 בדיקות לכל מופע. שני מסמנים הסכימו ב-84% מהמקרים — על פני 50 מופעים שנדגמו — בשאלה האם בדיקה שנוצרה תפסה נאמנה את החשש של הסוקר האנושי.

פגם ביבליוגרפי אחד שתיתקל בו אם תקרא את המאמר בעצמך: טבלת הנתונים (טבלה 4) מונה 67 מאגרים, בעוד שבחלק "איומים על התוקף" נכתב "184 מופעי pull request עם 234 אורקלים ניתנים לאימות ב-56 מאגרים." המאמר מציג את שני המספרים במקומות שונים ואינו מיישב ביניהם. אל תבחר מועדף ואל תחשב ממוצע — צטט כל אחד במקום שבו הוא מופיע. פערים כאלה הם בדיוק הפרט שבו קוראים משתמשים כדי להחליט אם benchmark שווה את זמנם.

לצורך בדיקת נאותות בנושא העצמאות: המאמר חושף כי אחד המחברים מזוהה עם SonarSource, וקובע שאין לפרש את הממצאים כ"הערכה של איכות המוצרים של SonarSource". זהו כתב הוויתור שלהם, המובא כציטוט ולא כפרפרזה.

כיצד לקרוא פרטיטורה ב‑c‑CRAB מבלי לצטט אותה באופן שגוי

המדד המרכזי הוא שיעור המעבר: עבור כל מופע, חלק הבדיקות של אותו PR שעברו, בממוצע על פני 184 המופעים. הנה טבלת התוצאות המלאה מהמאמר, שורה אחת לכל מבקר. שורת בני האדם היא סמן סולם ולא מתחרה — בני האדם כתבו את האורקל, ולכן הם מקבלים 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%; הציון הבודד הטוב ביותר הוא 32.1% של Claude Code. שנית, שורת האדם היא האורקל, לא מתמודדת; לחזור עליה כ"בני אדם מנצחים את הבוטים" היא שגיאה קטגורית. שלישית, והכי חשוב: 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 PRs ושיפוטו ש-84% (77/92) מהן מועילות — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. אז רוב התגובות שנכשלות במבחן אינן רעש; הן עוסקות במשהו שהמבקר האנושי לא העלה. המדגם קטן — 92 תגובות, 6 PRs — וראוי לציין זאת באותה נשימה עם האחוזים.

מה שהצדדים השניים בפועל מדברים עליו מסביר את צורת התוצאות. הסוקרים האנושיים נטו לטובת יכולת תחזוקה, עיצוב ותיעוד; הכלים נטו לטובת עמידות, בדיקות וטיפול בשגיאות. המאמר קורא זאת כטיעון בעד שיתוף פעולה בין אדם לסוכן, ולא החלפה — וזוהי גם ההסבר הטוב ביותר הזמין למדוע הציונים נראים נמוכים. סוקר חד בקצוות קצה אך שקט בכל הנוגע לעיצוב יפספס באופן שיטתי את הקטגוריות שבני אדם מסמנים, והאורקל בנוי כולו מסימונים אנושיים.

מי שהתנסו בתהליך מגיעים לאותה מסקנה. כתב־תיאור מפורט של דניאל ווהן, המכנה את העבודה CR-bench, מגיע לאותה מסקנה והופך אותה לזרימת עבודה: נותנים לסוכן לבצע את סריקת החוסן והנכונות, משאירים לבני אדם את העיצוב, המוסכמות והארכיטקטורה — הקטגוריות שבהן הסוכנים משיגים את התוצאות הגרועות ביותר — ומנחים את הסוכן באמצעות הוראות ביקורת המפרטות את הקטגוריות החלשות. האזהרה השימושית ביותר שלו לכל מי שקורא את לוח המובילים: "שימושיות אינה זהה לשיעור המעבר", כי ערכת הבדיקות דורשת התאמה לתיקון שהאדם התכוון אליו, ותיקון חלופי תקף נכשל בבדיקה. הדרך מ־20% לציון גבוה יותר באופן משמעותי, לדעתו, אינה שדרוג מודל — היא עבודת תצורה.

הרצת c-CRAB בעצמך

כל מה שלמעלה הוא קריאת תוצאות של אחרים. חבילת השכפול מאפשרת להריץ את ה-benchmark — היא נמצאת בכתובת 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> (תת-קבוצת הבenchmark שפורסמה), 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>. תמונות מוכנות מראש מתפרסמות גם תחת ארגון החבילות של c-CRAB-Benchmark ב-GitHub, אם תרצו לדלג על הבנייה.

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> — שם נמצאות הנחיות סקירת הבסיס לכל כלי, ואין ממשק תוספים; ה-README אינו מתעד נקודת הרחבה נקייה יותר. והמאגר אינו כולל קובץ רישיון מפורש, אז אל תניח שהקוד הוא MIT או Apache — המאמר הוא CC BY 4.0, ותנאי הקוד עצמו לא צוינו.

העלות היא הפריט הנוסף שלא פורסם. המאמר אינו מציג נתוני אסימונים או דולרים עבור הפעלת הצינור, לכן התייחסו לכל מספר עלות שתמצאו מצוטט ברשת כלא מאומת. מה שהמבנה מרמז עליו ברור מספיק: תמונת Docker אחת לכל PR על פני 184 מופעים, בתוספת מעבר פתרון של סוכן קידוד ומעבר הערכה לכל כלי. זה לא אחר צהריים בקנה מידה של מחשב נייד — תקצבו למחשוב אמיתי.

כאשר אינך יכול להרשות לעצמך אורקלים ברי-הרצה

העמדה הכנה של רוב הצוותים היא: ה-benchmark צודק בכך ששופט LLM אינו יכול לדרג ביקורות, אבל בניית אורקל מבוסס-בדיקות עבור ה-PRs שלכם היא מאמץ גדול. ההבחנה שכדאי לעשות היא בין שופט LLM שמשמש כמדרג לבין שופט LLM שמשמש כמסנן. הדחייה של c-CRAB את השופט כאורקל אינה הופכת שופט לחסר-תועלת בתוך מבקר — שופט שמקבץ ממצאים כפולים ומסנן חלשים עדיין יכול להעלות את רמת הדיוק. מצב הכשל שצריך לתכנן נגדו הוא אי-התלות.

שופט שרץ על המודל של הסוקר עצמו מסכים עם עצמו: הוא קורא את הביקורת, מוצא אותה סבירה, ומדווח על הצלחה בלי לשנות דבר. שופט של ספק אחר מפחית את ההסכמה העצמית הזו — הוא לא הופך שופט לבדיקה, אבל הוא עוצר את חותמת הגומי. אנו יכולים להראות לך מקרה קונקרטי וניתן לבדיקה של בדיוק מנגנון ההגנה הזה, מכיוון שרתמת הבדיקה שלנו פתוחה: Orca-Code-Reviewב-GitHub הוא תחת רישיון MIT, ומתכון הניתוב שלו מציין את הכלל במילותיו של המאגר עצמו — השופט "אסור לנקוב בשם המודל המוגדר כברירת מחדל", כי "על המודל של הסוקר עצמו הוא מסכים עם עצמו, ולכן האישור הופך לרדום בעודו מדווח על הצלחה". הפעולה לעולם אינה נוקבת בשם מודל; המתכון הוא שמחליט. בתצורה שסופקה, ברירת המחדל של הסוקר היא deepseek/deepseek-v4-flash-0731, וכלל שתואם לכותרת code>x-cr-lens: judge/code>

כשהקוד שלך לא נמצא בבנצ'מרק

184 בקשות משיכה (PRs) ב-56 או 67 מאגרים ציבוריים אינם בסיס הקוד שלך, ומעולם לא נועדו להיות כאלה. החלק שניתן להעברה הוא השיטה, ואתה יכול להריץ אותה על ההיסטוריה שלך בקנה מידה קטן בהרבה. קח PRs שמוזגו והיו להם תגובות ביקורת אנושיות. עבור מדגם של תגובות אלה, כתוב בדיקה שנכשלת לפני ביצוע פעולה לפי הביקורת ועוברת אחריה — תכונת "נכשל ואז עובר" היא כל המשחק. הרץ את המבקר המועמד שלך על ה-diff שלפני הביקורת. לאחר מכן בדוק אם פעולה לפי הערותיו גורמת לבדיקה לעבור. מה שאתה מקבל הוא מספר המחושב על הקוד שאתה באמת משחרר, ששווה יותר ממקום בלוח התוצאות. המחיר הוא בדיוק הקיר שהמאמר נתקל בו: אתה צריך סביבות ניתנות לשחזור לכל PR, כי בדיקה שעוברת רק על הלפטופ שלך אינה אורקל.

אינכם זקוקים ל-234 בדיקות. תריסר בדיקות שנבחרו היטב על PRs שהצוות שלכם ממש התווכח עליהם יגידו לכם יותר על הסוקר שלכם מאשר ציון בנצ'מרק. ניתוח מתרגלים מקביל של משפחת הבנצ'מרקים הזו הוא בוטה בנוגע לשער: הדיוק של מסווג ה-LLM בקביעה אם תגובה היא בעיה תקפה וניתנת לאימות נוחת בין 66% ל-85%, לכן התייחסו לסינון הממוכן כרשימה מצומצמת ושמרו על שלב הכרעה אנושית לפני שדבר כלשהו הופך לבדיקה. אותו מסמך מציין ש-ReviewBench של LangChain, שנבנה באופן בלתי תלוי על אותו רעיון של המרת תגובה לבדיקה, משחזר במקרה הטוב כ-30% מבעיות הבסיס שלו — באותו טווח כמו 20–32% של c-CRAB, ותזכורת לכך שהפרשים חד-ספרתיים בלוח התוצאות בין כלים הם לעתים קרובות קטנים יותר מהרעש בהגדרה שלכם.

אם אתה בכלל שוקל איזה כלי ביקורת לקנות, זו שאלה אחרת — המדריך לרוכש של סוכן ביקורת הקוד שלנו מכסה בוט מול סוכן, תמחור לפי מושב מול לפי טוקן, ומתי אירוח עצמי מנצח — וברגע שיש לך אחד, עלות ההפעלה של רתמת ביקורת על כל דחיפה מכוסה במסביר ביקורת הקוד האוטומטי שלנו. הדף הזה עוסק רק במדידה, והמאמר המלווה לדף זה סוקר את האנטומיה של המדד: משפך הבנייה, סטטיסטיקות מערך הנתונים, וטבלת התוצאות המלאה.

שאלות נפוצות

האם 41.5% הוא הציון הטוב ביותר של הסוכן?לא. 41.5% הוא האיחוד של כל ארבעת הכלים — מבחן נספר פעם אחת אם אחד מהם עבר אותו. הציון הבודד הטוב ביותר הוא 32.1% של Claude Code.

האם c-CRAB מודד כמה באגים סוקר תופס? לא. הוא מודד עד כמה סקירה תואמת למה שסוקר אנושי העלה, כשהוא מומר לבדיקות ברות-הרצה. פגם אמיתי שהאדם מעולם לא הזכיר מקבל ציון אפס, תהא תקפותו אשר תהא.

האם הבודקים האנושיים "ניצחו" את הבוטים? שורת ה-100% אנושי היא האורקל עצמו — בני האדם כתבו את הבדיקות — ולכן היא סמן קנה מידה, לא מתחרה.

האם c-CRAB הוא אותו דבר כמו CR-bench? כן. סט הנתונים הוא c-CRAB; חלק מהסיקורים של צד שלישי קוראים לו CR-bench, אבל יש כאן רק אמת מידה אחת.

כמה עולה להריץ את זה?המאמר לא מפרסם נתוני עלות. תמונת Docker אחת לכל PR על פני 184 מופעים, בתוספת מעבר פתרון-סוכנים, מרמזת על כוח מחשוב אמיתי — לא אחר צהריים בקנה מידה של מחשב נייד.

השורה התחתונה

תרומת c-CRAB אינה לוח התוצאות — אלא ההדגמה שאפשר לדרג ביקורת על ידי ביצוע העצות שבה, ושהשיטות של דמיון טקסט ושל שופט LLM שקדמו לה דירגו את הדבר הלא נכון. אם יש דבר אחד שתיקחו מהמאמר, שיהיה זה התיקון המשולש: 41.5% הוא איחוד, השורה האנושית היא האורקל, והבנצ'מרק לא נותן קרדיט לפגמים שבני אדם לא העלו מעולם. ואם אתם רוצים מספר שתוכלו לפעול לפיו, השיטה ניתנת להעברה — בדיקות שנכשלות ואז עוברות על ה-PRs הממוזגים שלכם, שלב של הכרעה אנושית, ואם אינכם יכולים לבנות אורקלים ניתנים להרצה, לפחות שופט שהמודל שלו בלתי תלוי במודל של הסוקר.

אם אתם מעדיפים למדוד מבקר מאשר להתווכח על אחד, התחילו מרתמה שאתם יכולים לקרוא. OrcaCode Review מריץ מעבר סקירה בתוספת שופט אימות בלתי תלוי, לפי טוקן במקום לפי מושב, וכל פרומפט בו הוא ציבורי — כך שאתם יכולים לכוון אותו לבנצ'מרק כמו זה ולקבל מספר משלכם במקום שלנו.