مهندسی Jev برای ایجنت‌های تولیدی

چکیده

Jev یک مدل مکالمه‌ای نیست؛ یک مدل تصمیم‌گیر است. چیزی که به آن می‌دهید یک state ساختاریافته به‌همراه چند پرسش تایپ‌شده است، و چیزی که پس می‌گیرید یک پاسخ محدود همراه با توزیع احتمال است، نه یک پاراگراف. این تفاوت برای ایجنت‌ها خیلی به‌کار می‌آید، چون خیلی از فراخوانی‌های گران‌قیمتی که امروز انجام می‌دهیم اصلاً نیازی به تولید زبان ندارند — فقط یک مسیر، یک امتیاز، یک بله/خیر، یا تصمیم به ارجاع به انسان لازم است. مدل مولد همچنان جای خودش را دارد برای کارهای باز-پاسخ؛ کد قطعی هم همچنان مسئول ناوردا‌های دقیق و اختیارهای بیرونی است.

این هندبوک همین تقسیم کار را به یک رشته‌ی مهندسی واقعی تبدیل می‌کند. واحد اصلی‌اش قرارداد تصمیم است: یک مشخصات نسخه‌دار از state، دستورالعمل‌ها، پیامدهای اعلام‌شده، مسیر fallback، آستانه‌ها، اقدامات مجاز و رفتار ارجاع. با یک قرارداد، یک قضاوت که قبلاً پنهان بود تبدیل می‌شود به منطقی درون کد که می‌شود آن را ارزیابی کرد، ثبت کرد، بازبینی کرد و حتی برگرداند.

رویکرد این سند کاملاً عملیاتی است. سراغ Choice، Score و Noul می‌رود؛ بسته‌های شواهد فشرده؛ مسیریابی آگاه از اطمینان؛ ارزیابی موازی روی یک عکس‌فوری از state؛ منوهای پویا؛ جاهایی که باید Jev را در harness جا داد؛ اجرا در حالت سایه (shadow mode)؛ کالیبراسیون؛ رسیدهای تصمیم؛ و آن حالت‌های شکستی که معمولاً به اشتباه گردن خودِ مدل انداخته می‌شوند. هدف این نیست که هرجا شد از Jev استفاده کنیم؛ هدف این است که فراخوانی‌های مولد را از تصمیم‌هایی که اصلاً به یک جمله نیاز نداشتند، حذف کنیم.

TypeSafe عدد تأخیر انتها-به-انتها را چیزی حدود ۷۰ تا ۵۰۰ میلی‌ثانیه برای پرسش‌های به‌سبک Jev گزارش می‌کند، با قیمتی معادل ۰٫۰۴۲ دلار به‌ازای هر میلیون توکن ورودی (بدون هیچ هزینه‌ای برای توکن خروجی). ادعاهای بزرگ‌تر — ۲۰ تا ۲۰۰ برابر سرعت، ۴۰ تا ۴۰۰ برابر هزینه — از ارزیابی‌های کارگاهی و کمی خوش‌بینانه می‌آیند. بهتر است این اعداد را سقف‌هایی وابسته به بار کاری در نظر بگیرید، نه وعده‌ای که در هر پروژه‌ای تکرار می‌شود. ارزش واقعی معماریِ قضاوت تایپ‌شده هم اصلاً به رسیدن به آن سقف تبلیغاتی گره نخورده.

واژه‌های کلیدی: Jev، TypeSafe AI، مدل system one، قرارداد تصمیم، قضاوت تایپ‌شده، کالیبراسیون، مسیریابی آگاه از اطمینان، harness ایجنت، حالت سایه، وارسی معنایی، Choice، Score، Noul.

I. چرا اصلاً به یک لایه‌ی تصمیم نیاز داریم

الف. فرضی که هزینه‌اش را کسی حساب نمی‌کند

بیشتر پشته‌های ایجنت یک فرض ساده اما پرهزینه دارند: هر قضاوتی، هرقدر هم کوچک، لایق یک فراخوانی دیگر به مدل frontier است. همان حلقه از همان مدل بزرگ برای نوشتن استفاده می‌کند، برای دسته‌بندی، برای انتخاب ابزار، برای برآورد ریسک، برای تصمیم‌گیری درباره‌ی کافی‌بودن شواهد، و حتی برای تشخیص اینکه کِی باید متوقف شود. از بیرون این شبیه یک ایجنت یکپارچه و توانمند به‌نظر می‌رسد؛ اما از داخل، مجموعه‌ای از شاخه‌های تصمیم کوچک است که همه به شکل تولید متن پیاده‌سازی شده‌اند.

مشکل این‌جاست که هزینه‌ی این شاخه‌ها به‌سختی دیده می‌شود، چون در پاسخ نهایی ظاهر نمی‌شود. خودش را به شکل تأخیر متوالی نشان می‌دهد، کانتکست تکراری، تعمیر JSON خراب، و بازیابی بعد از یک شاخه‌ی اشتباه. یک فراخوانی اضافه شاید مهم نباشد؛ اما بیست فراخوانی وابسته به هم، حتی وقتی خروجی نهایی کوتاه است، می‌توانند کل گردش‌کار را کند و گران کنند.

ب. یک پریمیتیو کاملاً متفاوت

Jev پریمیتیو را عوض می‌کند: به‌جای تولید متن، قضاوت معنایی تایپ‌شده می‌دهد. فراخواننده state فعلی و یک یا چند پرسش از پیش تعریف‌شده را می‌فرستد؛ پاسخ هم از همان نوع‌های اعلام‌شده می‌آید، همراه با توزیع احتمال. نرم‌افزار دیگر لازم نیست تصمیم را از میان یک پاراگراف بیرون بکشد یا از لحن جمله حدس بزند که اطمینان چقدر است.

همین محدودیت، نقطه‌قوتش است. Jev پیش‌نویس تحقیق نمی‌نویسد، گزارش تولید نمی‌کند، پچ کد نمی‌سازد. اما خوب می‌تواند تصمیم بگیرد کدام صف باید این ایمیل را بگیرد، آیا گزارش شواهد کافی دارد یا نه، یا آیا این پچ قبل از اجرا نیاز به بازبینی دارد. همین خروجی‌های محدود و ساده هستند که با منطق معمولیِ کد شما ترکیب می‌شوند.

ج. تأخیر، هزینه و یکپارچه‌سازی

TypeSafe، Jev را یک مدل system one معرفی می‌کند که با یادگیری تقویتی برای تصمیم‌های کالیبره‌شده آموزش دیده — یعنی هدفش کیفیت تصمیم همراه با یک عدم‌قطعیت قابل‌استفاده است، نه نثر خوش‌خوان. با اعداد سرویس گزارش‌شده — تأخیر تقریبی ۷۰ تا ۵۰۰ میلی‌ثانیه و ۰٫۰۴۲ دلار به‌ازای هر میلیون توکن ورودی، بدون هزینه‌ی توکن خروجی — شاخه‌بندی معنایی با فرکانس بالا واقعاً قابل‌قبول می‌شود.

اما این اعداد پیچیدگی سیستم را از بین نمی‌برند. یک تصمیم ارزان که کارگر اشتباه را انتخاب کند، می‌تواند کار بیشتری در ادامه‌ی مسیر ایجاد کند تا یک تصمیم گران‌تر ولی درست. یک وارسیِ سریع که کار ناقص را رد نکند، همان‌قدر تأخیر اضافه می‌کند. پس واحدی که باید اندازه بگیرید، وظیفه است، نه هر فراخوانی به‌تنهایی.

د. سه مالک برای سه نوع کار

یک ایجنت تولیدی باید کارها را بین سه مالک متفاوت تقسیم کند. مدل مولد آثار باز-پاسخ می‌سازد. Jev معنای مبهم را وقتی شکل پاسخ از قبل مشخص است تفسیر می‌کند. کد قطعی هم ناوردا‌های دقیق را اعمال می‌کند. اگر همه‌ی این‌ها را در یک فراخوانی مدل بریزید، سه نوع خطای کاملاً متفاوت را در یک مدل مبهم قاطی کرده‌اید.

جدول I. مالکیت هر وظیفه از شکل خروجی‌اش پیروی می‌کند، نه صرفاً از اینکه مدل توانایی انجامش را دارد یا نه.

ه. اختیار همیشه بیرون از مدل می‌ماند

یک امتیاز اطمینان فقط یک سیگنال عملیاتی است، نه یک مجوز. Jev شاید تخمین بزند یک دستور کم‌ریسک است، اما این موتور سیاست شماست که در نهایت تصمیم می‌گیرد اجرایش کند یا نه. این تفاوت جایی مثل انتشار محتوا، خرید، حذف، دسترسی به حساب، تغییر مجوز، حذف دیتابیس یا نمایندگی از طرف کاربر اهمیت حیاتی پیدا می‌کند.

ترتیب امن در همه‌ی یکپارچه‌سازی‌ها یکسان است: اول Jev قضاوت می‌کند، بعد کد سیاست را چک می‌کند، و در نهایت رکوردهای ردیابی اجرا را ثبت می‌کنند. اگر این ترتیب را برعکس کنید، عملاً یک قضاوت احتمالاتی را به اختیار نامحدود رسانده‌اید. آن‌وقت طبقه‌بند خودش تبدیل به سیاست می‌شود و کد اپلیکیشن مجبور است کورکورانه به آن اعتماد کند — طراحی‌ای که ممیزی و کوچک‌کردنش واقعاً سخت است.

