چیتشیت
مناظره، نقشها و پنلهای بازبینی
Debate, Roles and Review Panels
اجرای N ایجنت در R دور، تقسیم کار بین طراح، مجری، ناقد و اعتبارسنج، و مشروطسازی بازبینیها به حد نصاب (quorum).
فهرست مطالب
پروتکل مناظره
گامبهگام- هر یک از N ایجنتیک پاسخ اولیه برای پرسش تولید میکند.
- دور r = 2..Rهر ایجنت پاسخهای دور r-1 سایر ایجنتها را میخواند.
- هر ایجنتطرفهای ارتباط را نقد کرده و پاسخ بهروزشدهای ارائه میدهد.
- هر دورپرسش را مجدداً تزریق کنید تا از دریفت موضوع جلوگیری شود.
- پس از R دوربر سر پاسخهای نهایی رأیگیری اکثریتی انجام دهید.
- هزینهN ایجنت × R دور = N·R فراخوانی LLM با زمینهی در حال رشد.
توپولوژیهای مناظره
مقایسه| عامل | مش کامل | ستارهای کمپشت |
|---|---|---|
| چه کسی چه کسی را میخواند | هر مناظرهکننده تمام طرفهای ارتباط را میخواند | شاخهها فقط هاب را میخوانند |
| Runner | full_mesh_round | sparse_star_round |
| تعداد عملیات در هر دور | ops += len(peers) به ازای هر مناظرهکننده | شاخهها فقط هاب را میخوانند |
| N=5, R=3 | 60 عملیات نقد | 12 عملیات نقد |
| پیشنهادها در N=5, R=3 | 15 | 15 |
| ریسک اصلی | فروپاشی همگرایی | شکست هاب |
| راهکار رفع ریسک | الزامی کردن دورهای عدم توافق | چرخش هاب یا استفاده از چند هاب |
چهار نقش بنیادین
مفهومها- طراح (Planner)
- هدف را میخواند. خروجی یک برنامه یا مشخصات ساختاریافته است.
- مجری (Executor)
- در هر نوبت یک گام برنامه را میخواند. خروجی همان دستسازه است.
- ناقد (Critic)
- دستسازه را در برابر برنامه میسنجد. خروجی پذیرش/رد همراه با دلایل است.
- اعتبارسنج (Verifier)
- یک بررسی قطعی را اجرا میکند. خروجی قبولی/رد همراه با شواهد است.
- ناقد در برابر اعتبارسنج
- ناقد ذهنی و مبتنی بر LLM است. اعتبارسنج کد است. اینها یک نقش یکسان نیستند.
- حذف ارتباطی توهم
- در صورت نبود یک جزئیات، مجری نقش مربوطه را بر اساس نام خطاب قرار میدهد.
- الگوی SOP
- فرمول
Code = SOP(Team). هر نقش دارای اسکیما ورودی/خروجی سختگیرانهای است.
پایپلاین نقشها در کد
کدpython
spec = planner(user_wish) # مشخصات فنی با امضا و 3 تست
art = executor(spec) # دستسازه یک رشته کد را نگه میدارد
crep = critic(spec, art) # بررسی def، return، نام تسک
vrep = verifier(spec, art) # تستها را اجرا میکند
exec(art.code, ns, ns) # فضای نام ساندباکسِ verifier
fn = ns.get(spec.task_name) # نبود شیء قابل فراخوانی باعث شکست میشود
got = fn(*args) # مقایسه با مقدار مورد انتظار
if crep.approved and vrep.passed: # تنها در صورت قبولی هر دو منتشر کنید
معماری تیم نرمافزاری
معماریپیامهای تابلوی تسکها
دستورها| دستور | عملکرد |
|---|---|
plan_request | معمار برنامه را همراه با DAG زیرتسکها ثبت میکند |
subtask | معمار یک زیرتسک و فایلهای آن را به کدنویس میفرستد |
diff_ready | کدنویس پچ را به merge_coord ارسال میکند |
review_needed | هماهنگکنندهی مرج تفاوتهای بازنگری مرجشده را به بازبین میفرستد |
review_feedback | بازبین درخواستهای تغییر را به کدنویس ارجاع میدهد |
approved | بازبین تفاوتهای بازنگری را به تستر تحویل میدهد |
test_passed | تستر به pr_opener دستور باز کردن PR را میدهد |
test_failed | تستر stacktraceها را به کدنویس بازمیگرداند |
API پنل بازبینی
کار و کد| وظیفه | کد |
|---|---|
| رد مکانهای ساختگی | validateFinding(raw, files) |
| دستهبندی بر اساس فایل، خط، قاعده | aggregate(reviews, files, quorum = 2) |
| اجرای بازبینها همراه با محدودیتها | runPanel(reviewers, budget, timeoutMs = 1000) |
| امتیازدهی در برابر برچسبها | evaluate(predicted, expected) |
| کلید دستهبندی | JSON.stringify([f.file, f.line, f.rule]) |
| اجرای دمو | node cli.ts --input samples/review.json |
| وارد کردن گزارش PR | --pr-report /path/review.json |
کد حد نصاب و بودجه
کدtypescript
if (ids.has(review.reviewer)) throw new Error("duplicate reviewer");
if (seen.has(key)) continue; // یک رأی به ازای هر بازبین در هر گروه
status: g.supporters.length >= quorum ? "consensus" : "needs-review",
disagreement: new Set(g.severities).size > 1,
if (spent + r.cost > budget) { // وضعیت ردگیری محاسبات: "budget-skipped"
controller.abort(); // رسیدن به موعد زمانی، وضعیت: "timeout"
precision: p.size ? hits / p.size : 0, // پیشبینیهای صفر نتیجهی 0 میدهند
پیشفرضها و ارقام
پیشفرضها| تنظیم | پیشفرض | نکته |
|---|---|---|
Debate rounds cap | 3 | 3 دور بخش عمدهی بهبود را به دست میآورد |
Debate agents cap | 5 | فراتر از 5، باد کردن زمینه و هزینه غالب میشوند |
Original Du et al. setup | N=3, R=2 | انتخابشده به دلیل هزینه |
Critic revision rounds | 2 | سپس ارجاع به انسان |
CLI `quorum` | 2 | حامیان مورد نیاز برای اجماع |
CLI `budget` | 3 | واحدهای هزینهی بازبین |
CLI `timeout` | 1000 | میلیثانیه به ازای هر بازبین |
maxTurns | 12 | محدودیت نوبت گفتوگوی هماهنگکننده |
حالتهای شکست
عیبیابیهمهی ایجنتها سخن پرصداترین را تکرار میکنند
- علت
- آبشار تملق
- راهحل
- یک ایجنت باید بر سر موضع مخالف استدلال کند
پاسخها از پرسش فاصله میگیرند
- علت
- دریفت موضوع در طول دورهای متعدد
- راهحل
- تزریق مجدد پرسش در هر دور
هزینهی بیش از 10 برابر یک فراخوانی CoT
- علت
- انفجار محاسباتی، N·R فراخوانی
- راهحل
- محدود کردن دورها به 3 و ایجنتها به 5
همه بر سر پاسخ نادرست یکسانی توافق دارند
- علت
- پرامپت و مدل یکسان برای همه
- راهحل
- استفاده از پرامپتها و مدلهای متنوع
یک ایجنت نامناسب همه را خراب میکند
- علت
- هاب نامناسب در توپولوژی ستارهای
- راهحل
- چرخش هاب یا استفاده از چند هاب
کد ظاهراً درست ولی همراه با باگ منتشر میشود
- علت
- پایپلاین تماماً LLM، بدون اعتبارسنج
- راهحل
- افزودن بررسی قبولی/رد مبتنی بر کد
بازبین یک باگ شناختهشده را تأیید میکند
- علت
- تایید اشتباه
- راهحل
- آزمون ارزیابی با باگ تزریقشده، تنظیم زیر 5%
اعدادی که باید به خاطر سپرد
مفهومها- 5 ایجنت، 5 دور
- 25 فراخوانی با زمینهی در حال رشد.
- NLSOM
- جوامعی متشکل از 129 عضو.
- MAST
- ردیابی 1642 شکست. 21.3% آنها شکاف اعتبارسنجی بودند.
- حلقهی اعتبارسنجی
- دقت از 10% به 70%. بهبودی 7 برابری تنها با یک نقش.
- افزایش تصاعدی توکن
- یک اجرای تکایجنتی 40 نوبتی، در چهار نقش به 160 نوبت تبدیل میشود.
- شیوهنامهی نمرهدهی
- 25 نمره pass@1، 20 شتاب، 20 کیفیت بازبینی، 20 بهرهوری توکن، 15 هماهنگی.
پرسشها
پرسش و پاسخ- چرا مناظره به جای خودسازگاری؟
- نمونههای حاصل از یک مدل خطاهای مشترکی دارند. مناظره وابستگی آنها را از بین میبرد.
- ایجنتها یا دورها؟
- هر کدام به تنهایی به حالت یکنواخت میرسد. هر دو با هم جهشهای بزرگ ایجاد میکنند.
- چه زمانی مناظره آسیب میزند؟
- در UX حساس به تاخیر، مقیاسهای حساس به هزینه و جستجوهای ساده.
- آیا اجماع یعنی حقیقت؟
- خیر. اجماع میزان حمایت را میسنجد نه حقیقت را.
- پنج گزارش از یک بازبین؟
- میزان حمایت، شناسههای متمایز بازبین را میشمارد نه گزارشها را.
چکلیست انتشار
نکتهها- حداقل از دو مدل پایهی متفاوت در مجموعهی مناظره استفاده کنید.
- تمام دورها را ثبت کنید. دورهای پنهان قابل دیباگ یا حسابرسی نیستند.
- حداقل یک اعتبارسنج قطعی نگه دارید. هرگز پایپلاین تماماً LLM نسازید.
- ابتدا ناقد و سپس اعتبارسنج را اجرا کنید.
- به محض شروع کار کدنویسها، برنامه را فریز کنید. برنامهریزی مجدد یک رخداد مجزاست.
- بازبین نمیتواند تغییرات خودش را تایید کند.