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

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

GoGinQUIC / HTTP/3 (quic-go)gRPC + Protocol BuffersGorilla WebSocketPostgreSQLSQLiteRedisunidoc/unioffice + unipdfCobraLLMsVerifier bridgeDocker / Podman

منبع

HelixTranslate — no silent fallback Local runtimes — removed if unavailable if none verified Translation request Explicit provider requested? Verified model available? Select strongest-verified Deterministic fallback chain Translate on verified model Honest hard error no silent fallback · no local runtime Ollama · llama.cpp removed from default path
// معماری

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

HelixTranslate پلتفرم ترجمه کتاب الکترونیکی با کارایی بالا و مبتنی بر Go است که کتاب‌ها را بین بیش از ۱۰۰ زبان با استفاده از ارائه‌دهندگان LLM تأییدشده ترجمه می‌کند. این سیستم دارای نظارت WebSocket بلادرنگ و سیاست مسیریابی «عدم جایگزینی خاموش» است که به جای افت بی‌صدا، با شکست آشکار مواجه می‌شود.

ابزار جامع ترجمه کتاب الکترونیکی مبتنی بر Go. فرمت‌های FB2، EPUB، TXT، HTML، PDF و DOCX را در بیش از ۱۰۰ زبان با استفاده از قوی‌ترین مدل‌های LLM تأییدشده (از طریق پل LLMsVerifier) ترجمه می‌کند. این سیستم از APIهای REST/HTTP-3 و gRPC، پردازش توزیع‌شده و داشبورد نظارت WebSocket بلادرنگ بهره می‌برد.

HelixTranslate یک سیستم سازمانی و مبتنی بر Go برای ترجمۀ کامل کتاب‌ها بین زبان‌ها با استفاده از ارائه‌دهندگان LLM است — نه پاراگراف‌ها یا قطعات کوتاه، بلکه آثار بلند از ابتدا تا انتها. این سیستم فرمت‌های مختلف کتاب الکترونیکی (FB2، EPUB، TXT، HTML، PDF، DOCX) را تجزیه و بازسازی می‌کند، از بیش از ۱۰۰ زبان با تشخیص خودکار پشتیبانی کرده و هم ابزارهای CLI و هم سرورهای API (REST بر بستر HTTP/3، gRPC و جریان رویداد WebSocket) را ارائه می‌دهد تا هم در گردش کار ترمینال و هم در معماری سرویس‌مش به‌خوبی جای گیرد.

ویژگی تعیین‌کنندۀ این سیستم *نحوۀ انتخاب مدل* است: به جای کدنویسی ثابت یک ارائه‌دهنده و امید به سلامت آن، HelixTranslate تمام اختیارات مدل را به پل LLMsVerifier (pkg/bridge) واگذار می‌کند که قوی‌ترین مدل API *تأییدشده* را انتخاب کرده و زنجیرۀ جایگزین قطعی و مرتب‌شده بر اساس امتیاز را بازمی‌گرداند. صلاحیت مدل بر اساس امتیاز وزنی در معیارهایی همچون پاسخگویی، کد، غنای ویژگی‌ها و قابلیت اطمینان تعیین می‌شود — بنابراین مدلی که ترجمۀ شما را انجام می‌دهد، جایگاه خود را با اثبات کارایی‌اش به دست آورده است، نه با حضور در یک فایل پیکربندی.

نکتۀ حیاتی این است که سیستم در کد خود اصل «عدم جایگزینی خاموش» را به‌طور جدی اعمال می‌کند: اگر کلید API ارائه‌دهنده موجود نباشد یا اپراتور به‌طور صریح درخواست ارائه‌دهندۀ غیرقابل‌دسترس کند، خط لوله به جای تعویض بی‌صدای ارائه‌دهنده یا افت به زمان اجرا محلی و وانمود کردن اینکه همه چیز خوب است، با خطای سخت و آشکار مواجه می‌شود — قانونی که با یک دروازۀ پیش‌ساخت اختصاصی و آزمون جهش جفت‌شده تثبیت شده است. زمان‌های اجرای محلی (Ollama، llama.cpp) به‌طور عمد از مسیر پیش‌فرض حذف شده‌اند تا هیچ موتور ضعیف‌تری نتواند به‌طور پنهانی جایگزین یک مدل تأییدشده شود.

