// سطح: helix-primary · سفارش 11

LLMsVerifier betaاجازه‌نامه: TBD

GoGinSQLite + SQLCipherRedisRabbitMQ + KafkagRPC + Protocol BuffersQUIC / HTTP-3 (quic-go)JWT + LDAP/NTLMAngularPython + JavaScript SDKsDocker / Kubernetes / HelmPrometheus + Grafana

منبع

Candidate model provider API Do you see my code? real HTTP comprehension test Verified & usable (llmsvd) suffix Verified-only export OpenCode · Crush · Claude Code Rejected never exported LLMsVerifier — mandatory verification gate PASS FAIL
// معماری

تأیید. نظارت. بهینه‌سازی.

LLMsVerifier یک پلتفرم سازمانی برای تأیید، نظارت و بهینه‌سازی مدل‌های زبانی بزرگ در میان ارائه‌دهندگان مختلف است که بر اساس آزمون اجباری «آیا کد من را می‌بینی؟» ساخته شده است تا تنها مدل‌هایی که ثابت شده واقعاً کار می‌کنند، به‌عنوان قابل استفاده علامت‌گذاری یا صادر شوند.

پلتفرم Go که مدل‌های زبانی بزرگ را در میان چندین ارائه‌دهنده تأیید، معیارسنجی، نظارت و بهینه‌سازی می‌کند. هر مدل پیش از استفاده باید از آزمون اجباری دیدن کد عبور کند؛ سپس آزمایش‌های تأخیر، استریم، فراخوانی تابع، بینایی و تعبیه را پشت سر می‌گذارد و تنها تنظیمات تأییدشده را برای ابزارهای AI و CLI صادر می‌کند.

LLMsVerifier یک پلتفرم جامع برای تأیید، نظارت و بهینه‌سازی عملکرد LLM در میان ارائه‌دهندگان مختلف است. اصل محوری آن *تأیید اجباری* است و در این زمینه هیچ سازشی نمی‌پذیرد: پیش از آنکه هر مدلی به‌عنوان قابل استفاده علامت‌گذاری شود — یا اجازه ورود به تنظیمات صادرشده را پیدا کند — باید آزمون «آیا کد من را می‌بینی؟» را با موفقیت پشت سر بگذارد؛ آزمونی که با ارسال درخواست‌های واقعی HTTP به ارائه‌دهنده و تحلیل پاسخ‌ها برای درک واقعی (و نه صرفاً بازتابی شبیه به واقعیت) انجام می‌شود. مدلی که نتواند به‌طور قطعی ورودی شما را ببیند و درک کند، هرگز برچسب «قابل استفاده» را دریافت نخواهد کرد. پس از عبور از این مرحله، موتور تأیید‌کننده مجموعه‌ای کامل از آزمایش‌های قابلیت را اجرا می‌کند — وجود، پاسخگویی، تأخیر، استریم، فراخوانی تابع، بینایی و embeddings — و موتور گزارش‌دهنده نتایج را به گزارش‌های مارک‌داون و JSON تبدیل می‌کند که بر اساس آن‌ها می‌توان اقدام کرد.

