پرش به محتوای اصلی
پرش به محتوای مقاله

چگونه language-mcp نیاز عامل‌های هوش مصنوعی به APIهای خارجی را حذف می‌کند؟

·۲ مهر ۱۴۰۵۷ دقیقه مطالعه۲ بازدید
راهنما
عامل هوشمند با ابزار بررسی املا MCP: اصلاح خودکار متن در گفتگوهای چندمرحله‌ای
عامل هوشمند با ابزار بررسی املا MCP: اصلاح خودکار متن در گفتگوهای چندمرحله‌ای
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

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

اگر امروز یک عامل هوش مصنوعی برای شما متنی می‌نویسد، احتمالاً در رعایت دقیق استانداردهای املایی منطقه‌ای یا راهنمای سبک (Style Guide) شرکت شما شکست می‌خورد. در ۲۴ سپتامبر ۲۰۲۶، پیاده‌سازی جدیدی به نام language-mcp نشان داد که چگونه می‌توان این تصمیمات زبانی حیاتی را از وزن‌های مدل خارج کرد و به یک ابزار محلی سپرد.

بیشتر ابزارهای نوشتاری فعلاً به احتمال داخلی مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای تشخیص درست بودن یک کلمه تکیه می‌کنند. این رویکرد باعث می‌شود انگلیسی آمریکایی و بریتانیایی با هم ترکیب شوند یا دستورالعمل‌های خاص سازمانی نادیده گرفته شوند. با استفاده از پروتکل زمینهٔ مدل (MCP)، توسعه‌دهندگان اکنون می‌توانند یک «غلط‌گیر املایی» اختصاصی به عامل‌ها بدهند که به عنوان یک مرز قابل تأیید و مجزا بین یک لغت‌نامه، یک قانون سبک و یک تصمیم تحریری عمل می‌کند.

عامل هوش مصنوعی با ابزار بررسی املا MCP: ارتقای دقت متن‌نگاری

به نقل از گزارش dev.to، معماری language-mcp یک سرور TypeScript است که حریم خصوصی و دقت را در اولویت قرار می‌دهد. این سیستم از اجرایی به نام Hunspell برای انجام بررسی‌ها روی ماشین میزبان استفاده می‌کند؛ به این معنا که متن ارسالی برای تأیید املایی، محیط محلی را برای فراخوانی یک API ترک نمی‌کند و در محیط سیستم کاربر باقی می‌ماند.

با این حال، نویسنده به یک نکته حیاتی در ساختارهای ترکیبی (Hybrid) اشاره می‌کند: در حالی که ابزار غلط‌گیر محلی است، کلاینت MCP (یعنی همان عامل) ممکن است همچنان از یک LLM میزبانی‌شده در ابر استفاده کند. در این حالت، تاریخچه گفتگو و نتایج ابزار غلط‌گیر ممکن است همچنان به ارائه‌دهنده مدل منتقل شود. این تمایز به طور مفصل در راهنمای پروژه درباره‌ی اینکه در یک ساختار هوش مصنوعی ترکیبی چه چیزهایی محلی باقی می‌مانند، شرح داده شده است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفکیک لایه‌های پردازش محلی و ابری برای حفظ حریم خصوصی داده‌های حساس ضروری است.

این سرور پنج ابزار مجزا برای نیازهای مختلف زبانی ارائه می‌دهد:

  • check_us_english_text: پاراگراف‌ها را برای غلط‌های املایی و «بریتانیسم‌ها» (فرم‌های انگلیسی بریتانیایی) اسکن می‌کند. این ابزار از دارایی‌های لغت‌نامه SCOWL/LibreOffice استفاده می‌کند.
  • validate_us_english_word: بررسی می‌کند که آیا یک تک‌کلمه با استانداردهای انگلیسی آمریکایی مطابقت دارد یا خیر.
  • check_dutch_text: بررسی املایی محلی برای زبان هلندی را با استفاده از لغت‌نامه‌های OpenTaal از مخزن Hunspell OpenTaal انجام می‌دهد.
  • validate_dutch_word: اعتبارسنجی تک‌کلمات هلندی را بر عهده دارد.
  • get_dutch_word_details: ابزاری مبتنی بر شبکه است که از سایت Woordenlijst.org استعلام می‌گیرد. این سایت توسط Instituut voor de Nederlandse Taal برای Taalunie نگهداری می‌شود و جزئیات لغوی مانند تلفظ، فرم‌های کلمه و نحوه خط تیره گذاری (hyphenation) را ارائه می‌دهد.