در اطراف هستۀ ترجمه، زیرسیستم نظارت WebSocket بلادرنگ قرار دارد: ابزار ترجمۀ CLI رویدادهای تایپ‌شده را به سرور نظارت ارسال می‌کند که داشبورد وب زنده را هدایت می‌کند، در حالی که کارگران SSH از راه دور بار کاری را برای ترجمۀ توزیع‌شده پخش می‌کنند. بر روی این لایه‌ها، پرداخت چندمرحله‌ای برای یکنواختی، تحلیل کیفیت در مرحلۀ آماده‌سازی، کش ترجمه برای مدیریت هزینه در ورودی‌های طولانی و تضمین کیفیت مبتنی بر بینایی قرار گرفته است. کل پلتفرم بر اساس قانون اساسی مهندسی ضد-لاف‌زنی عمل می‌کند: آزمون‌ها باید نتایج واقعی و قابل‌مشاهده برای کاربر را اثبات کنند و پشتوانۀ آن‌ها آزمون جهش اجباری است، نه تیک‌های سبزی که هیچ چیزی را اثبات نمی‌کنند.

محتوا

برای ترجمهٔ کتاب‌های بلند به‌صورت قابل‌اعتماد و *صادقانه* — هرگز ترجمه‌ای «ناقص اما موجود» ارائه نکنیم. اصل طراحی این است که ترجمهٔ گم‌شده یا تأییدنشده باید خطایی بلند و سخت باشد، و انتخاب مدل همیشه باید به یک ارائه‌دهندهٔ واقعی و تأییدشده ختم شود، نه حدس از پیش تعیین‌شده یا جایگزینی خاموش محلی.