و. هدف واقعیِ این مهندسی

هدف این نیست که LLM را کنار بگذاریم. هدف این است که هر جا تولید متن لازم نیست، دیگر از آن استفاده نکنیم. مهندسی Jev در واقع یعنی طراحیِ مرز: کجا زبان واقعاً ارزش می‌آفریند، کجا قضاوت تایپ‌شده ابهام را حل می‌کند، و کجا باید کد باشد که تصمیم آخر را می‌گیرد، نه چیز دیگری.

ز. یک آزمون ساده برای مرز عملیاتی

قبل از اینکه Jev را وارد کار کنید، یک فهرست از تمام شاخه‌های معنایی موجود در ایجنت‌تان تهیه کنید: انتخاب کارگر، انتخاب مدل، ریسک بازیابی، تکمیل، تلاش دوباره، تصعید — هرچه هست. برای هرکدام بنویسید امروز چه چیزی این شاخه را می‌سازد، و آیا آن شاخه معنا را تفسیر می‌کند، عددی را حساب می‌کند، یا صرفاً یک قاعده‌ی دقیق را اجرا می‌کند. این فهرست خودش کلی تصمیم را که تا الان درون پرامپت‌ها پنهان بوده آشکار می‌کند، و جلوی مهاجرت بی‌رویه را هم می‌گیرد. بعضی شاخه‌ها باید همان‌جا در LLM بمانند چون خروجی‌شان مولد است؛ بعضی‌ها باید بروند توی کد چون شرط‌شان دقیق است. فقط شاخه‌های معنایی که باقی می‌مانند، کاندید واقعی Jev‌اند.

یک راه ساده‌تر هم هست: از هر شاخه سه سؤال بپرسید. آیا خودِ خروجی باید نوشته شود؟ اگر بله، مدل مولد. آیا معنا مبهم است در حالی که شکل پاسخ از قبل مشخص است؟ اگر بله، Jev. آیا شرط باید دقیقاً و بدون تفسیر رعایت شود؟ اگر بله، کد. اگر یک شاخه به‌نظر هر سه را با هم می‌خواهد، آن را به گام‌های جدا از تولید، قضاوت و اعمال بشکنید.

II. Choice، Score و Noul

الف. Choice

از Choice وقتی استفاده کنید که دقیقاً یک گزینه از میان چند گزینه‌ی اعلام‌شده باید برنده شود. نکته‌ی مهم در طراحی، برچسب گزینه نیست — توضیحش است. هر معیار باید به مدل بگوید دقیقاً چه شواهدی این پیامد را از همسایه‌هایش جدا می‌کند. برچسب‌هایی مثل research، write یا review برای کد راحت‌اند، اما این توضیح‌ها هستند که آن‌ها را معنادار می‌کنند.

یک منوی بسته، هر جا احتمال دارد واقعیت یک حالتِ فهرست‌نشده داشته باشد، به یک راه‌فرار نیاز دارد. اگر گزینه‌ای مثل none، other، stop یا escalate نگذارید، تمام توده‌ی احتمال روی «کم‌غلط‌ترین» گزینه تحمیل می‌شود. نتیجه از نظر نوع کاملاً معتبر است، اما در عمل اشتباه است. یک پیامد فرار، عدم‌قطعیت را حفظ می‌کند و به harness یک مسیر امن می‌دهد.

Choice برای مسیریابی کارگر، انتخاب مدل، انتخاب کنترل فعلیِ رابط کاربری، انتخاب استراتژی تلاش دوباره، یا تشخیص اینکه کدام کاندید بازیابی باقی بماند خیلی خوب کار می‌کند. اما برای اختراع یک شناسه، URL، عدد یا نامی که در منو اعلام نشده، اصلاً مناسب نیست.

ب. Score

Score جایی به‌کار می‌آید که تصمیم روی یک rubric معنایی و مرتب زندگی می‌کند. سطوحش باید توضیح‌های کلامی باشند، نه اعداد مبهم. برای کیفیت شواهد مثلاً می‌توانید از «بدون پشتیبانی مستقیم» شروع کنید، بروید تا «پشتیبانی جزئی با شکاف» و برسید به «پشتیبانی قوی از منابع مستقل».

خروجی‌ها می‌توانند بین سطوح rubric هم بیفتند، ولی این درون‌یابی یک مقیاس ترتیبی را به اندازه‌گیری دقیق تبدیل نمی‌کند. عدد ۱٫۶ فقط یعنی جایی بین دو توصیف است — نه ۸۰ درصد خوب، نه ۱٫۶ برابر بهتر، و نه چیزی که بین قراردادهای مختلف قابل‌مقایسه باشد.

ج. Noul

Noul یک احتمال بله/خیر برمی‌گرداند. نتیجه‌ی نزدیک به یک یعنی احتمالاً بله؛ نزدیک به صفر یعنی احتمالاً خیر؛ و نزدیک به نیم یعنی شواهدِ موجود کافی نیست که مدل یک طرف را با اطمینان انتخاب کند — نه اینکه شدت موضوع متوسط است، و نه اینکه یک مجوز نصفه‌ونیمه صادر شده. دسته‌بندی‌های ریسکِ مرتب، جای Score هستند، نه Noul.

Noul برای چک تکمیل، احتمال تأیید، کفایت شواهد، یا تشخیص اینکه آیا یک درخواست مبهم است یا یک اقدام پیشنهادی عارضه‌ی جانبی بیرونی دارد، عالی است. اما همچنان این خودِ اپلیکیشن است که باید تصمیم بگیرد کدام بازه‌ی احتمال، اتوماسیون را فعال می‌کند، کدام بازه شواهد بیشتر می‌خواهد، و کدام بازه باید برود سمت بازبینی انسانی.

د. انضباطی که در انتخاب پریمیتیو لازم دارید

جدول II. انتخاب پریمیتیو همیشه از شکل پاسخِ اعلام‌شده شروع می‌شود.

ه. تایپ‌بودن به‌معنای درست‌بودن نیست

Jev می‌تواند تضمین کند که پاسخ دقیقاً با نوع خروجی اعلام‌شده جور در می‌آید. اما نمی‌تواند تضمین کند که همان گزینه‌ی انتخاب‌شده از نظر معنایی هم درست است. شواهد اشتباه، معیارهای قدیمی، یا یک منوی ناقص می‌توانند به‌راحتی یک انتخاب کاملاً معتبر در سطح نوع — اما نادرست — تولید کنند. برای همین سیستم‌های production همیشه به نمونه‌های نماینده، آستانه‌های اطمینان، چک‌های قطعی، رسیدهای تصمیم و مسیرهای بازبینی نیاز دارند. تایپ‌بودن فقط خطاهای parse و schema را حذف می‌کند؛ نیاز به آزمودن معنای واقعی تصمیم هرگز از بین نمی‌رود.

و. وقتی چند پریمیتیو را با هم می‌خواهید

می‌توانید چند پریمیتیو را در یک فراخوانی با هم بپرسید، به شرطی که همه روی همان عکس‌فوری کار کنند. مثلاً یک مسیریاب می‌تواند در یک فراخوانی هم کارگر بعدی را با Choice بپرسد، هم فوریت را با Score، هم احتمال تأیید را با Noul. اما اگر یک پرسش به شواهد تازه‌ای نیاز دارد که پرسش قبلی هنوز نساخته، دیگر نباید آن‌ها را در یک درخواست زنجیر کنید.

ز. ضد-الگوهایی که مراقبشان باشید

یک مسئله‌ی چندبرچسبی را به‌عنوان Choice کدگذاری نکنید، اگر ممکن است چند گزینه هم‌زمان درست باشند. Score را روی دسته‌های بدون ترتیب به‌کار نبرید. و احتمال Noul را به‌جای مقیاس شدت تفسیر نکنید. هرکدام از این ناسازگاری‌ها می‌تواند اعدادی کاملاً معقول تولید کند که اپلیکیشن شما با معنای غلط می‌خواند.

هر وقت خروجی موردنیاز دقیقاً با یک پریمیتیو جور در نمی‌آید، پرسش را بشکنید. برای مثال یک گردش‌کار ریسک می‌تواند از Noul برای تشخیص وجود عارضه‌ی جانبی خارجی استفاده کند، از Score برای رتبه‌دادن پیامد، و از Choice برای انتخاب مسیر مجاز.

III. قرارداد تصمیم، یعنی کد

الف. یک پرسش، خودش بخشی از برنامه است

یک پرسش production در Jev در واقع یک قرارداد تصمیم است. مشخص می‌کند کدام فیلدهای state قابل‌دیدن‌اند، دستورالعمل‌ها دقیقاً چه معنایی دارند، چه پیامدهایی وجود دارند، مسیر راه‌فرار کجاست، اطمینان چطور تفسیر می‌شود، چه اقدامی ممکن است دنبالش بیاید، و کدام نسخه‌ی قرارداد این نتیجه را تولید کرده. اگر با پرسش مثل یک پرامپت گذرا رفتار کنید، بزرگ‌ترین مزیت قضاوت تایپ‌شده را از دست می‌دهید.