این سیستم مدولار و رویدادمحور است و رابط‌های CLI، رابط کاربری متنی، وب و REST API را بر پایه هسته‌ای متشکل از موتور تأیید‌کننده، موتور گزارش‌دهنده و مدیر تنظیمات ارائه می‌دهد. اما کار این سیستم به تأیید محدود نمی‌شود. لایه‌های پیشرفته‌تر الگوی سرپرست/کارگر را برای تجزیه وظایف مبتنی بر LLM اضافه می‌کنند، مدیریت زمینه با پنجره لغزان و خلاصه‌سازی LLM را برای جلوگیری از افت کیفیت جلسات طولانی، نقطه‌گذاری ابری، و سیستمی برای بازیابی پس از شکست با مدارشکن‌ها و مسیریابی مبتنی بر تأخیر فراهم می‌آورند. زیرساخت پیرامونی آن برای محیط‌های عملیاتی طراحی شده است: اتوبوس رویداد مبتنی بر انتشار/اشتراک، زمان‌بندی کرون، تشخیص قیمت/محدودیت‌ها، پایگاه داده vector برای RAG، و سیستم صادرات. یک قرارداد نام‌گذاری مشخصه، پسوند (llmsvd) را به هر ارائه‌دهنده/مدل تولیدشده اضافه می‌کند تا خروجی تأییدشده در نگاه اول قابل ردیابی باشد و هرگز با خروجی‌های تأییدنشده اشتباه گرفته نشود — و تنها مدل‌های تأییدشده در تنظیمات صادرشده برای ابزارهای AI CLI مانند OpenCode، Crush و Claude Code نوشته می‌شوند. این سیستم با ابزارهای عملیاتی مورد نیاز تیم‌ها در محیط عملیاتی عرضه می‌شود: استقرار Docker/Kubernetes/Helm، نظارت Prometheus/Grafana، احراز هویت LDAP/SSO، و ذخیره‌سازی رمزنگاری‌شده با SQLCipher.

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

محتوا

