«نیاز به تست‌های واحد»؛ راهکار افزایش دقت مدل‌های زبانی در توابع پیچیده

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

به گزارش وب‌سایت dev.to در ۱۱ اکتبر ۲۰۲۶، یک توسعه‌دهنده در حین مستندسازی یک کتابخانه قدیمی پایتون متوجه شد که دستورات استاندارد برای مدل‌های gpt-3.5-turbo و gpt-4 عملاً شکست می‌خورند. مدل‌ها به‌جای توضیح منطق کد، صرفاً نام توابع را با کلمات متفاوت بازنویسی می‌کردند و خروجی‌هایی تولید می‌کردند که هیچ ارزش افزوده‌ای برای برنامه‌نویس نداشت.

نوشتن مستندات معمولاً برای برنامه‌نویسان خسته‌کننده است و منجر به تلهٔ رایج «منِ آینده این کار را انجام می‌دهد» می‌شود. در این مورد خاص، توسعه‌دهنده با مخزنی از توابع کاربردی (Utility Functions) روبرو بود؛ قطعه‌کدهای کوچک و پرکاربردی که طی چندین ماه به‌سرعت نوشته شده و عمدتاً بدون مستندات رها شده بودند. هدف این بود که توابع پیچیده‌ای، مانند process_complex_csv_data(filepath, schema_config, output_dir)، بدون نیاز به غوطه‌ور شدن در کدهای داخلی در هر بار استفاده، به‌طور کامل قابل فهم شوند.

وقتی از هوش مصنوعی برای پر کردن این شکاف استفاده می‌کنیم، مدل معمولاً «پرت‌وپلاهای کلی» (Generic Fluff) تولید می‌کند؛ توصیفاتی که صرفاً بیان می‌کنند تابع چه کاری انجام می‌دهد، اما هرگز توضیح نمی‌دهند که تابع چگونه با داده‌های خاص یا حالت‌های لبه (Edge Cases) برخورد می‌کند. این وضعیت یک چرخه منفی در بهره‌وری ایجاد می‌کند: زمانی که صرف بازبینی و اصلاح خروجی مدل، از زمانی که برای نوشتن مستندات از صفر لازم است، بیشتر می‌شود. این چالش با پدیده‌ی «AI Slop» یا محتوای بی‌کیفیت تولید شده توسط هوش مصنوعی همسو است که در تحلیل‌های ما درباره‌ی بازسازی تجربه جست‌وجوی کاربر به تأثیرات آن بر دسترسی به اطلاعات دقیق پرداخته‌ایم.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مهندسی پرامپت اشاره کردیم، مدل‌های زبانی بدون بستر (Context) دقیق، تمایل به حدس زدن دارند.

شکست دستورات کلی

تلاش‌های اولیه با دستوراتی ساده مثل «یک docstring به سبک گوگل تولید کن»، خروجی‌هایی داشت که از نظر فنی درست اما از نظر کاربردی بی‌فایده بودند. توسعه‌دهنده برای تست این پرامپت‌ها از محیط Playground شرکت OpenAI و اسکریپت‌های مختلف استفاده کرد.

برای تابعی که طراحی شده بود تا رشته‌ها را برای جست‌وجو نرمال کند — و از Type Hintهای پایتون ۳.۹ به بالا و ماژول re استفاده می‌کرد — مدل صرفاً نوشت: «این تابع رشته را برای اهداف جست‌وجو نرمال می‌کند». کد مورد نظر به شرح زیر بود:

import re
def normalize_string_for_search(text: str, lower_case: bool = True, strip_punct: bool = True) -> str:
    if lower_case:
        text = text.lower()
    if strip_punct:
        text = re.sub(r'[^\w\s]', '', text)
    return text

این رویکرد شکست خورد زیرا مدل نمی‌توانست قصد برنامه‌نویس یا تأثیر دقیق کد را فراتر از نحو (Syntax) سطحی آن استنباط کند. مدل توضیح نداد که چه نوع علائم نگارشی حذف می‌شوند یا خروجی برای رشته‌ای مانند "Hello, World!" با تنظیمات پیش‌فرض چه خواهد بود. حتی ارتقا به gpt-4 تنها بهبودهای جزئی ایجاد کرد، زیرا مدل همچنان در ارائه مثال‌های کاربردی یا شناسایی حالت‌های لبه بدون راهنمایی خارجی ناتوان بود. توسعه‌دهنده چهار ساعت را طی دو شب با امتحان کردن ترکیباتی مثل «دقیق‌تر باش!» و «مثل یک انسان فکر کن!» تلف کرد، اما نتیجه‌ای نگرفت.