شناسه‌های داخلی خودشان دستورالعمل نیستند. یک فیلد به اسم safe_to_publish برای کدِ اپلیکیشن شما مفید است، اما به مدل نمی‌گوید «امن» یعنی چه. تعریف واقعی و عملیاتی باید توی خودِ دستورالعمل‌ها و معیارها نوشته شود؛ وگرنه سیستم یک قاعده‌ی معنایی دارد که توسعه‌دهنده‌ها می‌بینندش، ولی مدل هیچ‌وقت نمی‌بیندش.

ب. یک قرارداد از چه فیلدهایی تشکیل شده

یک قرارداد حداقلی معمولاً شامل schema‌ی state است؛ دستورالعمل‌ها؛ توضیح گزینه‌ها یا rubric؛ آستانه‌های اطمینان؛ کلاس پیامد؛ پیامد fallback؛ مسیر تصعید؛ نسخه‌ی مدل؛ و نسخه‌ی خودِ قرارداد. یک قرارداد خوب را باید بشود بدون خواندن کل اپلیکیشن، فقط با نگاه‌کردن به همان فایل، بازبینی کرد.

فیلد «اقدام مجاز» اهمیت ویژه‌ای دارد. جلوی این را می‌گیرد که نتیجه‌ی یک دسته‌بندی ساده، بی‌سروصدا تبدیل به یک اختیار گسترده شود. یک قرارداد می‌تواند مسیریابی داخلی را مجاز بداند اما هر عارضه‌ی جانبیِ بیرونی را ممنوع کند — و همچنان این harness است که باید تأیید کند اقدام نهایی داخل همان مرز باقی مانده.

ج. نسخه‌بندی قرارداد

گزینه‌ها عوض می‌شوند، ابزارها عوض می‌شوند، کاربران و حتی زبان هم تغییر می‌کنند. یک ویرایش معنایی می‌تواند رفتار production را عوض کند، حتی بدون اینکه یک خط کد اپلیکیشن تغییر کرده باشد. پس قرارداد تصمیم را جدا از کد نسخه‌بندی کنید تا این تغییرات را بشود بازبینی کرد، ارزیابی کرد، به‌تدریج دیپلوی کرد، و در صورت نیاز روی نمونه‌های تاریخی برگرداند.

د. رسید تصمیم

هر تصمیمی که روی production می‌رود باید یک رسید تولید کند. رسید همان چیزی است که قضاوت را به state و سیاستی که در آن لحظه وجود داشته وصل می‌کند — و بدون آن، ممیزی، کالیبراسیون، بازبینی حادثه یا مقایسه‌ی بین نسخه‌های قرارداد عملاً غیرممکن است.

جدول III. یک برچسب بدون رسید، ارزیابی و ممیزی را عملاً غیرممکن می‌کند.

ه. چهار مرحله‌ی چرخه‌ی عمر قرارداد

چرخه‌ی عمر یک قرارداد چهار مرحله دارد. اول state و پیامدها را تعریف می‌کنید. دوم قرارداد را روی یک عکس‌فوری ثابت ارزیابی می‌کنید. سوم نتیجه را از میان یک سیاست قطعیِ آگاه از پیامد مسیریابی می‌کنید. چهارم رسید را ثبت می‌کنید و اقدام نهایی را اجرا می‌کنید. هیچ‌کدام از این مراحل نباید توی مرحله‌ی دیگر پنهان بماند.

جداکردن ارزیابی از مسیریابی این امکان را می‌دهد که یک توزیع احتمال یکسان، چند سیاست متفاوت را پشتیبانی کند. مثلاً یک بیانیه‌ی عمومی شاید در آستانه‌ای پایین‌تر از یک مسیریابی داخلی، خودکار شود. یک اقدام برگشت‌ناپذیر هم شاید در هر سطح اطمینانی همچنان نیاز به بازبینی داشته باشد. نکته این است که قضاوت معنایی قابل‌استفاده‌ی مجدد است، ولی سیاست همیشه به زمینه‌ی خودش تعلق دارد.

و. چطور یک قرارداد را آزمایش کنیم

آزمون‌های قرارداد باید موارد عادی را پوشش بدهند، موارد مبهم را، شواهد ناقص را، زبان خصمانه را، و گزینه‌های قدیمی‌ای که دیگر هیچ‌کدام مناسب نیستند. آزمون‌ها باید هم پاسخ انتخاب‌شده را بسنجند و هم اینکه آیا اطمینان به‌طور منطقی با کیفیت شواهد بالا و پایین می‌رود. اگر یک قرارداد فقط روی موارد آسان دقیق است، هنوز آماده‌ی کنترل یک شاخه‌ی واقعی نیست.

ز. رسیدها وقتی که یک حادثه پیش می‌آید

در جریان یک حادثه، رسید باید بتواند جواب بدهد: مدل چه چیزی دید، قرارداد چطور تفسیرش کرد، احتمال چطور توزیع شد، کدام آستانه فعال شد، کدام سیاست قطعی اجرا شد، و در نهایت چه اقدامی انجام گرفت. بدون این پیوندها، تیم‌ها شکست را می‌بینند اما نمی‌توانند بگویند دقیقاً کجای مرز خراب شده.

رسیدها یک فایده‌ی دیگر هم دارند: ارزیابی ضدواقعی را ممکن می‌کنند. یک نسخه‌ی جدید از قرارداد می‌تواند روی عکس‌فوری‌های قدیمیِ state دوباره اجرا شود، بدون اینکه عوارض جانبی واقعی‌اش تکرار شوند. این مقایسه دقیقاً همان‌جایی لازم می‌شود که هدف‌تان مسیریابیِ امن‌تر است، نه فقط برچسب‌های متفاوت.

IV. بسته‌های state و شواهد

الف. مهندسیِ خودِ state

Jev فقط می‌تواند stateای را که به آن داده‌اید قضاوت کند. اگر یک transcript غول‌پیکر بفرستید، مدل مجبور می‌شود کل گردش‌کار، دستورالعمل‌های مختلط، تلاش‌های قدیمی، نتیجه‌گیری‌های قبلی و تاریخچه‌ی نامرتبط را از نو بازسازی کند. خروجی ممکن است ظاهراً با نوع اعلام‌شده جور در بیاید، در حالی که قضاوت زیرینش روی کانتکستی کهنه یا حتی گمراه‌کننده ساخته شده.

یک بسته‌ی state خوب باید فشرده، به‌روز و مبتنی بر شواهد باشد. هدف، حقایق، مصنوعات، شواهد، محدودیت‌ها، گزینه‌ها و نسخه را از هم جدا نگه دارید — هرکدام نقش خودش را دارد. این جداسازی حذفیات را قابل‌مشاهده می‌کند و جلوی این را می‌گیرد که تفسیر یک ایجنت قبلی، بی‌سروصدا تبدیل به یک حقیقت غیرقابل‌سؤال شود.

جدول IV. فیلدهای عملکردی در state، اتصال تصادفی بین شواهد و تفسیر را کم می‌کنند.

ب. شواهد بفرستید، نه نتیجه‌گیری آماده

state باید شواهد قابل‌مشاهده را نگه دارد، نه یک نتیجه‌گیری از پیش‌جویده. جمله‌ای مثل «تحقیق احتمالاً کافی است» به Jev می‌گوید صرفاً به یک قضاوت قبلی اعتماد کند. اما چیزی مثل «هفت منبع جمع‌آوری‌شده، سه‌تا رسمی، قیمت تأییدشده، ادعای امنیتی هنوز حل‌نشده» ماده‌ی خامی می‌دهد که مدل واقعاً بتواند رویش قضاوت تازه‌ای بسازد.

ج. کنترل دسترسی روی state

یک بسته‌ی state فشرده باید اصل کمترین امتیاز را هم رعایت کند. مدل تصمیم‌گیر فقط باید همان فیلدهایی را ببیند که قرارداد واقعاً لازم دارد. اسرار، اطلاعات شخصی، کد اختصاصی، یا داده‌ی حساب نامرتبط نباید صرفاً به این دلیل که در کانتکست ایجنت والد وجود دارند، سرریز کنند به state.

قوانین دسترسی سطح-فیلد این مرز را قابل‌بازبینی می‌کنند. یک فایده‌ی دیگرشان این است که اجازه می‌دهند همان state زیرین، پروجکشن‌های متفاوتی برای مسیریابی، بازیابی، وارسی و تأیید بسازد.

د. تازگی و باطل‌شدن

هر مجموعه‌گزینه‌ای یک شرط باطل‌سازی دارد. کارگرها آفلاین می‌شوند، دکمه‌ها ناپدید می‌شوند، بودجه‌ها کم می‌شوند، فایل‌ها جابه‌جا می‌شوند، مجوزها لغو می‌شوند، منابع به‌روز می‌شوند. تصمیم‌گیری روی state کهنه فقط یک استنتاج ضعیف نیست — استنتاج روی یک گراف اساساً نامعتبر است.

یک timestamp یا نسخه به هر شاهدی که ممکن است کهنه شود بچسبانید. درست قبل از ارزیابی، گزینه‌های زنده را دوباره بسازید، و مراقب باشید بین ساخت عکس‌فوری و ارزیابیِ نهایی چیزی ننویسید که سازگاری را بهم بزند. اگر سیستم دوباره تلاش می‌کند، باید یا شواهد جدید بیاورد یا قرارداد را عوض کند؛ تکرار همان پرسش نامطمئن روی همان state چیزی یاد نمی‌گیرد.

ه. کوچک‌کردن state، نه خالی‌کردنش