بیشتر خطوط لولهٔ ترجمهٔ HelixTranslate به‌صورت خاموش شکست می‌خورند — بی‌صدا به مدل ضعیف‌تر بازمی‌گردند، به محیط محلی می‌لغزند، یا خروجی ناقص تولید می‌کنند در حالی که مجموعهٔ آزمون همچنان سبز می‌ماند و کسی متوجه سقوط کیفیت نمی‌شود. HelixTranslate این حالت شکست را به‌کلی غیرممکن می‌سازد: انتخاب مدل دروازه‌دارِ تأیید است، زنجیرهٔ جایگزین قطعی و کاملاً شفاف است، و «نبود کلید / نبود مدل تأییدشده» به خطای سخت صادقانه ختم می‌شود، نه به بی‌تفاوتی خاموش. همین تصمیم طراحی، پرسش «آیا این ترجمه واقعاً با مدل توانمند و تأییدشده اجرا شده؟» را از امیدی که نمی‌توان بررسی کرد به ضمانتی تبدیل می‌کند که سیستم به‌جای شما اجرا می‌کند.

  • مسیردهی مدل دروازه‌دارِ تأیید از طریق پل LLMsVerifier — قوی‌ترین مدل *تأییدشده* به‌طور خودکار انتخاب می‌شود، بنابراین اپراتورها نیّت خود را اعلام می‌کنند، نه نام فروشنده، و هرگز ارائه‌دهنده‌ای را به‌صورت دستی انتخاب نمی‌کنند که ممکن است از دسترس خارج باشد.
  • ضمانت عدم جایگزینی خاموش که در کد اعمال می‌شود — چهار شاخهٔ مسیریابی صریح (ماک / تأییدکنندهٔ صریح / ارائه‌دهندهٔ صریح / پیش‌فرض پل)، که هر یک به‌جای تعویض خاموش، خطای سخت تولید می‌کنند، به‌علاوه حذف عمدی محیط‌های محلی از مسیر پیش‌فرض تا چیزی ضعیف‌تر برای جایگزینی وجود نداشته باشد.
  • اجرای مکانیکی — دروازهٔ پیش‌ساخت CM-NO-LOCAL-RUNTIME به‌همراه آزمون جهش‌یافتهٔ جفت‌شده، در زمان ساخت تأیید می‌کند که هیچ کلاینت محیط محلی هرگز در مسیر پیش‌فرض ساخته نمی‌شود: این ضمانت نمی‌پوسد زیرا اگر چنین شود، ساخت با شکست مواجه می‌شود.
  • زنجیرهٔ جایگزین قطعی و مرتب‌شده بر اساس امتیاز — جایگزینی ارائه‌دهنده به ارائه‌دهنده در میان مدل‌های *تأییدشده* مجاز و کاملاً شفاف است، تمایزی اصولی با جایگزینی خاموش ممنوع: همیشه می‌دانید کدام مدل توانمند کار را به‌دست گرفته است.
  • پایش بلادرنگ WebSocket — رویدادهای ترجمهٔ تایپ‌شده به‌صورت زنده به داشبورد ارسال می‌شوند، با کارگران توزیع‌شدهٔ SSH تا کار ترجمهٔ کتاب به‌صورت موازی و قابل‌مشاهده انجام شود، نه در جعبه‌ای سیاه.
  • رژیم آزمون ضدفریب — آزمون جهش، ادعاهای منفی، اجرای سیستم واقعی، و تضمین کیفیت مبتنی بر بینایی با هم تضمین می‌کنند که «آزمون‌ها قبول می‌شوند» هرگز نتواند «قابلیت واقعاً کار نمی‌کند» را به‌صورت خاموش پنهان کند.

  • ضمانت خط لولهٔ ترجمهٔ صادقانه (بدون تنزل کیفیت خاموش). با متمرکزسازی همهٔ اختیارات مدل در پل LLMsVerifier حل شد تا نقطهٔ تصمیم‌گیری واحدی برای نظارت وجود داشته باشد، کدگذاری چهار شاخهٔ مسیریابی صریح که هر یک به‌جای حدس زدن، با خطای بلند شکست می‌خورند، حذف کامل جایگزین‌های محیط محلی از مسیر پیش‌فرض، و جوشکاری این قانون با دروازهٔ ساخت به‌علاوه آزمون جهش که اگر ضمانت هرگز حذف شود، ساخت با شکست مواجه می‌شود.
  • «آزمون‌ها سبز، قابلیت‌ها شکسته.» این حالت شکست در قانون اساسی به‌صراحت نام برده شده و با رژیم آزمون ضدفریب شکست داده می‌شود: ادعاهای ملموس و قابل‌مشاهده برای کاربر به‌جای جزئیات پیاده‌سازی، سیستم‌های واقعی در حلقه (ماک‌ها محدود به آزمون‌های واحد)، آزمون جهش اجباری (شکست عمدی قابلیت باید آزمون را قرمز کند)، و تضمین کیفیت مبتنی بر بینایی که واقعاً به خروجی نگاه می‌کند.
  • کیفیت چندقالبی و بلندمدت. ورودی‌های به‌اندازهٔ کتاب هم ثبات و هم بودجه را تحت فشار قرار می‌دهند؛ با پرداخت چندمرحله‌ای که متن را دوباره مرور می‌کند، تحلیل فاز آماده‌سازی که حجم کار را از پیش تخمین می‌زند، و حافظهٔ نهان ترجمه که از پرداخت دوبارهٔ یک بخش جلوگیری می‌کند، حل شد.