این سامانه، ناوگان‌های LLM را *قابل اعتماد* می‌کند — واژه‌ای که به‌ندرت در فضایی پر از تنظیماتی که با سکوت دروغ می‌گویند، به دست می‌آید. به‌جای امید بستن به اینکه یک مدل پیکربندی‌شده کار کند، تیم‌ها تضمینی قابل آزمایش و اجباری دریافت می‌کنند که هر مدل در حال استفاده، آزمایش‌های واقعی را پشت سر گذاشته است؛ با نظارت، جایگزینی خودکار در صورت شکست و صادرات صرفاً تأییدشده که حلقه را از اثبات تا تولید می‌بندد. در اکوسیستم Helix، این سامانه به تنها منبع حقیقت برای مدل‌ها، ارائه‌دهندگان و فراداده‌های تأیید LLM تبدیل می‌شود: سایر سرویس‌ها (از جمله HelixTranslate) بر اساس آن مسیریابی می‌کنند، به‌طوری که کل پلتفرم به‌جای آنکه هر تیم حدس امیدوارانهٔ خود را داشته باشد، یک پاسخ صادقانه به این پرسش می‌دهد: «الان کدام مدل‌ها واقعاً کار می‌کنند؟»

  • تأیید اجباری «آیا کد من را می‌بینی؟» — دروازه‌ای واقعی و مبتنی بر HTTP برای درک مطلب که هر مدل باید پیش از قابل استفاده شدن از آن عبور کند؛ ویژگی متمایزکنندهٔ اصلی این محصول و دلیلی که هیچ چیز تأییدنشده‌ای از آن عبور نمی‌کند.
  • صادرات پیکربندی صرفاً تأییدشده — پیکربندی‌های تولیدشده برای ابزارهای AI و CLI *تنها* شامل مدل‌هایی هستند که تأیید شده‌اند، بنابراین پیکربندی‌ای که ارسال می‌کنید نمی‌تواند به‌طور پنهانی یک مدل معیوب را دوباره وارد کند.
  • سیستم پسوند برندینگ (llmsvd) — هر ارائه‌دهندهٔ تولیدشده/مدل، پسوندی قابل ردیابی دارد که اصالت تأییدشده را در هر جایی که خروجی سفر می‌کند، نمایان می‌سازد.
  • تشخیص قابلیت‌ها در میان بسیاری از عامل‌ها و ارائه‌دهندگان CLI — این سامانه به‌جای فرض کردن، انواع جریان داده (SSE، WebSocket، JSONL، EventStream)، فشرده‌سازی و رفتارهای کش را شناسایی می‌کند.
  • جایگزینی خودکار مقاوم — قطع‌کننده‌های مدار، مسیریابی مبتنی بر تأخیر که هنگام عبور زمان تا دریافت اولین توکن از آستانهٔ مشخصی، ترافیک را تغییر مسیر می‌دهد، پروب‌های سلامت و تقسیم ترافیک وزنی، ناوگان را حتی زمانی که ارائه‌دهندگان منفرد دچار نوسان می‌شوند، پاسخگو نگه می‌دارند.
  • خودمختاری طولانی‌مدت — الگوی تجزیهٔ ناظر/کارگر به‌همراه نقطهٔ بازرسی و یکپارچگی حافظه، جلسات طولانی‌ای را که در غیر این صورت بافتار را از بین می‌بردند، پایدار نگه می‌دارد.
  • یکپارچگی با RAG / vector-DB برای تقویت بافتار مبتنی بر داده‌های واقعی.

  • اثبات اینکه یک مدل واقعاً کار می‌کند، نه فقط اینکه پیکربندی شده است. هدف اصلی و سخت‌ترین بخش کار. با آزمون اجباری دیدن کد حل شد که تماس‌های واقعی API برقرار می‌کند و پاسخ‌ها را برای درک مطلب مثبت تحلیل می‌کند، پشتوانه‌اش مجموعه‌ای گسترده از آزمون‌های قابلیت است — و سپس با امتناع از صادرات هر چیزی که تأیید نشده باشد، اثبات (نه پیکربندی) را به دروازهٔ تولید تبدیل می‌کند.
  • پایداری در برابر ارائه‌دهندگان شخص ثالث ناپایدار. با یک هماهنگ‌کنندهٔ جایگزینی حل شد که ناپایداری ارائه‌دهندگان را حالت عادی فرض می‌کند: قطع‌کننده‌های مدار پس از N شکست در M ثانیه، یک ارائه‌دهنده را به‌عنوان معیوب علامت‌گذاری می‌کنند، مسیریابی مبتنی بر تأخیر از نقاط پایانی کند دوری می‌کند، پروب‌های سلامت دوره‌ای برای بازیابی جستجو می‌کنند و مسیریابی وزنی، مدل‌های مقرون‌به‌صرفه را با مدل‌های ممتاز متعادل می‌سازد.
  • پشتیبانی از جلسات طولانی و خودمختار. با الگوی تجزیهٔ ناظر/کارگر حل شد که کارهای بزرگ را به قطعات قابل مدیریت تقسیم می‌کند، نقطهٔ بازرسی دوره‌ای در ذخیره‌سازی ابری که پیشرفت را در برابر قطع شدن حفظ می‌کند و مدیریت لایه‌ای بافتار (پنجرهٔ لغزان + خلاصه‌سازی LLM + RAG) تا مدل بدون غرق شدن در توکن‌ها، موضوع را دنبال کند.
  • پراکندگی ارائه‌دهندگان. با پنهان کردن بسیاری از آداپتورهای Go اختصاصی هر ارائه‌دهنده پشت یک واسط مشترک حل شد، به‌طوری که نقاط پایانی واقعی به‌طور مرکزی فهرست می‌شوند — بنابراین افزودن یک ارائه‌دهنده تغییری محدود است، نه موجی در سراسر کدبیس.