کوچک‌سازی به‌معنای حذف تهاجمی نیست؛ یعنی اعلام صریح ربط. کد می‌تواند مطابقت‌های دقیق را از قبل فیلتر کند، شواهد محتمل را بازیابی کند، و یک بسته‌ی کوچک بسازد؛ آن‌وقت Jev فقط ابهام معنایی باقی‌مانده را حل می‌کند. این جداسازی جلوی این را می‌گیرد که مدل مجبور شود حقایقی را که برنامه از قبل می‌دانسته دوباره کشف کند.

بسته باید طوری باشد که یک انسان هم بتواند نگاهش کند و بفهمد. اگر توسعه‌دهنده‌ها نتوانند توضیح دهند چرا یک فیلد آن‌جاست، احتمالاً state دارد تاریخچه‌ی یک transcript را حمل می‌کند، نه اطلاعات واقعیِ تصمیم را.

و. آزمودن بسته‌های state

آزمون‌های state باید فیلدها را یکی‌یکی حذف کنند، خراب کنند، یا کهنه کنند تا مشخص شود کدام شاهد واقعاً شاخه را هدایت می‌کند. اگر تاریخچه‌ی نامرتبط پاسخ را عوض می‌کند، یعنی بسته به‌اندازه‌ی کافی ایزوله نیست. اگر حذف یک فیلدِ ظاهراً ضروری هیچ اثری ندارد، یا آن فیلد اصلاً لازم نبوده، یا قرارداد به‌طور قابل‌اعتماد ازش استفاده نمی‌کند.

برای نسخه‌های رایج state و موارد مرزی، fixture نگه دارید. هر fixture باید مسیر مورد انتظار و یک توجیه انسانیِ کوتاه داشته باشد — نه یک ردِ کامل chain-of-thought. هدف این است که مرز تصمیم و کفایت شواهد را وارسی کنید.

V. اطمینان، پیامد و کالیبراسیون

الف. اطمینان یک سیگنال مسیریابی است، نه یک برچسب

خیلی از سیستم‌ها زودتر از موقع، احتمال را به یک برچسب مسطح تبدیل می‌کنند. نتیجه‌ی ۰٫۵۱ و نتیجه‌ی ۰٫۹۹ هر دو ممکن است «بله» شوند، در حالی که واقعاً نباید همان سطح از اختیار را بگیرند. این توزیع است که باید تعیین کند harness در قدم بعد چه‌کار می‌کند.

یک سیاست خوب سه منطقه‌ی عملیاتی دارد. اطمینان بالا همراه با پیامد پایین، می‌تواند شاخه‌ی اعلام‌شده را خودکار کند. اطمینان متوسط باید state را بهبود بدهد — یعنی شواهد بیشتری جمع کند، یک چک قطعی اجرا کند، گزینه‌ها را محدود کند، یا سراغ یک مدل قوی‌تر برود. و اطمینان پایین یا پیامد بالا، باید همیشه تصعید کند.

جدول V. این آستانه‌ها فقط نمونه‌اند؛ باید برای هر کلاس اقدام جداگانه کالیبره شوند.

یک نکته‌ی مهم: همان سطح اطمینان نباید هم یک صف داخلی را کنترل کند و هم یک بیانیه‌ی عمومی. آستانه به کلاس پیامد تعلق دارد، نه فقط به نوع خروجی. اقدامات برگشت‌ناپذیر هم، فارغ از هر عددی برای اطمینان، باید همیشه زیر نظر انسان بمانند.

ب. وقتی اطمینان متوسط است، state را بهبود بدهید

یک مسیرِ اطمینان-متوسط باید دقیقاً مشخص کند state چطور قرار است بهتر شود. یک منبع دیگر بگیرید، یک فایل را وارسی کنید، یک چک مجوز اجرا کنید، از کاربر یک سؤال دقیق‌تر بپرسید، یا مجموعه‌ی گزینه‌ها را کوچک‌تر کنید. اگر اطمینان به یک اقدام بعدیِ واقعاً متفاوت منجر نشود، فقط تزئین است.

یک نکته‌ی ظریف: ارزیابی مکرر با همان شواهد بدون تغییر می‌تواند اطمینان کاذب بسازد، چون چند خروجی مشابه شبیه اجماع به‌نظر می‌رسند. بودجه‌ای که برای تلاش دوباره می‌گذارید باید واقعاً اطلاعات تازه بخرد، نه فقط یک نمونه‌ی دیگر از همان عدم‌قطعیت قبلی.

ج. حاکمیت روی آستانه‌ها

آستانه‌ها بخشی از پیکربندی production‌اند. مالک، منطق، پنجره‌ی ارزیابی، کلاس پیامد و شرط بازگردانی هرکدام را ثبت کنید. آستانه‌ای که از یک مجموعه‌ی دمویی کوچک درآمده، هرگز نباید بی‌سروصدا تبدیل به سیاست دائمی شود.

ترافیکی که نزدیک هر آستانه جمع می‌شود را رصد کنید. اگر توده‌ی زیادی درست بالای مرز اتوماسیون جمع شده، سیستم به کوچک‌ترین لغزش در کالیبراسیون حساس می‌شود. در چنین حالتی، قبل از افزایش خودمختاری، یا قرارداد را بهتر کنید یا منطقه‌ی بازبینی را گسترش بدهید.

د. کالیبراسیون یعنی چه

کالیبراسیون این سؤال را می‌پرسد: آیا رویدادهایی که با یک احتمال مشخص پیش‌بینی شده‌اند، واقعاً با همان فرکانس روی بار کاری هدف رخ می‌دهند؟ یک نمودار قابلیت‌اطمینان، تصمیم‌ها را در سطل‌های اطمینان گروه‌بندی می‌کند و اطمینان پیش‌بینی‌شده را با درستیِ واقعی مقایسه می‌کند. کالیبراسیون کامل دقیقاً روی قطر می‌نشیند؛ منحنی زیر آن یعنی مدل بیش‌ازحد مطمئن است، و منحنی بالای آن یعنی کمتر از حد مطمئن. اتوماسیون به این بستگی دارد که آیا اطمینان بالاتر واقعاً موارد امن‌تر را نشان می‌دهد یا نه.

ه. چطور کالیبراسیون را اندازه بگیریم

برای تصمیم‌های دودوییِ Noul، امتیاز Brier خطای مجذور بین احتمال و پیامد واقعی را اندازه می‌گیرد. برای Choice، کالیبراسیون top-label یا کالیبراسیون classwise می‌تواند نشان بدهد کدام گزینه‌ی نادر به‌طور سیستماتیک بیش یا کمتر از حد مطمئن ارزیابی می‌شود. معیارها را بر اساس نسخه‌ی قرارداد، کلاس پیامد، زبان و مورد نادر تفکیک کنید — یک میانگین سراسری می‌تواند دقیقاً همان شاخه‌ای که مهم است را پنهان کند.

و. اطمینان، اختیار نمی‌دهد

حتی یک توزیع کاملاً کالیبره‌شده هم بازهم یک پیش‌بینی است، نه یک مجوز. سیاست، بودجه، لیست‌های مجاز، تأیید کاربر و چک‌های قطعیِ پایین‌دست همچنان سر جای خودشان می‌مانند. کالیبراسیون کاری که می‌کند این است که اتوماسیون را قابل‌اندازه‌گیری می‌کند؛ اما هیچ‌وقت اختیار را به مدل منتقل نمی‌کند.

ز. دیپلوی‌کردن کالیبراسیون

کالیبراسیون باید اول در حالت سایه تخمین زده شود، بعد از اتوماسیون دوباره چک شود، و هر وقت قرارداد یا schema‌ی state تغییر مهمی کرد، دوباره محاسبه شود. کالیبراسیون کاملاً وابسته به بار کاری است؛ همان قرارداد را که ببرید سراغ یک زبان تازه، یک حوزه‌ی محصول جدید یا جمعیت کاربری دیگر، منحنی قبلی را باطل می‌کند.

برچسب انسانی را گزینشی اما پیوسته جمع کنید. روی موارد نادر، پرپیامد و نزدیک-به-آستانه بیشتر تمرکز کنید. نمونه‌گیری کاملاً تصادفی ممکن است یک تجمیع اطمینان‌بخش بسازد در حالی که دقیقاً همان مرز اتوماسیونی که برایتان مهم است، هنوز به‌خوبی اندازه‌گیری نشده.

VI. پرسش‌های موازی و مرزهای state

الف. یک عکس‌فوری، چند پرسش با هم

Jev می‌تواند چند پرسش تایپ‌شده را در یک درخواست، روی همان state، ارزیابی کند. مثلاً یک مسیریاب می‌تواند کارگر بعدی را با Choice بپرسد، فوریت را با Score، و احتمال تأیید را با Noul — همه در یک فراخوانی. چون هر سه دقیقاً روی یک عکس‌فوری کار می‌کنند، رکورد تصمیم منسجم باقی می‌ماند و بازرسی‌اش خیلی ساده‌تر از دنبال‌کردن یک زنجیره از فراخوانی‌های مولد مستقل است.

این دسته‌ای‌کردن، هم انتقال تکراری state را کم می‌کند و هم جلوی آن اختلاف زمانیِ ناخواسته را می‌گیرد که وقتی شواهد بین دو پرسش عوض می‌شود پیش می‌آید. یک فایده‌ی جانبی هم دارد: زود آشکار می‌کند دو قرارداد دارند روی برداشت‌های ناسازگار از state کار می‌کنند یا نه.