توسعه‌دهنده برای تضمین صحت، اجرای بومی Hunspell را به جای جایگزین‌های جاوااسکریپتی مثل nspell ترجیح داده است. اگرچه حذف وابستگی‌های بومی استقرار را ساده‌تر می‌کرد، اما نویسنده خاطرنشان کرد که تغییر در پیاده‌سازی نیازمند اثبات سازگاری رفتاری (Behavioral Compatibility) است تا دقت سیستم کاهش نیابد.

یکی از چالش‌های فنی در پروتکل لوله (Pipe) مدل -a در Hunspell است. این پروتکل تضمین نمی‌کند که برای هر توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — دقیقاً یک خط پاسخ ارسال شود. برای مثال، یک ورودی که دارای خط تیره است می‌تواند برای هر بخش یک پاسخ تولید کند و سپس یک خط جداکننده خالی ارسال کند. اگر یک Wrapper (پوشش نرم‌افزاری) صرفاً خطوط پاسخ را با کلمات ورودی جفت (Zip) کند، یک کلمه ترکیبی می‌تواند تمام نتایج بعدی را جابه‌جا کرده و باعث شود هر کلمه پاسخ اشتباهی دریافت کند.

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

  • پاسخ‌های * و + را می‌پذیرد.
  • پیشنهادات اصلاحی را از پاسخ‌های & جمع‌آوری می‌کند.
  • پاسخ‌های ناشناخته را به عنوان شکست در نظر می‌گیرد.
  • پیشنهادات تکراری را حذف کرده و حداکثر ۸ پیشنهاد برای هر توکن برمی‌گرداند.
  • زمان اجرای زیرپردازش (Subprocess) را به ۲۰ ثانیه محدود می‌کند تا از توقف سیستم جلوگیری شود.

این سیستم املای کلمات و سبک نوشتاری را به عنوان دو لایه مجزا می‌بیند. در حالی که یک لغت‌نامه ممکن است کلمه 'whilst' را به عنوان یک کلمه صحیح بپذیرد، قوانین سبک language-mcp آن را به عنوان فرم بریتانیایی علامت‌گذاری کرده و برای انگلیسی آمریکایی، کلمه 'while' را پیشنهاد می‌دهد. بررسی لغت‌نامه به تنهایی این تفاوت ظریف را تشخیص نمی‌دهد.

این قوانین سبک به صورت فهرستی استاتیک از عبارت‌های منظم (Regular Expressions) پیاده شده‌اند. این قوانین بیشتر بر ترجیحات تحریری — مانند ترجیح کلمه 'custom' بر 'bespoke' — تمرکز دارند تا اینکه بخواهند به عنوان یک تجزیه‌کننده کامل گرامری (Grammar Parser) عمل کنند. از آنجا که این قوانین ممکن است نسبت به متن بی‌تفاوت (Context-insensitive) باشند، عامل طراحی شده تا یافته‌ها را بررسی کرده و تصمیم بگیرد کدام تغییرات منطقی است، نه اینکه آن‌ها را به‌طور خودکار اعمال کند.

به عنوان مثال، کلمه 'queue' در یک مقاله برنامه‌نویسی آمریکایی کاملاً عادی است و کلمه 'lift' همیشه به معنای آسانسور نیست. به دلیل اینکه قوانین می‌توانند متنی معتبر را علامت‌گذاری کنند یا صرف‌رفتی نامناسب تولید کنند، این سیستم بیشتر به عنوان یک «قرارداد سبک» عمل می‌کند تا گواهینامه‌ای برای انگلیسی اصیل و بومی.

