ویرگول
ورودثبت نام
صابر طباطبائی یزدی
صابر طباطبائی یزدیبرنامه نویس۴۴ساله. از مدرک MCSD دات نت سال 2002 شروع کردم البته بعد از لیسانس و تمام عمرم رو در مدیریت با ابزار های شیرپوینت و MSPS و CRM و غیره گذراندم. https://zil.ink/sabert
صابر طباطبائی یزدی
صابر طباطبائی یزدی
خواندن ۴ دقیقه·۸ روز پیش

دوره هوش مصنوعی آنتروپیک آوردم براتون. +ویدیو +پادکست +اینفوگرافیک

۵ درس غافلگیرکننده از دوره‌های تخصصی Anthropic برای تسلط بر Claude

به عنوان یک متخصص ارشد مهندسی پرامپت، بارها دیده‌ام که توسعه‌دهندگان تفاوت بین یک پاسخ «خوب» و یک پاسخ «بی‌نقص» را به شانس یا جادوی مدل نسبت می‌دهند. اما حقیقت این است که کار با مدل‌های زبانی بزرگ (LLM) بیش از آنکه هنر باشد، یک علم تجربی، تکرارپذیر و مبتنی بر ارزیابی (Evaluation) است.

در این مقاله، ۵ درس استراتژیک را که از دل منابع آموزشی پیشرفته Anthropic استخراج کرده‌ام، تحلیل خواهیم کرد. این درس‌ها نگاه شما را از «نوشتن یک متن ساده» به سمت «مهندسی یک سیستم هوشمند» تغییر می‌دهند.

--------------------------------------------------------------------------------

۱. جادوی تکرار؛ وقتی Few-shot بر بن‌بست Multi-label غلبه می‌کند

در یکی از پروژه‌های طبقه‌بندی شکایات (Classification Task)، یک پرامپت اولیه با دستورالعمل‌های ساده به دقت ۸۵٪ رسید. در نگاه اول این عدد قابل قبول است، اما تحلیل مهندسی نشان داد که مدل در سناریوهای Multi-label (برچسب‌های چندگانه) شکست می‌خورد.

به عنوان مثال، وقتی کاربر می‌گفت: «اپلیکیشن کرش می‌کند و گوشی من بیش از حد داغ شده است»، مدل Haiku به دلیل ضعف در Instruction Following بدون مثال، تنها یکی از دسته‌ها (Software Bug) را برمی‌گرداند و Hardware Malfunction را نادیده می‌گرفت. راهکار Anthropic برای رساندن دقت به ۱۰۰٪، نه توضیحات طولانی‌تر، بلکه استفاده از Few-shot prompting با ۹ مثال متنوع بود.

این فرآیند نشان‌دهنده یک اصل حیاتی است:

"We’re following the standard prompt + eval loop" یعنی مهندسی پرامپت یعنی: نوشتن، تست روی دیتاست، شناسایی الگوهای شکست و اصلاح.

۲. تگ‌های XML؛ استخوان‌بندی پنهان برای جلوگیری از تداخل

برخلاف بسیاری از مدل‌ها که با Markdown راحت‌ترند، مدل‌های خانواده Claude به طور اختصاصی برای درک ساختار XML آموزش دیده‌اند. استفاده از تگ‌هایی مانند <context> یا <instructions> صرفاً برای زیبایی نیست؛ این تگ‌ها از Instruction Overlap یا تداخل داده با دستورالعمل جلوگیری می‌کنند.

در پروژه‌های سنگین مثل «خلاصه‌ساز ترنسکریپت تماس»، قرار دادن متن مکالمه داخل تگ <transcript> به مدل می‌فهماند که محتوای این بخش نباید به عنوان دستور جدید (Instruction Injection) تلقی شود. این جداسازی فیزیکی، ظرفیت مدل را برای پردازش داده‌های حجیم و استخراج خروجی‌های ساختاریافته (مثل JSON) به شدت بالا می‌برد.

نمونه ساختار حرفه‌ای:

<instructions> Summarize the following call transcript. Return only a JSON object. </instructions> <transcript> [Call Data Here] </transcript>

۳. تفکیک «فکر کردن» از «پاسخ دادن»؛ استراتژی خروجی دو مرحله‌ای