ب. مرز استقلال را جدی بگیرید

موازی‌بودن به‌معنای مستقل‌بودن نیست. یک پرسش نمی‌تواند پاسخ تازه‌ی پرسش دیگر را همان لحظه، توی همان ارزیابی، مصرف کند. اگر تصمیم دوم به نتیجه‌ی یک جست‌وجو، خروجی یک ابزار، یا شفاف‌سازیِ کاربر نیاز دارد، اول همان کار را انجام دهید، نسخه‌ی state را به‌روز کنید، و بعد دوباره بپرسید.

مرز خیلی ساده است: شواهد یکسان می‌تواند چند پرسش را تغذیه کند؛ اما شواهد تازه همیشه به یک عکس‌فوری تازه نیاز دارد. اگر یک طرح چندمرحله‌ای را داخل یک برچسب پنهان کنید، وابستگی‌های واقعی را جمع کرده‌اید و دیگر نمی‌شود فهمید کدام شاهد واقعاً پشت پاسخ نهایی بوده.

ج. انضباطی که عکس‌فوری‌ها لازم دارند

هر دسته باید یک نسخه‌ی state یا یک hash محتوا با خودش حمل کند. زمان اجرا باید جلوی نوشته‌های هم‌زمان بین ساخت عکس‌فوری و ارزیابی را بگیرد، یا حداقل آن مسابقه را ثبت کند. رسید تصمیم هم باید مشخص کند هر پرسش دقیقاً اجازه‌ی دیدن کدام شواهد را داشته.

دسته‌ای‌کردن فقط یک بهینه‌سازی نیست؛ یک مرز تراکنشیِ معنایی می‌سازد. همه‌ی پاسخ‌ها یک نسخه از واقعیت را توصیف می‌کنند، و هر تغییری که بعداً واقعیت را عوض کند، خودش یک عکس‌فوری جدید می‌سازد.

د. یک رکورد تصمیم نمونه

این رکورد کل توزیع را نگه می‌دارد، نه فقط برنده را. یک ممیزی بعدی می‌تواند بررسی کند آستانه‌ی انتخاب‌شده معقول بوده یا نه، آیا یک گزینه‌ی نادر نادیده گرفته شده، و آیا اطمینان بعد از رسیدن شواهد تازه واقعاً تغییر کرده یا نه.

ه. وقتی پرسش‌ها واقعاً به هم وابسته‌اند

هر فلشی که شواهد تازه می‌سازد باید در ردیابی قابل‌مشاهده باشد. اگر نباشد، ایجنت ظاهراً استدلالی پیوسته دارد، در حالی که گراف واقعی‌اش پر از انتقال‌های state پنهان و ثبت‌نشده است.

و. هم‌زمانی و عوارض جانبی

پرسش‌های مستقل و فقط-خواندنی، کاندیدهای طبیعی برای ارزیابی موازی‌اند. اما شاخه‌هایی که چیزی می‌نویسند، به کنترل خیلی دقیق‌تری نیاز دارند. دو تصمیم می‌توانند از نظر معنایی کاملاً مستقل باشند، اما نتایج‌شان روی همان فایل، همان صف، همان بودجه یا همان حساب بیرونی رقابت کنند.

harness باید موازی‌سازیِ تصمیم را از موازی‌سازیِ اجرا جدا نگه دارد. می‌تواند مسیرها را با هم ارزیابی کند، اما بعد بر اساس سیاست قطعی، منابع را ترتیب‌دهی یا قفل کند. یک مدل تصمیم‌گیرِ سریع، دغدغه‌های همیشگیِ سیستم‌های توزیع‌شده را از بین نمی‌برد.

ز. حالت‌های شکستی که این‌جا زیاد پیش می‌آیند

شکست‌های رایج شامل این‌ها می‌شوند: دسته‌کردن پرسش‌هایی که واقعاً به هم وابسته‌اند، مخلوط‌کردن نسخه‌های مختلف state در یک رکورد، ارزیابی بعد از نوشتن بدون بازسازی شواهد، و ثبت فقط پاسخ نهایی به‌جای کل رسید. هرکدام از این‌ها مسیر ممیزی را ضعیف می‌کند، حتی وقتی خودِ شاخه‌ی بلافصل درست به‌نظر می‌رسد.

ح. بازسازی کامل مسیر

یک ردیابی کامل به بازرس اجازه می‌دهد کل تراکنش معنایی را بازپخش کند: عکس‌فوری state را بارگذاری کند، نسخه‌ی قرارداد را برگرداند، گزینه‌های اعلام‌شده را از نو بسازد، توزیع‌ها را ببیند، پیکربندی آستانه را اعمال کند، و مسیر نتیجه را با اقدامی که واقعاً اجرا شده مقایسه کند.

اگر حتی یک حلقه از این زنجیره قابل‌بازسازی نباشد، آن تصمیم فقط نیمه‌قابل‌مشاهده است. این شکاف را باید یک نقص عملیاتی جدی حساب کرد، حتی اگر هیچ خطای قابل‌مشاهده‌ای برای کاربر رخ نداده باشد.

VII. جایگاه Jev در harness

الف. پیش از خودِ مدل مولد

اولین جایی که می‌توانید Jev را بگذارید، مسیریابیِ وظیفه است. یک مدل مولد وقتی سیستم فقط باید تصمیم بگیرد یک درخواست ساده است یا مبهم، معمولی است یا پرریسک، یا اصلاً خارج از توانایی موجود است، اضافی است. Jev می‌تواند از میان مدل‌ها یا کارگرهای فعلی انتخاب کند، در حالی که کد کاندیدهایی که در دسترس نیستند، بودجه‌شان تمام شده یا سیاست منعشان کرده را حذف می‌کند.

مسیریاب باید همیشه یک منوی زنده از مدل‌ها، بودجه‌های به‌روز هزینه/تأخیر، محدودیت‌های وظیفه، و کلاس پیامد را ببیند — نه یک گراف پرامپت ثابت با اسم مدلی که دیروز فعال بوده. مسیریابی روی یک منوی کهنه، صرفاً یک استنتاج ضعیف نیست؛ ارزیابی روی یک گراف اساساً نامعتبر است.

ب. پیش از اجرای هر ابزار

دومین نقطه، دسته‌بندی ریسک معنایی است. LLM یک فراخوانی ابزار پیشنهاد می‌دهد؛ Jev معنای همان اقدام پیشنهادی را در برابر یک rubric اعلام‌شده می‌سنجد؛ و بعد کد، مجوزهای دقیق، دامنه، بودجه، مقصد و تأیید کاربر را پیش از اینکه چیزی واقعاً اجرا شود چک می‌کند.

این جداسازی جلوی این را می‌گیرد که طبقه‌بند خودش تبدیل به موتور سیاست شود. یک پیش‌بینیِ کم‌ریسک هرگز نباید بتواند یک لیست مجاز، مرز یک مخزن، مجوز یک حساب یا شرط تأیید انسانی را دور بزند.

ج. بعد از اینکه ابزار اجرا شد

سومین نقطه، وارسی است. یک پاسخ HTTP موفق یا یک کد خروج صفر فقط ثابت می‌کند عملیات تمام شده، نه اینکه هدف واقعی حاصل شده. وارسی باید شواهد تازه را بررسی کند: آیا مصنوع مدنظر واقعاً وجود دارد، بخش‌های لازمش حاضرند، ادعاها استناد دارند، مسیر خروجی درست است، و هیچ تأیید موردنیازی معلق نمانده.

د. سازنده و وارسی‌کننده، هردو یک rubric لازم دارند

سازنده و وارسی‌کننده باید یک مصنوع و یک rubric مشترک داشته باشند، نه فقط یک حس مبهم از «تمام‌شدن». سازنده می‌تواند مدل مولد باشد؛ وارسی‌کننده هم می‌تواند چک‌های قطعی را کنار امتیاز یا انتخاب Jev بگذارد. اگر یک چک شکست خورد، باید برود سمت تعمیر، جمع‌آوری شواهد یا مسیریابیِ تصعید — نه اینکه فقط دوباره همان کار را تکرار کند.

ه. اطراف بازیابی

embeddingها شباهت موضوعی را خوب پیدا می‌کنند، اما همیشه چیزی که واقعاً برای تصمیم مرتبط است را پیدا نمی‌کنند. یک پشته‌ی بازیابیِ خوب معمولاً با فیلترهای قطعیِ ارزان شروع می‌شود، با embedding یک فهرست کوتاه می‌سازد، از Jev می‌خواهد ربطِ هر مورد را نسبت به پرسش فعلی امتیاز بدهد، و در نهایت یک بسته‌ی شواهد کوچک برای مدل مولد می‌سازد.

این pipeline دقت اسناد را حفظ می‌کند و ابهام معنایی را برای Jev نگه می‌دارد. ردیابی می‌تواند دقیقاً توضیح دهد چرا هر مورد باقی مانده، مدل مولد نویز کمتری می‌بیند، و تصمیمِ بازیابی هم مستقل از مصنوع تولیدشده قابل‌آزمون می‌شود.

جدول VI. Jev درست در گذارهای معنایی می‌نشیند؛ اختیار نهایی همیشه با کد باقی می‌ماند.

و. کجا واقعاً ارزش دارد Jev بگذارید