برای راه‌اندازی این سرور به Node.js ۲۰+، Git، npm و نصب بسته Hunspell در مسیر PATH سیستم نیاز است. برای کاربران ویندوز، نویسنده استفاده از WSL (زیرسیستم لینوکس برای ویندوز) را توصیه می‌کند. این سرور از طریق stdio ارتباط برقرار می‌کند، به این معنی که یک محیط تعاملی (Prompt) نیست، بلکه ابزاری است که بر اساس پروتکل برای یک کلاینت MCP عمل می‌کند.

برای نصب نسخه تثبیت‌شده (commit a5787562260bead2e19939db862e2aa07b78781d)، مراحل زیر لازم است:
۱. نصب Hunspell از طریق مدیریت بسته (مثلاً pacman -S hunspell در آرچ لینوکس).
۲. کلون کردن مخزن: git clone https://github.com/seppegadeyne/language-mcp.git.
۳. تغییر نسخه به کامیت مشخص شده (Checkout) برای جلوگیری از تغییرات ناگهانی در آینده.
۴. اجرای دستورات npm ci --ignore-scripts و npm test و npm run build.

در استقرار Hermes، این سرور به پیکربندی mcp_servers با زمان انتظار اتصال (connect_timeout) ۶۰ و زمان انتظار کلی (timeout) ۱۲۰ اضافه می‌شود. تست شناسایی را می‌توان با دستور hermes mcp test language انجام داد.

محدودیت‌های عملیاتی این سیستم عبارتند از:

  • محدودیت توکن: توکن‌ساز پس از ۲۰۰۰ توکن قابل بررسی متوقف می‌شود.
  • فیلتر کردن: توکن‌های تک‌کاراکتری و مخفف‌های کوتاه که تماماً با حروف بزرگ نوشته شده‌اند، نادیده گرفته می‌شوند.
  • مدیریت Markdown: توکن‌ساز املایی، URLها، ایمیل‌ها، کدهای محصور در fenced code و کدهای inline را حذف می‌کند. اما اسکنر بریتانیسم‌ها (britticism scan) متن اصلی را دریافت می‌کند؛ به این معنی که مثال‌های نقل‌شده یا شناسه‌ها ممکن است در یافته‌های سبک ظاهر شوند، حتی زمانی که بخش املایی آن‌ها را نادیده گرفته است.
  • موقعیت‌یابی: موقعیت‌های گزارش‌شده بر اساس ایندکس رشته‌های جاوااسکریپت هستند، نه شماره خط و ستون ویرایشگر. پیاده‌سازی فعلی از اولین occurrence (وقوع) توکن در رشته اصلی استفاده می‌کند.
  • محدودیت شبکه: جست‌وجوی لغوی هلندی از یک سرویس XML غیررسمی استفاده می‌کند که حداقل فاصله ۱.۲ ثانیه‌ای بین فراخوانی‌ها و حافظه موقت (Cache) ۲۴ ساعته دارد. پارسر آن اولین فیلدهای فرزند منطبق را می‌گیرد که گاهی منجر به نتایج مبهم می‌شود (مثلاً خط تیره در سطح بالا که بازتاب‌دهنده یک کلمه تصغیر شده است).

گام بعدی شما

این رویکرد فرض بنیادی در نوشتار هوش مصنوعی را تغییر می‌دهد: این که LLM نباید تنها داور صحت باشد. با سپردن املای کلمات به یک ابزار قطعی (Deterministic)، توسعه‌دهنده «توهم» صحت را کاهش می‌دهد؛ جایی که مدل اصرار دارد کلمه‌ای درست نوشته شده چون در داده‌های آموزشی‌اش رایج بوده است. با این حال، باید به خاطر داشت که پروتکل MCP به تنهایی نمی‌تواند تمام توهمات عامل‌های تجاری را حذف کند و نیاز به طراحی دقیق لایه‌های اعتبارسنجی دارد.

