# طرح مسئله: دستیار آموزشی آفلاین روی USB (Proof of Concept)...

Prompt

# طرح مسئله: دستیار آموزشی آفلاین روی USB (Proof of Concept) > این سند برای ارسال کامل به مدل‌های زبانی دیگر (جهت دریافت نظر تخصصی و مقایسه‌ی راه‌حل‌ها) نوشته شده است. تمام زمینه‌ی لازم در همین فایل موجود است. --- ## ۱. هدف پروژه طراحی یک نمونه‌ی اولیه (Proof of Concept) از یک ابزار کمک‌آموزشی کاملاً آفلاین برای دانشجویانی که به اینترنت دسترسی ندارند. هدف نهایی، ارائه‌ی این PoC به مراکز آموزشی در مناطق محروم است تا در محیط‌های کنترل‌شده از آن استفاده کنند. این پروژه صرفاً جنبه‌ی تحقیقاتی/آموزشی در حوزه‌ی NLP دارد. ## ۲. الزامات فنی (ثابت و غیرقابل مذاکره) 1. روی یک فلش USB (۳۲ گیگابایت، USB 3.0) نصب و بدون نیاز به نصب چیزی روی سیستم میزبان اجرا شود. 2. ورودی متنی از دو مسیر بپذیرد: فایل متنی مستقیم، یا OCR روی تصاویر اسکن‌شده. 3. از یک مدل زبانی کوچک (زیر ۲ گیگابایت روی دیسک) برای تولید پاسخ آموزشی استفاده کند. 4. روی ویندوز ۱۰/۱۱ با ۸ گیگابایت RAM و پردازنده‌ی Core i5 (بدون GPU اختصاصی) اجرا شود. 5. زمان پاسخ‌دهی هدف: کمتر از ۵ ثانیه (با quantization و بهینه‌سازی). 6. کاملاً آفلاین؛ هیچ داده‌ای نباید به بیرون ارسال شود. 7. خروجی به‌صورت ساختاریافته (JSON یا TXT) ذخیره شود. 8. زبان اصلی محتوا و پاسخ‌ها: فارسی (با حفظ اصطلاحات تخصصی لاتین در صورت نیاز). ## ۳. محدودیت‌های واقعی محیط هدف (که باید در هر پیشنهاد لحاظ شود) - سیستم‌های مقصد ممکن است **بدون دسترسی Admin** و با Execution Policy یا آنتی‌ویروس سخت‌گیرانه باشند. - اپراتور نهایی (در مرکز آموزشی) لزوماً فرد فنی نیست — راه‌اندازی باید حداکثر «یک کلیک» باشد. - کیفیت اسکن ورودی‌ها ممکن است پایین باشد (دوربین موبایل، نور نامناسب). - فلش ممکن است روی سیستم‌های مختلف با حرف درایو متفاوت (D:, E:, F:, …) استفاده شود. --- ## ۴. پیشنهادهایی که تاکنون از دو AI متفاوت دریافت شده ### رویکرد A | بخش | انتخاب | |---|---| | موتور اجرا | **llamafile** (باینری مستقل ساخته‌شده روی llama.cpp + Cosmopolitan Libc؛ بدون وابستگی خارجی، بدون نیاز به Visual C++ Redistributable) | | مدل | Qwen2.5-1.5B-Instruct، GGUF، Q4_K_M (~۱ گیگابایت) | | OCR | Tesseract portable با بسته‌ی زبان `fas+eng` | | اتوماسیون | PowerShell + `FileSystemWatcher` روی پوشه‌ی `input\` | | ساختار خروجی | تولید آزاد توسط مدل → parse در سمت PowerShell با try/catch (بدون اجبار schema در سمت مدل) | | کاهش hallucination | محدود کردن system prompt به «فقط از متن ورودی استفاده کن» | | **نقطه‌ی قوت اصلی** | صفر وابستگی نصب‌نشده روی سیستم میزبان (ریسک کمتر برای الزام #۱) | | **نقطه‌ی ضعف اصلی** | برای هر مدل باید فایل llamafile جداگانه ساخته شود (swap بین مدل‌ها سخت‌تر)؛ کنترل ریزتنظیمات کمتر از باینری خام | ### رویکرد B | بخش | انتخاب | |---|---| | موتور اجرا | **llama-server.exe** (باینری prebuilt رسمی llama.cpp برای ویندوز) | | مدل | Qwen3-1.7B-Instruct Q4_K_M (~۱.۱ گیگابایت) به‌عنوان پیش‌فرض، + Gemma 3 1B-it Q4_K_M (~۰.۸ گیگابایت) به‌عنوان حالت «سیستم ضعیف» | | OCR | Tesseract portable (`--oem 1`) + پیش‌پردازش تصویر با ImageMagick (deskew, despeckle, threshold, 300 DPI) + پشتیبانی PDF از طریق Poppler | | اتوماسیون | PowerShell + حلقه‌ی polling دوثانیه‌ای (به‌جای FileSystemWatcher، به دلیل نگرانی از عدم قابلیت‌اطمینان روی درایوهای قابل‌جابجایی) | | ساختار خروجی | اجبار schema در سمت مدل با `response_format: json_schema` (grammar-constrained decoding) | | کاهش hallucination | همان محدودسازی به متن منبع + نقشه‌ی راه صریح برای افزودن RAG (embedding محلی + SQLite) در فاز بعد | | بهینه‌سازی‌های اضافه | `--no-mmap` (جلوگیری از page fault هنگام خواندن مدل از USB)، تعداد thread بر اساس هسته‌ی فیزیکی (نه منطقی)، `--cache-type-k/v q8_0`، `cache_prompt: true` برای کش کردن system prompt | | **نقطه‌ی قوت اصلی** | کنترل ریزتنظیمات بیشتر، swap آسان بین دو مدل، خروجی JSON با تضمین ساختاری قوی‌تر، جزئیات بهینه‌سازی حافظه/سرعت دقیق‌تر | | **نقطه‌ی ضعف اصلی** | باینری‌های prebuilt ویندوزی llama.cpp در برخی موارد مستندشده به **Visual C++ Redistributable** نیاز دارند که ممکن است روی سیستم مقصد نصب نباشد — ریسک مستقیم برای الزام #۱ که باید قبل از commit شدن، روی یک ویندوز «تمیز» تست شود | ### نقاط توافق دو رویکرد - هر دو، llama.cpp (مستقیم یا از طریق llamafile) را به Ollama ترجیح می‌دهند، چون Ollama سرویس نصب می‌کند. - هر دو از Tesseract با بسته‌ی زبان فارسی (`fas`) به‌عنوان OCR اصلی استفاده می‌کنند. - هر دو تأکید می‌کنند مدل‌های زیر ۲ میلیارد پارامتر در فارسی افت کیفیت محسوس دارند و باید مدل را مقید به «فقط از متن منبع» کرد. - هر دو `--host 127.0.0.1` (فقط loopback) را برای تضمین آفلاین‌بودن پیشنهاد می‌دهند. - هر دو `max_tokens` کوتاه و `--ctx-size` محدود را کلیدی‌ترین اهرم رسیدن به هدف «زیر ۵ ثانیه» می‌دانند، و هر دو صادقانه اشاره کرده‌اند که رسیدن قطعی به عدد «زیر ۵ ثانیه» روی CPU خالص با این کلاس سخت‌افزار تضمین‌شده نیست، مگر با محدود کردن شدید طول پاسخ یا استفاده از streaming. --- ## ۵. سؤالات باز و نقاط تصمیم‌گیری (نیازمند نظر تخصصی) این‌ها دقیقاً همان مواردی هستند که پاسخ قطعی و اجماعی هنوز ندارند: 1. **انتخاب موتور نهایی:** با توجه به تضاد بین «کنترل ریزتنظیمات + سوییچ آسان بین مدل‌ها» (llama-server.exe خام) در برابر «تضمین صفر-وابستگی روی سیستم میزبان» (llamafile)، کدام برای این سناریوی خاص (سیستم‌های آموزشی متنوع و اغلب بدون Admin) ریسک کمتری دارد؟ آیا راهی برای گرفتن مزایای هر دو وجود دارد (مثلاً bundle کردن VC++ Redistributable به‌صورت portable در کنار llama-server.exe)؟ 2. **انتخاب مدل نهایی:** بین Qwen2.5-1.5B-Instruct، Qwen3-1.7B-Instruct، و Gemma 3 1B-it، کدام برای ترکیب «کیفیت فارسی + سرعت روی CPU خالص Core i5 + حجم زیر ۲ گیگ» بهینه‌ترین انتخاب است؟ آیا نگه‌داشتن دو مدل (یکی پیش‌فرض، یکی برای سیستم‌های ضعیف‌تر) ارزش پیچیدگی اضافه را دارد؟ 3. **مکانیزم تشخیص فایل جدید:** `FileSystemWatcher` (event-driven، ولی گزارش‌شده که روی برخی درایوهای قابل‌جابجایی/شبکه‌ای می‌تواند رویداد را از دست بدهد) در برابر polling دوثانیه‌ای (ساده‌تر و قابل‌پیش‌بینی‌تر، ولی با overhead دائمی و تأخیر کوچک) — کدام برای یک ابزار میدانی با اپراتور غیرفنی مناسب‌تر است؟ 4. **تضمین خروجی ساختاریافته:** آیا اجبار schema در سمت مدل (`response_format: json_schema`، که در برخی نسخه‌های llama.cpp گزارش باگ «شکست خاموش» داشته) باید اصل قرار گیرد، یا روش امن‌تر این است که فقط از پرامپت + parse بعدی با fallback استفاده شود؟ یا باید هر دو را هم‌زمان به‌کار برد؟ 5. **معماری کاهش hallucination:** آیا در همین فاز PoC باید RAG سبک (embedding محلی + جست‌وجوی برداری روی متن منبع) پیاده‌سازی شود، یا محدودسازی prompt-level («فقط از متن ورودی استفاده کن») برای یک نمونه‌ی اولیه کافی است و RAG به فاز بعد موکول شود؟ 6. **سازگاری با سیستم‌های قفل‌شده:** چه ترکیبی از اقدامات (`Unblock-File`، اجرای بدون Admin، دور زدن Execution Policy فقط در سطح پروسه، فرمت exFAT به‌جای FAT32/NTFS) بیشترین اطمینان را می‌دهد که ابزار روی طیف وسیعی از سیستم‌های آموزشی واقعی (نه فقط دستگاه توسعه) بدون شکست اجرا شود؟ 7. **بودجه‌بندی واقع‌بینانه‌ی زمان پاسخ:** با فرض سرعت decode حدود ۸ تا ۴۰ توکن بر ثانیه (بسته به مدل) روی CPU خالص Core i5، چه ترکیبی از `max_tokens`، طول system prompt، و streaming واقعاً «حس پاسخ زیر ۵ ثانیه» را برای کاربر نهایی تضمین می‌کند — بدون فدا کردن بیش‌ازحد کیفیت آموزشی پاسخ؟ --- ## ۶. درخواست نهایی از مدل با توجه به تمام موارد بالا (هدف، الزامات فنی، محدودیت‌های محیط واقعی، دو رویکرد پیشنهادی موجود، و نقاط توافق/اختلاف مشخص‌شده در بخش ۵)، لطفاً: - برای هر یک از ۷ سؤال باز در بخش ۵، یک توصیه‌ی مشخص و مستدل بده (نه فقط مرور گزینه‌ها). - در صورت وجود، منابع یا مستندات فنی معتبر برای ادعاهای کلیدی (به‌خصوص ریسک‌های سازگاری روی ویندوز و رفتار واقعی llama.cpp server) ذکر کن. - در پایان، یک معماری نهایی یکپارچه (ترکیب بهترین انتخاب‌ها) به‌همراه توجیه فنی کوتاه برای هر انتخاب ارائه بده.