یکی از قدرتمندترین متدولوژی‌های Anthropic، استفاده از مفهوم Chain of Thought پنهان است. ما به مدل فضایی اختصاصی می‌دهیم تا قبل از ارائه پاسخ نهایی، در تگ‌های <thinking> تحلیل خود را انجام دهد. این کار به طرز چشمگیری «توهم» (Hallucination) را کاهش می‌دهد، زیرا مدل ابتدا فرصت دارد کافی بودن اطلاعات را بسنجد.

اما نکته طلایی مهندسان ارشد در "Physical Separation" است. ما از مدل می‌خواهیم پاسخ نهایی را در تگ <answer> قرار دهد. این کار به ما اجازه می‌دهد در محیط تولید (Production)، با یک Regex ساده یا String Parsing، بخش تفکر را حذف کرده و فقط خروجی تمیز را به کاربر نهایی نشان دهیم.

"دادن فضا به مدل برای فکر کردن، به او اجازه می‌دهد قبل از رسیدن به پاسخ نهایی، جوانب مختلف مسئله را بسنجد و از ارائه اطلاعات نادرست خودداری کند."

۴. مدل علیه مدل؛ توزیع بار محاسباتی (Load Distribution)

چطور می‌توان معیارهای کیفی مثل «میزان عذرخواهی بیش از حد» یا «لحن آموزشی مناسب برای نوجوانان» را سنجید؟ کدنویسی سنتی برای این کار تقریباً غیرممکن است. اینجاست که رویکرد Model-graded Evaluation وارد می‌شود.

در این استراتژی، ما از یک مدل کوچک و سریع مثل Claude 3 Haiku برای انجام وظایف (Worker) استفاده می‌کنیم، اما یک مدل با قدرت استدلال و انتزاع بالاتر مثل Claude 3 Opus را به عنوان قاضی (Judge) قرار می‌دهیم. استفاده از ابزارهایی مثل llm-rubric به ما اجازه می‌دهد نمره‌دهی کیفی را خودکار کنیم. واقعیت این است که شکست‌های ظریف در لحن، فقط توسط یک مدل با سطح Reasoning بالاتر قابل شناسایی و اصلاح هستند.

۵. مدیریت موارد مرزی؛ INSUFFICIENT_DATA به مثابه فیلتر سیستماتیک

یک پرامپت در مقیاس تولید، باید بداند چه زمانی «نه» بگوید. Anthropic در درس‌های مربوط به مدیریت داده‌های ناقص (Insufficient Data Criteria)، تأکید می‌کند که مدل باید در برخورد با لبه‌های مرزی (Edge Cases) - مثلاً تماسی که کمتر از ۵ تبادل دارد یا کاملاً نامفهوم است - به جای حدس زدن، پاسخ یونیک INSUFFICIENT_DATA را برگرداند.

این موضوع صرفاً یک پاسخ ساده نیست، بلکه یک فیلتر سیستماتیک است. این رویکرد اجازه نمی‌دهد داده‌های نویزدار و توهمات مدل وارد پایگاه داده‌های تحلیلی (Analytics) شما شوند و کیفیت خروجی کل سیستم را در مقیاس کلان حفظ می‌کند.

--------------------------------------------------------------------------------

نتیجه‌گیری: فراتر از یک پرامپت ساده

آموزه‌های تخصصی Anthropic به ما ثابت می‌کند که مهندسی پرامپت در واقع مهندسی فرآیند و ارزیابی است. تفاوت یک متخصص ارشد با یک کاربر معمولی در این است که متخصص، پرامپت را یک موجود زنده می‌بیند که باید دائماً در چرخه "Prompt + Eval" تکامل یابد. با استفاده از ساختارهای XML، جداسازی خروجی و سیستم‌های ارزیابی مدل‌محور، ما در حال گذار از «چت کردن» به سمت «ساخت سیستم‌های هوشمند قابل اعتماد» هستیم.

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

هوش مصنوعیمهندسی پرامپت
۸
۰
صابر طباطبائی یزدی
صابر طباطبائی یزدی
برنامه نویس۴۴ساله. از مدرک MCSD دات نت سال 2002 شروع کردم البته بعد از لیسانس و تمام عمرم رو در مدیریت با ابزار های شیرپوینت و MSPS و CRM و غیره گذراندم. https://zil.ink/sabert
شاید از این پست‌ها خوشتان بیاید