محتوا

  • Go — به‌خاطر ساختارهای همزمانی‌اش انتخاب شده که به‌طور طبیعی با پردازش، ترجمه و جریان‌دهی همزمان چندین فصل سازگار است؛ بک‌اند با همزمانی بالا، ماژول digital.vasic.translator.
  • Gin — به‌عنوان یک مسیریاب HTTP سریع و کم‌حجم برای سرویس‌دهی به سطح REST API انتخاب شده است.
  • QUIC / HTTP/3 (quic-go) — برای فراهم‌کردن یک انتقال کم‌تأخیر و مدرن برای REST API انتخاب شده که در شبکه‌های ناپایدار نیز کارایی خود را حفظ می‌کند.
  • gRPC + Protocol Buffers — برای ایجاد یک رابط سرویس قویاً تایپ‌شده و با کارایی بالا در کنار REST برای فراخوانی‌های برنامه‌نویسی انتخاب شده است.
  • Gorilla WebSocket — برای انتقال جریان رویدادهای ترجمه به‌صورت بلادرنگ و تایپ‌شده انتخاب شده که داشبورد نظارتی را به‌صورت زنده تغذیه می‌کند.
  • PostgreSQL, SQLite, Redis — تقسیم عمدی سه‌لایه: PostgreSQL برای داده‌های رابطه‌ای پایدار، SQLite برای وضعیت محلی/توکار (که همچنین پشتیبان فروشگاه مدل‌های تأییدشده پل است، data/verified_models.db) و Redis به‌عنوان حافظهٔ پنهان داغ.
  • unidoc/unioffice + unipdf — برای مدیریت فرمت‌های دشوار انتخاب شده‌اند: پردازش و بازسازی DOCX و PDF به‌گونه‌ای که کتاب‌های الکترونیکی چندفرمته به‌طور دقیق دورگردانی شوند.
  • Cobra — به‌عنوان چارچوب CLI انتخاب شده که ابزار unified-translator و ابزارهای همراه آن را قدرت می‌بخشد.
  • golang-jwt (JWT HS256) — برای احراز هویت بدون‌حالت API انتخاب شده که همراه با محدودیت نرخ توکن بر اساس IP و امنیت انتقال TLS/QUIC برای سخت‌کردن سطح حمله استفاده می‌شود.
  • پل LLMsVerifier (pkg/bridge) — محور اصلی: قوی‌ترین مدل تأییدشده به‌همراه زنجیرهٔ بازگشتی قطعی‌اش را تأمین می‌کند و به‌عنوان تنها نقطهٔ اعمال تضمین «عدم بازگشت خاموش» عمل می‌کند.
  • Testify — برای مجموعه تست‌های Go انتخاب شده است، از جمله تست اختصاصی provider_routing_test.go و دروازه‌های تغییر که قوانین صداقت را صادق نگه می‌دارند.
  • Docker / Podman (بدون نیاز به روت) + Compose — برای استقرار کانتینری و توزیع‌شده (docker-compose.distributed.yml) انتخاب شده‌اند، با Podman بدون نیاز به روت برای وضعیت امنیتی سخت‌گیرانه‌تر.

  • وضعیت: بتا. پلتفرم کارکردی است؛ نسخه در فایل‌های VERSION، Makefile و AGENTS.md به‌طور ناهماهنگ ذکر شده و بنابراین غیرقطعی تلقی می‌شود.
  • مجوز: نامشخص. فایل README ادعای مجوز MIT دارد اما این موضوع در فایل LICENSE تأیید نشده است — پیش از اعلام، تأیید شود.
  • نقاط پایانی داشبورد/نظارت فقط محلی هستند و عمومی نیستند. اعداد عملکرد WebSocket در مستندات اهداف اعلام‌شده هستند و تأیید نشده‌اند. فایل ARCHITECTURE.md همچنان به موتورهای محلی Ollama که حذف شده‌اند اشاره دارد (اطلاعات قدیمی).

اولویت لایه: Helix-اصلی (خوشهٔ LLM-زیرساخت). در خانوادهٔ پلتفرم‌های Helix، پس از HelixTrack قرار دارد.