فقط چون Jev ارزان است، آن را در هر گوشه‌ای نگذارید. با تصمیم‌های معنایی تکراری و کم‌پیامد شروع کنید، جایی که خطاهایش هم قابل‌اندازه‌گیری باشد. یک گره‌ی تصمیم خوب باید یا یک فراخوانی مولد را حذف کند، یا یک مرز سیاست را روشن‌تر کند، یا قابلیت‌مشاهده را بهتر کند، یا مسیری بسازد که قبلاً اصلاً وجود نداشته.

اگر یک گره فقط یک شرط دقیق را که کد از قبل می‌دانست دوباره تکرار می‌کند، فقط عدم‌قطعیت اضافه کرده بدون اینکه چیزی هوشمندتر شده باشد. و اگر یک گره محتوای باز-پاسخ تولید می‌کند، دارد خارج از نقش خودش کار می‌کند. کیفیت گراف مهم‌تر از تعداد فراخوانی‌های Jev است.

ز. مسیریابی که به امنیت هم فکر می‌کند

مسیریابی مدل باید علاوه بر کیفیت، هزینه و تأخیر، اعتماد را هم در نظر بگیرد. بسته‌ی state می‌تواند مشخص کند یک شاخه مجاز است کدام دسته از داده را ببیند. کد هم، قبل از اینکه Jev از میان گزینه‌های باقی‌مانده انتخاب کند، ارائه‌دهنده‌هایی که برای اسرار، زیرساخت، تحقیق اختصاصی یا داده‌ی شخصی صلاحیت ندارند را حذف می‌کند.

این کار مرز سیستم را دست‌نخورده نگه می‌دارد: Jev می‌تواند بهترین تناسب معنایی را درون مجموعه‌ی مجاز پیدا کند، ولی این سیاست قطعی است که از اول تعیین می‌کند چه چیزی اصلاً اجازه‌ی وجود دارد.

VIII. منوهای زنده و بازیابی

الف. یک منو، خودش یک تکه از state زمان اجراست

اقداماتی که در یک ایجنت در دسترس‌اند، دائم عوض می‌شوند. کنترل‌های مرورگر بعد از هر کلیک ظاهر و ناپدید می‌شوند. کارگرها آنلاین و آفلاین می‌شوند. فایل‌ها ساخته یا جابه‌جا می‌شوند. بودجه‌ها کوچک می‌شوند. مجوزها تغییر می‌کنند. صف‌ها پر می‌شوند. یک مدل تصمیم فقط باید از میان چیزهایی انتخاب کند که همین الان واقعاً وجود دارند.

مجموعه‌ی گزینه‌ها باید درست قبل از ارزیابی، از state زنده استخراج شود. یک منویی که ابتدای اجرا نوشته شده، دیگر بازنمایی قابل‌اعتمادی از برنامه نیست. اگر گزینه‌ی انتخاب‌شده دیگر وجود نداشته باشد، الزاماً مدل بد استنتاج نکرده — این harness بوده که یک گراف نامعتبر را برای ارزیابی فرستاده.

ب. وقتی مجموعه‌ی گزینه خیلی بزرگ است

منوهای بزرگ باید قبل از هر انتخاب معنایی کوچک شوند. کد قطعی می‌تواند کاندیدهای غیرممکن را حذف کند؛ بازیابی یا embedding یک فهرست کوتاه بسازد؛ و بعد Jev فقط ابهام باقی‌مانده را حل کند. این توالی خیلی پایدارتر از این است که از Jev بخواهید صدها گزینه‌ای که برنامه می‌توانست خودش حذف کند را مرور کند.

فرایند فهرست‌کوتاه‌کردن باید همیشه یک راه‌فرار داشته باشد. پیش‌فیلترِ خیلی تهاجمی می‌تواند گزینه‌ی درست را حتی قبل از اینکه Jev ببیندش حذف کند. هم تعداد کاندید اولیه و هم تعداد بازماندگان را ثبت کنید، تا اگر شکستی پیش آمد بتوانید بگویید مال فیلترکردن بوده، مال بازیابی، یا مال خودِ انتخاب معنایی.

ج. مسیریابیِ پویا برای کارگرها

منوی کارگرها باید در دسترس‌بودن، توانایی، هزینه، تأخیر، سیاست اعتماد و بار فعلی را در نظر بگیرد. توضیح معنایی می‌گوید هر کارگر کِی مناسب است؛ فیلدهای قطعی هم کارگرهایی که قانوناً یا عملیاتاً نمی‌توانند این وظیفه را بگیرند را حذف می‌کنند.

د. آزمودن خودِ منوساز

منوساز را جدا از انتخاب معنایی آزمایش کنید. fixtureها باید کارگرهای غیردردسترس، کنترل‌های غیرفعال، منابع منقضی، بودجه‌های تمام‌شده و تغییرات مجوز را پوشش بدهند. نتیجه‌ی مورد انتظار می‌تواند یک منوی کوچک‌تر باشد، یا حتی فقط یک پیامد stop یا review.

یک Choice درست، هیچ‌وقت نمی‌تواند گزینه‌ای را که یک منوساز معیوب حذفش کرده برگرداند. جداکردن این آزمون‌ها جلوی این را می‌گیرد که نقص‌های ساخت منو، به گردن Jev بیفتد.

ه. بازیابی، یک تصمیم پشتیبانی‌شده است

یک مورد بازیابی باید به این دلیل باقی بماند که به یک پرسش اعلام‌شده شواهد می‌دهد — نه صرفاً چون از نظر موضوعی نزدیک به نظر می‌رسد. قرارداد ربط باید بگوید آیا منبع مستقیماً از یک ادعا پشتیبانی می‌کند، آیا برای این پیامد به‌اندازه‌ی کافی معتبر است، و آیا برای این تصمیم به‌اندازه‌ی کافی تازه است.

بسته‌ای که به مدل مولد می‌فرستید باید شناسه‌ی منبع و رابطه‌ی پشتیبانی را هم ثبت کند. با این ساختار، وارسی‌کننده می‌تواند بپرسد آیا هر ادعای مهم واقعاً شاهد دارد، و آیا نوع آن شاهد با قرارداد جور در می‌آید.

و. توضیح گزینه‌ها را جدی بگیرید

توضیح‌ها باید گزینه‌ها را از هم متمایز کنند، نه فقط اسم‌شان را عوض کنند. دو کارگر که فقط با «سریع» و «توانمند» توصیف شده‌اند، یک منوی کم‌مشخصه ساخته‌اند. معیارها باید بگویند تحت چه شرایطی از شواهد، هر کارگر انتخاب درستی است؛ و هرجا همپوشانی دارند، یک پیامد review یا none اضافه کنید.

ز. توقف هم یک اقدام است

منوهای پویا معمولاً باید stop را هم داشته باشند. بدون آن، ایجنت مجبور می‌ماند به کارش ادامه بدهد، حتی وقتی هدف قبلاً کامل شده یا هیچ اقدام امنی وجود ندارد. توقف یک شکست نیست؛ یک پیامد اعلام‌شده با معیارهای مشخص است که هم قابل‌ارزیابی است و هم قابل‌ممیزی.

در ایجنت‌های مرورگر و ابزار، یک مسیر توقف امن اغلب از هر شاخه‌ی بازیابیِ دیگری مهم‌تر است. جلوی این را می‌گیرد که حلقه فقط به این دلیل که یک منوی اقدام نمی‌تواند «تکمیل» را نمایش بدهد، توکن مصرف کند یا عارضه‌ی جانبی بسازد.

ح. کش‌کردن state پویا

کش‌کردن وقتی ساخت گزینه‌ها گران است می‌تواند کمک کند، اما هر ورودی کش باید یک قانون باطل‌سازی صریح داشته باشد. انقضای مبتنی بر زمان به‌تنهایی برای کنترل‌ها، بودجه‌ها و منوهای زنده کافی نیست. هرجا سیستم زیرین یک سیگنال تغییر قابل‌اعتماد می‌دهد، باطل‌سازیِ رویداد-محور را ترجیح بدهید.

رسید تصمیم باید نسخه‌ی مجموعه‌گزینه را هم ثبت کند. وقتی یک حادثه به یک انتخاب کهنه برمی‌گردد، تیم می‌تواند بگوید مشکل از خطای استنتاج بوده یا از خطای باطل‌سازی.

IX. ارزیابی و راه‌اندازی روی production

الف. با یک تصمیم شروع کنید، نه با همه

همه‌ی شاخه‌های پنهان را یک‌جا جایگزین نکنید. یک تصمیم معنایی با حجم بالا و پیامد پایین انتخاب کنید که بعداً بشود پاسخ درستش را برچسب زد. مسیریابی تیکت داخلی، انتخاب کارگر، فیلتر بازیابی و چک‌های تکمیل، نقطه‌های شروع خوبی‌اند. تأیید پرداخت بدون بازبینی انسانی، جزو این دسته نیست.

ب. قرارداد را قبل از یکپارچه‌سازی بنویسید

قرارداد را قبل از هر فراخوانی به مدل بنویسید: فیلدهای state، دستورالعمل‌ها، گزینه‌ها یا rubric، fallback، آستانه‌های اطمینان، کلاس پیامد، مسیر تصعید و نسخه. اگر تیم روی همین فیلدها هنوز به توافق نرسیده، آن شاخه هنوز آماده‌ی اتوماسیون نیست.