محتوا

  • Go — به‌عنوان زبان اصلی پلتفرم انتخاب شده است؛ به دلیل قابلیت همزمانی، موتور تأیید چندرشته‌ای را به حرکت درمی‌آورد که می‌تواند به‌طور موازی مدل‌های متعددی را بررسی کند، به‌علاوه سرویس‌های پیرامونی.
  • Gin — به‌عنوان سرور REST API انتخاب شده است که احراز هویت، محدودسازی نرخ درخواست‌ها و نقاط پایانی WebSocket/SSE را مدیریت می‌کند.
  • SQLite + SQLCipher — برای ذخیره‌سازی تعبیه‌شده با رمزنگاری سطح پایگاه داده انتخاب شده‌اند، زیرا داده‌های تأیید (کلیدها، نتایج) حساس هستند و باید به‌طور پیش‌فرض در حالت استراحت رمزنگاری شوند.
  • Redis — به‌عنوان لایه کش انتخاب شده است تا جستجوهای داغ تأیید و فراداده‌ها با سرعت بالا انجام شوند.
  • RabbitMQ + Kafka — برای تأمین معماری رویدادمحور انتخاب شده‌اند: پیام‌رسانی و جریان داده‌ای که تولیدکنندگان را از مصرف‌کنندگان در سراسر پلتفرم جدا می‌کند.
  • gRPC + Protocol Buffers — برای ارتباطات قویاً تایپ‌شده بین سرویس‌ها و انتقال رویدادها بین مؤلفه‌ها انتخاب شده‌اند.
  • QUIC / HTTP-3 (quic-go) — برای پشتیبانی از انتقال مدرن انتخاب شده‌اند (اسناد مخزن، در دسترس بودن HTTP/3 را محدود توصیف می‌کنند — قابلیتی ارائه‌شده، نه ادعای جهانی).
  • JWT + LDAP/NTLM — برای احراز هویت سازمانی انتخاب شده‌اند تا پلتفرم در هویت شرکتی موجود (SSO/SAML/OIDC که در اسناد ادعا شده) ادغام شود.
  • Viper (پیکربندی)، Logrus (لاگینگ)، Brotli/compress (فشرده‌سازی) — زیرساخت عملیاتی: پیکربندی انعطاف‌پذیر، لاگ‌های ساختاریافته و فشرده‌سازی بار.
  • Angular — برای برنامه تک‌صفحه‌ای وب انتخاب شده است؛ دروازه بصری برای تأیید و نظارت.
  • Python + SDKهای JavaScript — برای دسترسی درجه‌یک تیم‌های کلاینت انتخاب شده‌اند که از طریق OpenAPI/Swagger مستند شده‌اند.
  • Docker، Kubernetes، Helm — برای استقرار تولید با نظارت سلامت و مقیاس‌بندی خودکار انتخاب شده‌اند تا ناوگان تأیید مانند هر سرویس مدرنی مقیاس‌پذیر باشد.
  • Prometheus + Grafana — برای معیارها و داشبوردها انتخاب شده‌اند تا سلامت خود پلتفرم به‌اندازه مدل‌هایی که نظارت می‌کند قابل مشاهده باشد.
  • Testify (Go) + node --test/jsdom (وب) — برای تست لایه‌ای در هسته Go و رابط کاربری وب انتخاب شده‌اند.

  • وضعیت: بتا. کد منبع Go تأیید HTTP واقعی را پیاده‌سازی می‌کند (یک سند قدیمی که تأیید را صرفاً مبتنی بر پیکربندی توصیف می‌کند، آرمانی و منسوخ است — کد معتبر است).
  • مجوز: نامشخص. فایل README مجوز MIT را اعلام کرده در حالی که یک برچسب Dockerfile مجوز Apache-2.0 را ذکر کرده است — پیش از انتشار باید حل شود.
  • تعداد ارائه‌دهندگان: فایل README از «۱۲ آداپتور» سخن می‌گوید اما دایرکتوری ارائه‌دهندگان حدود ۲۶ مورد را فهرست کرده است — آن را «۱۲+ / در حال توسعه بیشتر» در نظر بگیرید. فایل‌های وضعیت متعددی با برچسب «نهایی/کامل» وجود دارند؛ کد، مستندات و go.mod معتبر هستند.
  • مخزن در سازمان vasic-digital قرار دارد، اما از نظر کارکردی لایه اعتماد زیرساخت Helix LLM است.

سطح اولویت: Helix-اصلی (خوشه زیرساخت LLM؛ منبع واحد حقیقت برای فراداده‌های LLM/ارائه‌دهنده/تأیید). پس از HelixTrack قرار دارد.