جهش با رویکرد مثال‌محور

راهکار زمانی پیدا شد که با هوش مصنوعی مانند یک برنامه‌نویس جونیور برخورد شد که به تعریف دقیقی از «موفقیت» نیاز دارد. استراتژی تغییر کرد به ارائه مثال‌های عینی از رفتار مورد انتظار؛ در واقع ایجاد «تست‌های واحد برای مستندات».

با استفاده از مدل gpt-4-0125-preview از طریق API (نسخه ۲۰۲۴-۰۵-۱۵)، ساختار جدید پرامپت شامل موارد زیر شد:

• تعریف نقش (Persona): «تو یک توسعه‌دهنده خبره پایتون هستی که وظیفه نوشتن docstringهای جامع به سبک گوگل را دارد».
• الزامات سخت‌گیرانه: رعایت فرمت گوگل، توضیح دقیق پارامترها، مقادیر بازگشتی و ارائه حداقل دو مثال کاربردی متمایز که رفتار تابع و حالت‌های لبه را نشان دهد.
• جفت‌های داده‌ای عینی: لیست کردن صریح ورودی‌ها و خروجی‌های مورد انتظار برای آموزش مدل درباره رفتار تابع:
  • text="Hello, World!", lower_case=True, strip_punct=True $\rightarrow$ "hello world"
  • text="AI & ML rocks!", lower_case=False, strip_punct=True $\rightarrow$ "AI ML rocks"
  • text="What's up, Doc?", lower_case=True, strip_punct=False $\rightarrow$ "what's up, doc?"

طبق اعلام نویسنده در dev.to، این روش کارایی مستندات تولید شده را از حدود ۳۰٪ به ۸۵٪ رساند. خروجی‌ها اکنون دقیق بودند و مثلاً حذف علائم نگارشی را به‌صورت «کاراکترهای غیر الفبایی و غیر فضای خالی» توصیف می‌کردند و شامل مثال‌های قابل اجرا با علامت >>> بودند.

تغییر پارادایم تعامل با مدل

این تجربه ثابت می‌کند که مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — یک مولد جادویی نیست، بلکه ابزاری است که خروجی‌اش توسط بستر ارائه شده محدود می‌شود. برای توابع پیچیده، مدل نمی‌تواند «چرایی» پشت کد را حدس بزند؛ این موضوع باید به او گفته شود.

برای یک توسعه‌دهنده، این یعنی مرحله‌ی پرامپت‌نویسی در واقع یک مرحله‌ی «آموزش» است. با سرمایه‌گذاری اندک در ابتدا برای تعریف چند مثال کلیدی، بخش سختِ پیش‌نویس مستندات به‌طور کامل خودکار می‌شود. توسعه‌دهنده دریافت که اگرچه برای توابع بسیار پیچیده هنوز نیاز به اصلاحات دستی جزئی است، اما حجم اصلی کار توسط مدل مدیریت می‌شود.

این رویکرد، مدل را از یک نویسنده ناقص و خودمختار به یک کمک‌خلبان (Co-pilot) بسیار مؤثر تبدیل می‌کند. این کار بار بازبینی دستی را کاهش داده و تضمین می‌کند که کدهای قدیمی و به‌هم‌ریخته — مانند فایل utils.py ذکر شده در گزارش — سرانجام مستنداتی را که نیاز دارند دریافت کنند، بدون اینکه نیاز به هفته‌ها کار دستی باشد.

برای پیاده‌سازی این روش، توسعه‌دهندگان باید از درخواست «نوشتن یک docstring» دست بردارند و به‌جای آن بخواهند که مدل «این رفتارهای خاص را در یک docstring بگنجاند».

گام بعدی شما

• به‌جای درخواست «نوشتن مستندات»، لیستی از ۳ مورد ورودی و خروجی (Input/Output) را به پرامپت اضافه کنید.
• از مدل بخواهید برای هر تابع، یک «حالت لبه» (Edge Case) را شناسایی و در مستندات ذکر کند.
• پرامپت‌های خود را با تعریف یک نقش تخصصی (Expert Persona) بازنویسی کنید.

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