ج. یک مجموعه‌ی ارزیابی واقعاً نماینده بسازید

مجموعه‌ی ارزیابی باید موارد عادی را داشته باشد، موارد مبهم را، شواهد ناقص را، زبان خصمانه را، گزینه‌های قدیمی را، و مواردی که هیچ‌کدام از گزینه‌ها مناسب نیست. نمونه‌هایی از توزیع واقعی بگذارید و چند ضدمثال سخت هم عمداً اضافه کنید. یک مجموعه‌ی دمویی صیقلی هیچ‌وقت نمی‌تواند نشان بدهد اطمینان واقعاً مفید است یا نه.

د. اول در حالت سایه اجرا کنید

در حالت سایه، مسیر production فعلی همچنان همان‌طور که هست کار می‌کند. Jev همان تصمیم را ارزیابی می‌کند، ولی هیچ اقدامی انجام نمی‌دهد. سیستم فقط توزیع، پاسخ انتخاب‌شده، اطمینان، ارجاع state، نسخه‌ی قرارداد، و پاسخ فعلیِ production را ثبت می‌کند — همراه با برچسب انسانی، هرجا در دسترس باشد.

حالت سایه این فایده را دارد که اختلاف‌نظرها را زودتر نشان می‌دهد، بدون اینکه کاربر واقعی را در معرضشان بگذارد. همچنین دقیقاً همان داده‌ای را می‌سازد که برای آزمودن این سؤال لازم دارید: آیا اطمینان بالاتر واقعاً با درستیِ بالاتر جور در می‌آید یا نه.

ه. برچسب‌ها و داوری‌شان

برچسب انسانی به یک rubric نوشته‌شده و یک مسیر داوری نیاز دارد. اگر بازبینان مرتب با هم اختلاف نظر دارند، احتمالاً مشکل از قرارداد است، نه از مدل. اختلاف‌نظر را نگه دارید و زودهنگام اجماع تحمیل نکنید — همین اختلاف نشان می‌دهد مرز تصمیم هنوز به شفاف‌سازی نیاز دارد.

برای شاخه‌های پرپیامد، از بازبینان بخواهید هم پاسخ معنایی را برچسب بزنند و هم مسیر مجاز را. این کار کمک می‌کند یک قضاوت درست را از یک سیاست اتوماسیونِ امن، جدا نگه دارید.

و. کل سیستم را ارزیابی کنید، نه فقط یک عدد

دقت متوسط تصمیم به‌تنهایی کافی نیست. تأخیر تصمیم را اندازه بگیرید، هزینه‌ی مسیر را، دقت شاخه را، کالیبراسیون را، هزینه‌ی ابزار پایین‌دست را، هزینه‌ی بازیابی را، نرخ بازبینی انسانی را، و نرخ وظیفه‌ی کامل‌شده را. هدف واقعی کسب‌وکار، هزینه و قابلیت‌اعتماد به‌ازای هر وظیفه‌ای است که واقعاً تمام می‌شود.

جدول VIII. قیمت هر فراخوانی فقط یک تکه از اقتصادِ کل وظیفه‌ی تکمیل‌شده است.

ز. امن‌ترین شاخه را اول خودکار کنید

بعد از ارزیابی در حالت سایه، همان پیامدی را که هم پیامدش پایین است و هم کالیبراسیونش قوی، خودکار کنید. موارد نادر، نامطمئن یا پرپیامد را همچنان پشت مسیر بازبینیِ موجود نگه دارید. رفتار حالت سایه را با baseline مقایسه کنید و همیشه یک راه بازگردانیِ فوری داشته باشید.

ح. هر بار فقط یک مرز را باز کنید

یک توالی معمول معمولاً با مسیریابی داخلی شروع می‌شود، بعد فیلترکردن بازیابی، وارسی تکمیل، انتخاب مدل، و در نهایت دروازه‌بانیِ ابزارهای کم‌ریسک. اقدامات پرپیامد باید دیرتر بیایند و همیشه با سیاست و تأیید صریح احاطه شوند. این توالی کمک می‌کند هر حالت شکست، همچنان قابل‌مشاهده بماند.

ط. مراقب رانش باشید

کاربرها عوض می‌شوند، ابزارها عوض می‌شوند، گزینه‌ها و زبان هم همین‌طور. دقت و کالیبراسیون را به‌تفکیک نسخه‌ی قرارداد و در یک پنجره‌ی زمانی اخیر رصد کنید. افزایش نرخ بازبینی انسانی، افت کیفیت state، یک منوی کهنه، یا یک دسته‌ی جدید که قرارداد نمی‌تواند دسته‌بندیش کند — همه نشانه‌اند. با رانش معنایی دقیقاً مثل رانش نرم‌افزار رفتار کنید: بازرسی کنید، آزمون بگیرید، نسخه‌بندی کنید، و اگر لازم شد برگردانید.

قیمتی که TypeSafe منتشر کرده، هر تصمیم منفرد را خیلی ارزان می‌کند. اما این اقتصاد، فراخوانی‌های غیرضروری را توجیه نمی‌کند؛ اقتصاد واقعی همیشه پایین‌دست است. یک گراف کوچک با مرزهای باکیفیت، همیشه بهتر از یک گراف متراکم پر از طبقه‌بندهای کم‌ارزش است.

ی. حفاظ‌های لازم برای استقرار

اولین شاخه‌ی خودکار را بر اساس سهم ترافیک، مستأجر، زبان و پیامد محدود کنید. موارد خودکارشده را نمونه‌برداری کنید و بازبینی کنید، مسیر قدیمی را همچنان به‌عنوان fallback نگه دارید، و پیش از راه‌اندازی یک ماشه‌ی بازگردانی مشخص کنید. این حفاظ‌ها باید همیشه قطعی باشند و مستقل از اطمینانِ Jev.

یک استقرار فقط وقتی واقعاً کامل است که تیم بتواند پیامدهای انتها-به-انتها را مقایسه کند، نه فقط توافق طبقه‌بند را. سود مورد انتظار باید در تأخیر، هزینه، بار بازبینی، یا نرخ وظیفه‌ی تکمیل‌شده دیده شود — بدون اینکه به‌همان‌اندازه کار بازیابی زیادتر شده باشد.

X. حالت‌های شکست و اصلاح‌ها

الف. نتیجه‌گیری‌ای که مثل شاهد جا زده شده

یک فیلد state می‌گوید «تحقیق احتمالاً کافی است». Jev هم همین نتیجه‌گیری را تأیید می‌کند، چون به‌عنوان یک حقیقت به آن داده شده. اصلاحش این است که به‌جای این جمله، شواهد قابل‌مشاهده را ذخیره کنید: تعداد منبع، نوع منبع، ادعاهای تأییدشده، ادعاهای هنوز حل‌نشده، و تازگی.

ب. منویی که راه‌فرار ندارد

هر گزینه‌ی فهرست‌شده در واقع اشتباه است، اما قرارداد همچنان یک برنده می‌خواهد. نتیجه اطمینان‌بخش به‌نظر می‌رسد، فقط چون احتمال مجبور است روی همان منوی بسته جمع شود. هرجا احتمال دارد منو ناقص باشد، یکی از این‌ها را اضافه کنید: none، other، stop یا review.

ج. یک آستانه برای همه‌ی پیامدها

یک دسته‌بندیِ داخلی و یک اقدام عمومی، هر دو از یک آستانه‌ی اطمینان یکسان استفاده می‌کنند — و این کیفیتِ پیش‌بینی را با اختیار قاطی می‌کند. آستانه‌ها را بر اساس کلاس اقدام تعریف کنید، و اقدامات برگشت‌ناپذیر را همیشه زیر نظر انسان نگه دارید.

د. گزینه‌هایی که دیگر واقعی نیستند

کارگر انتخاب‌شده دیگر در دسترس نیست، کنترل مرورگر ناپدید شده، منبع تغییر کرده. راه‌حل این است که مجموعه‌ی گزینه را از state زنده دوباره بسازید و به هر تصمیم یک نسخه‌ی مشخص متصل کنید.

ه. تلاش دوباره‌ای که چیزی یاد نمی‌گیرد

همان تصمیم نامطمئن، بارها با همان شواهد ارزیابی می‌شود، بدون اینکه چیز جدیدی یاد گرفته شود. بودجه‌ی تلاش دوباره را طوری تنظیم کنید که یا شواهد تازه‌ای اضافه کند، یا قرارداد را عوض کند، یا منو را محدودتر کند، یا در نهایت تصعید کند.

و. ثبت فقط برنده، نه کل ماجرا

ردیابی فقط برچسب انتخاب‌شده را نگه می‌دارد و توزیع، آستانه، ارجاع state و مسیر را دور می‌ریزد. نتیجه این است که کالیبراسیون و ممیزی هر دو غیرممکن می‌شوند. همیشه یک رسید تصمیم کامل ذخیره کنید.

ز. سیاستی که قایم شده توی طبقه‌بند

پرسش می‌پرسد چه چیزی باید مجاز باشد، و کد اپلیکیشن هم کورکورانه همان پاسخ را اجرا می‌کند. این یعنی به یک قضاوت احتمالاتی، اختیار قطعی داده‌اید. مجوزها، بودجه‌ها، دامنه‌ها و عوارض جانبی بیرونی را همیشه در سیاست قطعی نگه دارید، نه در پاسخ مدل.

