تصور کنید سیستمی دارید که هر چند ساعت یک‌بار می‌میرد، اما هر بار با حالتی بهتر و بدون از دست دادن حتی یک بیت داده، دوباره زنده می‌شود. این دقیقاً همان رویکردی است که یک توسعه‌دهنده برای نجات خط لوله تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — به کار گرفته است.
به نقل از گزارشی که در ۹ اکتبر ۲۰۲۶ در dev.to منتشر شد، این سیستم پس از بازسازی، توانست ۱۹ بار ری‌استارت شدن توسط Watchdog و ۵ بار بسته شدن اجباری (Session Kill) را بدون هیچ آسیبی به داده‌ها تحمل کند. در حالی که اکثر برنامه‌نویسان تلاش می‌کنند از کرش کردن جلوگیری کنند، در این پروژه فرض بر این بود که سیستم «قطعاً خواهد مرد» و تمرکز روی این بود که این مرگ‌ها هیچ هزینه‌ای برای یکپارچگی داده‌ها نداشته باشند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی پایداری زیرساخت‌های هوش مصنوعی اشاره کردیم، تفاوت بین یک اسکریپت ساده و یک محصول واقعی در نحوه مدیریت خطاهاست. این موضوع یادآور بررسی ۹ خطای عملیاتی رایج است که نشان می‌دهد پایداری سیستم‌های هوش مصنوعی بیش از هر چیز به کیفیت لوله‌کشی وابسته است.
این سامانه به‌طور کامل روی یک مک‌بوک ایر ۸ گیگابایتی با استفاده از Ollama، مدل nomic-embed-text و پایگاه‌داده ChromaDB اجرا می‌شود. برای مدیریت ۸.۲ میلیون کاراکتر و ۱۱,۴۰۰ تکه متن (Chunk)، سه ابزار اختصاصی طراحی شده است:
- Scribe: موتور ورودی که نقاط بازرسی (Checkpoint) را قبل از انجام کار می‌نویسد تا سیستم دقیقاً از همان‌جایی که متوقف شده بود، ادامه دهد. این رویکرد برای حل مشکلاتی است که معمولاً در زنجیره RAG پیش از رسیدن داده‌ها به مدل زبانی (LLM) رخ می‌دهند و باعث نقص در خروجی می‌شوند.
- Warden: یک دیده‌بان (Watchdog) که با تحلیل نرخ ثبت لاگ‌ها، فرآیندهای یخ‌زده را شناسایی و حذف می‌کند.
- Hand: سیستمی که هر عملیات نوشتن در پایگاه‌داده برداری را در یک زیرفرآیند (Subprocess) ایزوله می‌کند تا یک سند خراب، کل سیستم را زمین نزند.
قلب تپنده این معماری، «نوشتارهای هم‌توان» یا Idempotent Writes (آپ‌سرت‌ها) است. به زبان ساده، یعنی تکرار یک عملیات، نتیجه‌ای متفاوت از یک‌بار اجرای آن ندارد؛ بنابراین سیستم می‌تواند بی‌نهایت بار کرش کند و ری‌استارت شود، بدون اینکه داده‌ای تکراری در پایگاه‌داده برداری ایجاد شود. این متد در واقع پاسخی به چالش‌های انتقال داده در مدل‌های RAG است که در معماری‌های رویدادمحور برای رفع خطاهای همزمانی به کار می‌روند.
این تغییر رویکرد نشان می‌دهد که در استقرار واقعی هوش مصنوعی، «لوله‌کشی» و نحوه مدیریت شکست‌ها، بسیار حیاتی‌تر از نسخه مدل انتخابی است. برای شما به عنوان کاربر یا توسعه‌دهنده، این یعنی جایگزینی اسکریپت‌های یکپارچه و شکننده با جریان‌های کاری ایزوله و دارای نقطه بازرسی.
گام بعدی شما
- در طراحی خط لوله‌های داده، به‌جای تلاش برای حذف خطا، مکانیزم Upsert را برای جلوگیری از تکرار داده‌ها پیاده کنید.
- فرآیندهای حساس را در Subprocessهای مجزا اجرا کنید تا خطای یک سند، کل برنامه را متوقف نکند.
- از نقاط بازرسی (Checkpoints) قبل از عملیات سنگین استفاده کنید تا زمان بازیابی سیستم به حداقل برسد.
اما تفاوت این طراحی با سیستم‌های مانیتورینگ مبتنی بر Heartbeat چیست؟ پاسخ این سوال را در گزارش بعدی ما درباره معماری Watchdog در برابر Heartbeat بخوانید.
گفتگو