LLM یک راه پایدارتر برای نوشتن کد، نوشتن DSL است

چند وقت پیش، من بارها و بارها همین وضعیت را دیدم: پرتاب نیازها به طور مستقیم به مدل، سرعت تولید بسیار سریع است، و دوباره کاری نیز سریع است. ابتدا الزامات را در یک لایه DSL قرار دهید، و سپس اجازه دهید مدل پیاده سازی را در اطراف این لایه مدل معنایی بنویسد، و خروجی به وضوح پایدار است. تغییر بسیار مستقیم است. نکته کلیدی این نیست که آیا می توان مدل را نوشت یا نه، بلکه مهم این است که آیا ابتدا فضای اختیاری بسته شده است.

زبان طبیعی برای گفتن مسیرها مناسب است، اما برای حمل تصمیمات ضمنی زیاد مناسب نیست. یک نیاز به ظاهر ساده در هنگام اجرا به قضاوت‌های کوچک زیادی تقسیم می‌شود: نحوه نام‌گذاری وضعیت، اینکه آیا شکست کامل شده در نظر گرفته می‌شود، چند بار برای تلاش مجدد، منطقه زمانی که پنجره زمانی بر اساس کدام منطقه است، و گزارش روی کدام لایه نوشته شده است. تا زمانی که این قضاوت ها هنوز در فرآیند تولید پنهان هستند، مدل جزئیات را پر می کند و مرزها را هم زمان تغییر می دهد. مطلب نوشته شده نهایی قابل اجرا است، اما بررسی آن دشوار است.

زبان طبیعی فقط برای صحبت در مورد مشکلات مناسب است

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

به همین دلیل است که کلمات طولانی اغلب هر چه بیشتر بنویسید خسته کننده تر می شوند. بعد از اینکه کلمه اعلان طولانی شد، مدل همچنان یک متن آزاد دریافت می کند، اما متن آزاد طولانی تر است. زمینه بیشتری را بدون بدست آوردن مرزهای بیشتر به خاطر می آورد. اگر مرز بسته نباشد، مدل فقط می تواند به حدس زدن ادامه دهد.

DSL قضاوت ضمنی را به ورودی صریح تبدیل می کند

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

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

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

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

LLM برای مشارکت در رشد DSL مناسب است

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

در این مرحله، LLM کاملا مفید است. این می تواند به تراز کردن عبارات پراکنده در مجموعه ای از اصطلاحات کمک کند، و همچنین می تواند مشکلاتی مانند ناسازگاری های نامگذاری، شکاف های وضعیت، و از دست دادن مسیرهای غیرعادی را در مرحله پیش نویس شناسایی کند. پس از پایداری مدل معنایی، مدل پیاده‌سازی‌ها، نمودارهای شماتیک و نمونه‌های آزمایشی را تولید می‌کند. خروجی بیشتر شبیه دویدن در مسیر خواهد بود و هر بار به مکان های دیگر نمی چرخد.

من ترجیح می دهم LLM را پشت DSL قرار دهم. ابتدا مرزها را مشخص کنید و سپس اجازه دهید بعداً به پر کردن مرزها کمک کنند تا سیستم به راحتی با بداهه گویی بارها و بارها منحرف نشود.

لایه معنایی نیز ناکارآمد خواهد شد

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

بنابراین، قضاوت عملی تر این نیست که “آیا LLM می تواند به DSL مجهز شود؟” اما «آیا ابتدا باید معناشناسی این موضوع را اصلاح کرد؟» هنگامی که پاسخ مثبت است، کلمه نشانه دیگر نباید مسئولیت کامل را داشته باشد. Prompt مسئول توضیح قصد است، DSL مسئول حمل محدودیت ها، و مدل مسئول تبدیل محدودیت ها به نتایج اجرایی است. آنچه به این شکل نوشته شده است بیشتر شبیه یک نظام مهندسی است تا یک سری بداهه پردازی.