ح. قوانین دقیقی که اشتباهی به Jev سپرده شده‌اند

تعداد تلاش‌ها، تاریخ‌ها، موجودی‌ها، رشته‌های دقیق — این‌ها را به یک مدل معنایی نفرستید. از کد استفاده کنید. قضاوت معنایی هرگز نباید جایگزین یک محاسبه یا یک ناوردایی شود که برنامه از قبل بدون شک می‌داند.

ط. اول بفهمید خطا از مدل است یا از قرارداد

وقتی یک تصمیم اشتباه از آب در می‌آید، اول بپرسید: آیا state شواهد لازم را داشت؟ آیا مجموعه‌ی گزینه معتبر بود؟ آیا آستانه به مسیر درست نگاشته شده بود؟ فقط بعد از این سه چک است که می‌شود گفت مشکل از توانایی خودِ مدل بوده. این ترتیب تشخیصی جلوی این را می‌گیرد که خطاهای harness را با مدل‌های بزرگ‌تر، پرامپت‌های طولانی‌تر یا فراخوانی‌های تکراری جبران کنید، در حالی که مرز واقعاً معیوب دست‌نخورده می‌ماند.

ی. برچسبی که یک مقدار ناشناخته را پنهان کرده

قرارداد از Jev می‌خواهد یک نام، URL، شناسه یا عددی بسازد که اصلاً در schema خروجی اعلام نشده. این دیگر استخراج یا تولید است، نه یک Choice تایپ‌شده. از ابزار مناسبش استفاده کنید، و فقط بعد از اینکه مجموعه‌ی پیامدها مشخص شد دوباره به Jev برگردید.

ک. یک طرح چندمرحله‌ای که در یک پاسخ فشرده شده

یک برچسب به‌طور ضمنی جست‌وجو، وارسی و اجرا را با هم نشان می‌دهد، بدون اینکه هیچ شاهد میانی‌ای بین آن‌ها باشد. راه‌حل این است که گراف را باز کنید: اول ابزاری که شواهد می‌سازد را اجرا کنید، بعد state را به‌روز کنید، و بعد پرسش بعدی را بپرسید.

ل. وارسیِ ناقص که فقط موفقیتِ انتقال را چک می‌کند

ابزار کد ۲۰۰ یا خروج صفر برمی‌گرداند، و سیستم هم همین را معادل موفقیت می‌گیرد. به‌جایش خودِ هدف را وارسی کنید: وجود artifact، ساختار موردنیاز، شواهد، مقصد درست، و اینکه هیچ تأیید معلقی باقی نمانده باشد.

م. تغییر قرارداد بدون هیچ ارزیابی‌ای

یک ویرایش کلامی یا تغییر یک گزینه، مثل یک ویرایش بی‌ضرر پرامپت دیپلوی می‌شود — اما در واقعیت منطق تصمیم را عوض می‌کند. قرارداد را نسخه‌بندی کنید، روی نمونه‌های تاریخی اجرایش کنید، تغییر رفتار را مقایسه کنید، و همیشه یک راه بازگردانی نگه دارید.

ن. یک جدول کوتاه برای اصلاح سریع

جدول IX. خیلی از نقص‌هایی که ظاهراً مربوط به مدل به‌نظر می‌رسند، در واقع ریشه‌شان جای دیگری در harness است.

س. ترتیب عملیاتیِ امن، خلاصه‌شده در یک جمله

Jev قضاوت می‌کند؛ کد سیاست را چک می‌کند؛ رکوردهای ردیابی مسیر را ثبت می‌کنند. مدل یک پریمیتیو تازه به شما می‌دهد؛ حلقه تصمیم می‌گیرد این پریمیتیو کجا بنشیند؛ harness تعیین می‌کند سیستم اصلاً مجاز است چه‌کاری انجام بدهد؛ و ردیابی در نهایت به تیم می‌گوید این معماری واقعاً کار کرده یا نه.

ع. وقتی نوبت بازبینی یک حادثه می‌رسد

بازبینی حادثه باید state، قرارداد، توزیع، آستانه، سیاست، اقدام و پیامد را دوباره کنار هم بگذارد. باید اولین مرزی که خراب شده را پیدا کند، نه فقط آخرین شکستی که همه دیدند. اقدام اصلاحی ممکن است به ساخت state تعلق داشته باشد، به تولید منو، به عبارت قرارداد، به کالیبراسیون، به سیاست، یا به خودِ اجرا.

state‌های حادثه‌های مهم را به‌عنوان fixture‌های رگرسیونِ دائمی نگه دارید. یک اصلاح تا وقتی که سیستمِ اصلاح‌شده روی همان fixtureها دقیقاً همان قضاوت و مسیر درست را تولید نکند — بدون اینکه موارد بی‌ربط را خراب کند — کامل حساب نمی‌شود.

XI. کتاب‌راهنمای پیاده‌سازی و منابع

الف. ده گام برای پیاده‌سازی

1. حلقه‌ی ایجنت را نقشه‌برداری کنید و هر تصمیم پنهانِ choice، score، قضاوت بله/خیر، تلاش دوباره و توقف را علامت بزنید.
2. خلق باز-پاسخ را همچنان در LLM مولد نگه دارید و ناوردا‌های دقیق را در کد قطعی.
3. یک شاخه‌ی معنایی تکراری و کم‌پیامد را برای اولین یکپارچه‌سازی Jev انتخاب کنید.
4. قرارداد تصمیم را بنویسید: state، دستورالعمل‌ها، پیامدها، راه‌فرار، آستانه‌ها، اختیار، تصعید و نسخه.
5. به‌جای فرستادن تکه‌های transcript، بسته‌های شواهد فشرده بسازید.
6. پرسش‌های مستقل را روی یک عکس‌فوری تغییرناپذیر از state، دسته‌ای کنید.
7. اطمینان را به مسیرهای اتوماسیون، بهبود-state و بازبینی-انسانی مسیریابی کنید.
8. اول در حالت سایه اجرا کنید و کالیبراسیون را روی یک نمونه‌ی واقعاً نماینده اندازه بگیرید.
9. امن‌ترین شاخه را اول خودکار کنید و همیشه یک راه بازگردانی نگه دارید.
10. هر بار فقط یک مرز را باز کنید، در حالی که اقتصاد وظیفه‌ی تکمیل‌شده را رصد می‌کنید.

ب. یک چک‌لیست قبل از راه‌اندازی

• تصمیم واقعاً معنایی است، نه مولد و نه دقیق.
• state فشرده است، به‌روز است و مبتنی بر شواهد است.
• دستورالعمل‌ها معنا را صریح تعریف می‌کنند.
• Choice جایی که لازم است راه‌فرار دارد.
• Score از لنگرهای کلامیِ مرتب استفاده می‌کند.
• Noul به‌عنوان عدم‌قطعیتِ بله/خیر تفسیر می‌شود، نه شدت.
• اطمینان واقعاً مسیر را عوض می‌کند.
• اختیار بیرونی همچنان دست کد است.
• پرسش‌های مستقل یک نسخه‌ی state مشترک دارند.
• پرسش‌های وابسته منتظر می‌مانند تا state به‌روز شود.
• آستانه‌ها اختصاصیِ همان پیامدند.
• کل توزیع، نه فقط برنده، در رسید ذخیره می‌شود.
• قرارداد قبلاً در حالت سایه اجرا شده.
• آزمون‌های نماینده، ابهام و موارد بدون گزینه‌ی مناسب را هم شامل می‌شوند.
• هر تلاش دوباره یا شواهد تازه می‌آورد یا گراف را عوض می‌کند.
• سیستم می‌تواند امن متوقف شود یا تصعید کند.

ج. جمع‌بندی

Jev جایگزین مدل مولد نیست؛ یک لایه‌ی گمشده در کنار آن است. LLM کانتکست را به کار تازه تبدیل می‌کند. Jev، state را به قضاوت تایپ‌شده تبدیل می‌کند. کد هم قضاوت را به اقدام کنترل‌شده تبدیل می‌کند. وقتی این سه مسئولیت را از هم جدا نگه دارید، تولید غیرضروری کم می‌شود، عدم‌قطعیت قابل‌عمل می‌شود، و harness یک مرز اختیار دارد که واقعاً می‌شود دنبالش کرد.

بهبود اصلی، فقط یک عدد کمتر برای تأخیر یا هزینه نیست. تبدیل قضاوت‌های پنهان به مؤلفه‌هایی است که نسخه دارند، قابل‌آزمون‌اند، شاهد دارند، آستانه دارند، fallback دارند، رسید دارند و می‌شود برشان گرداند. همین تفاوت است بین اضافه‌کردن یک فراخوانی دیگر به مدل، و واقعاً مهندسی‌کردن یک ایجنت.

د. منابع

1. Rari. «Jev Engineering: Stop Using LLMs for Every Decision.» مقاله‌ی X، ۲۱ سپتامبر ۲۰۲۶.
2. مواد راه‌اندازی و پست‌های TypeSafe AI از Diogo Almeida، به‌نقل و خلاصه در منبع ۱. بازه‌های ادعاشده‌ی تأخیر، قیمت و ۲۰-۲۰۰ برابر / ۴۰-۴۰۰ برابر ادعای فروشنده و وابسته به بار کاری‌اند.
3. «مهندسی Jev برای ایجنت‌های کدنویسی.» یادداشت کاری مستقل ارائه‌شده همراه این پروژه.