برای توسعه‌دهنده عملی، این یعنی عامل‌های هوش مصنوعی اکنون می‌توانند ملزم به یک «قرارداد سبک» سخت‌گیرانه باشند. به جای پرامپت دادن به مدل برای اینکه «به انگلیسی آمریکایی بنویس» — که یک پیشنهاد نرم است — عامل اکنون می‌تواند یک بررسی سخت در برابر لغت‌نامه و لیست regex اجرا کند و یک حدس احتمالی را به یک حقیقت قابل تأیید تبدیل کند. برای جلوگیری از رفتارهای پیش‌بینی نشده در این فرآیند، استفاده از پاسخ‌های منفی ماشین‌خوان در سرورهای MCP می‌تواند مانع از بداهه‌پردازی‌های خطرناک عامل شود.

برای پیاده‌سازی این الگو برای زبان‌های دیگر، توسعه‌دهندگان صرفاً باید لغت‌نامه‌های سازگار با Hunspell را فراهم کرده و ابزارهای متناظر را ثبت کنند. این فرآیند شامل موارد زیر است:
۱. تهیه لغت‌نامه Hunspell و فایل‌های affix سازگار.
۲. حفظ فایل‌های لایسنس و ارجاعات لغت‌نامه.
۳. افزودن دارایی‌ها به resolver لغت‌نامه.
۴. ثبت ابزارهای بررسی متن و اعتبارسنجی کلمه برای زبان خاص.
۵. تست کلمات معتبر، غلط‌های املایی، کلمات ترکیبی و پیشنهادات قبل از استقرار.

هسته قابل استفاده مجدد در اینجا، تفکیک مسئولیت‌هاست: لغت‌نامه املای کلمات را بررسی می‌کند، قوانین کنوانسیون‌های سبک را چک می‌کنند و عامل نهایی، بازبینی تحریری را انجام می‌دهد. اگر در حال ساخت یک گردش‌کار عاملی برای نشر حرفه‌ای هستید، باید ادغام سرورهای MCP محلی را برای مدیریت اصطلاحات تخصصی دامنه (Domain-specific) که LLMهای عمومی را به طور مداوم گمراه می‌کنند، بررسی کنید.

  • اگر در حال توسعه عامل‌های محتواساز هستید، از پروتکل MCP برای اتصال لغت‌نامه‌های تخصصی صنعت خود استفاده کنید تا نرخ توهم (Hallucination) در املای کلمات فنی کاهش یابد.
  • برای پیاده‌سازی در زبان‌های دیگر، لغت‌نامه‌های سازگار با Hunspell را تهیه کرده و ابزارهای اعتبارسنجی متناظر را در سرور ثبت کنید.
  • در گردش‌کارهای نشر حرفه‌ای، به جای تکیه بر پرامپت‌های «به انگلیسی آمریکایی بنویس»، یک لایه بررسی سخت‌افزاری/محلی را به عنوان گیت نهایی کیفیت اضافه کنید.

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

چرا این موضوع مهم است؟

این رویکرد با تکیه بر اعتبار لغت‌نامه‌های استاندارد (Authority)، خطای مدل‌های زبانی در رعایت استانداردهای زبانی را حذف می‌کند. این تغییر برای سازمان‌هایی که استانداردهای سخت‌گیرانه برند و سبک نوشتاری دارند، حیاتی است.

تأثیر برای ایران

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

·نگاه ما
تحریریه دات‌هوش

انتقال مسئولیت صحت املایی از لایه احتمالی LLM به ابزارهای قطعی (Deterministic)، پارادایم «اعتماد به مدل» را به «تأیید توسط ابزار» تغییر می‌دهد. این رویکرد نشان می‌دهد که آینده‌ی عامل‌های هوش مصنوعی نه در مدل‌های بزرگ‌تر، بلکه در معماری‌های ترکیبی است که در آن مدل نقش مدیر ارشد (Orchestrator) و ابزارهای محلی نقش متخصصان دقیق را ایفا می‌کنند.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.