فراتر از سریع: آنچه توصیه های LLM Google کاملاً به شما نمی گوید

نویسنده (ها): مایانک بوهرا

در ابتدا منتشر شده در به سمت هوش مصنوعیبشر

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

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

اما بیایید عملگرا باشیم. این ایده که چند ترفند سریع به طرز جادویی “10x” نتایج شما را برای هر کار بازاریابی می کند ، بازاریابی اعتیاد به مواد مخدره است ، نه واقعیت مهندسی. این مدل ها ، برای تمام قابلیت های آنها ، اساساً ماشینهای تطبیق الگوی هستند که در یک فضای احتمالی کار می کنند. آنها به روشی که انسان انجام می دهد درک نمی کنند. درخواست در مورد برهنه کردن این الگوی نزدیکتر به نتیجه مورد نظر است.

بنابراین ، توصیه های Google چه چیزی را پوشش داده است ، و چه چیزی Builder Builder در مورد آن است؟ این تکنیک ها به طور کلی به اصولی که مدتی می شناسیم جوش می خورد: وضوح ، ساختار ، ارائه نمونه ها و تکرار.

اصول: وضوح ، ساختار ، زمینه

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

• خاص و دقیق بودن: این یک راز نیست ؛ این فقط ارتباط خوبی است. اگر از “اطلاعات مربوط به AI” بخواهید ، چیزی عمومی دریافت خواهید کرد. اگر می خواهید “خلاصه ای از پیشرفت های اخیر در معماری مدل AI تولیدی که از آوریل 2025 در مقالات تحقیقاتی منتشر شده است ، با تمرکز بر روی مدل های MOE” ، به این مدل هدف بسیار بهتری ارائه می دهید.
• تعریف قالب خروجی: مدل ها ژنراتور متن انعطاف پذیر هستند. اگر ساختار را مشخص نکنید (JSON ، نقاط گلوله ، یک قالب پاراگراف خاص) ، هر آنچه را که از نظر آماری محتمل است بر اساس داده های آموزش، که اغلب متناقض است. گفتن مدل “پاسخ در قالب JSON با کلیدها” خلاصه “و” key_findings “جادویی نیست. این الزامات واضح است.
• زمینه ارائه: مدل ها دارای ویندوز زمینه محدود هستند. نشان دادن کل پایگاه کد یا کلیه مستندات کاربر در آن کار نخواهد کرد. شما باید اطلاعات مربوطه را به دست آورید. این اصل کل پایه و اساس نسل تقویت شده بازیابی (RAG) است ، جایی که بخش های مربوطه را بازیابی می کنید و سپس آنها را به عنوان زمینه ای برای سریع ارائه می دهید. به تنهایی بدون دانش خارجی مربوطه فقط از داخلی مدل استفاده می کند داده های آموزش، که ممکن است برای کارهای خاص دامنه منسوخ یا کافی نباشد.

این نکات بنیادی است. آنها کمتر در مورد کشف رفتارهای مدل پنهان و بیشتر در مورد کاهش ابهام ذاتی زبان طبیعی و عدم وجود درک واقعی مدل.

ساخت مکالمه: نقش ها و تعیین کننده ها

اختصاص یک نقش (“به عنوان یک مورخ متخصص …”) یا استفاده از محدود کننده ها (مانند “یا – – -) روشهای ساده اما مؤثر برای هدایت رفتار مدل و دستورالعمل های جداگانه از ورودی هستند.

• اختصاص نقش: این یک ترفند برای تولید مدل برای تولید متن سازگار با شخصیت خاص یا حوزه دانش است که در طول آموزش آموخته است. این واقعیت را به وجود می آورد که این مدل نمونه های بی شماری از سبک های مختلف نوشتن و بیان دانش را دیده است. این کار می کند ، اما این یک اکتشافی است ، نه ضمانت دقت واقعی یا پیروی کامل به نقش.
• با استفاده از محدود کننده ها: ضروری برای ارسال برنامه نویسی. هنگامی که شما در حال ساختن برنامه ای هستید که ورودی کاربر را به یک فوریت تغذیه می کند ، باید از تعیین کننده (به عنوان مثال ، سه گانه پشتی ، برچسب های XML) استفاده کنید تا به وضوح ورودی بالقوه کاربر را از دستورالعمل های سیستم خود جدا کنید. این یک اقدام مهم امنیتی در برابر حملات تزریق سریع است ، نه فقط یک نکته قالب بندی.

برهنه کردن استدلال مدل: چند عکس و گام به گام

برخی از تکنیک ها فراتر از ساخت ورودی است. آنها تلاش می کنند تا بر پردازش داخلی مدل تأثیر بگذارند.

• چند عکس شات: ارائه چند نمونه از جفت های ورودی/خروجی (“ورودی x → خروجی Y” ، ورودی → خروجی B ، ورودی C →؟) اگر اغلب بسیار مؤثرتر از توصیف کار است. چرا؟ زیرا مدل نقشه برداری مورد نظر را از مثالها می آموزد. این دوباره به رسمیت شناختن الگوی است. این برای آموزش قالب های خاص یا تفسیر دستورالعمل های ظریف است که توصیف کاملاً کلامی است. این اساساً یادگیری درون متن است.
• شکستن وظایف پیچیده: درخواست از این مدل برای فکر کردن گام به گام (یا تکنیک های اجرای مانند زنجیره ای از فکر یا فکر کردن در خارج از مدل) آن را ترغیب می کند تا مراحل واسطه ای را نشان دهد. این اغلب منجر به نتایج نهایی دقیق تر ، به ویژه برای کارهای استدلال سنگین می شود. چرا؟ این تقلید از انسان HWO مشکلات را حل می کند و مدل را مجبور می کند مراحل محاسباتی را به صورت متوالی تخصیص دهد. این کمتر در مورد یک دستورالعمل مخفی و بیشتر در مورد هدایت مدل از طریق یک فرآیند چند مرحله ای به جای اینکه انتظار داشته باشد که به یک پاسخ بپردازد.

زاویه مهندسی: آزمایش و تکرار

این توصیه همچنین شامل آزمایش و تکرار است. باز هم ، این منحصر به فرد برای مهندسی سریع نیست. این برای همه توسعه نرم افزار اساسی است.

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

حقیقت سخت: جایی که مهندسی سریع به یک دیوار برخورد می کند

در اینجا جایی است که نمای عملی واقعاً شروع به کار می کند.

1. محدودیت پنجره زمینه: فقط اطلاعات زیادی وجود دارد که می توانید در یک فوریت قرار دهید. اسناد طولانی ، تاریخچه های پیچیده یا مجموعه داده های بزرگ خارج است. به همین دلیل سیستم های RAG ضروری هستند – آنها زمینه مربوطه را به صورت پویا مدیریت و بازیابی می کنند. به تنهایی باعث نمی شود که دانش تنگنا را حل کند.
2. دقت و توهم واقعی: هیچ مقدار درخواست نمی تواند تضمین کند که یک مدل حقایق را اختراع نمی کند و یا با اطمینان اطلاعات نادرست را ارائه نمی دهد. برای مثال ، می تواند گاهی اوقات این مسئله را کاهش دهد ، برای مثال ، به مدل می گوید فقط به متن ارائه شده (RAG) بچسبد ، اما مسئله اساسی را برطرف نمی کند که مدل پیش بینی کننده متن است ، نه یک موتور حقیقت.
3. تعصب مدل و رفتار ناخواسته: اعلان ها می توانند بر بازده تأثیر بگذارند ، اما آنها به راحتی نمی توانند تعصبات تعبیه شده در داده های آموزش را نادیده بگیرند یا از ایجاد محتوای مضر یا نامناسب به روش های غیر منتظره جلوگیری کنند. GuardRails باید * در خارج از لایه سریع اجرا شود.
4. سقف پیچیدگی: برای فرآیندهای واقعاً پیچیده ، چند مرحله ای که نیاز به استفاده از ابزار خارجی ، تصمیم گیری و وضعیت پویا دارند ، فرکانس های خالص تجزیه می شوند. این دامنه عوامل AI است که از LLM ها به عنوان کنترلر استفاده می کنند اما برای دستیابی به اهداف به حافظه خارجی ، ماژول های برنامه ریزی و تعامل ابزار متکی هستند. درخواست فقط یک قسمت از حلقه عامل است.
5. قابلیت حفظ: در یک برنامه بزرگ ، ده ها یا صدها مورد پیچیده و چند خط پیچیده را در بین ویژگی های مختلف مدیریت کنید. نسخه آنها؟ آزمایش تغییرات؟ این به سرعت به یک کابوس مهندسی تبدیل می شود. دستورالعمل ها کد هستند ، اما غالباً بدون مستند و کد غیرقابل تحمل در رشته ها زندگی می کنند.
6. تزریق سریع: همانطور که با محدود کننده ها ذکر شد ، اجازه ورود خارجی (از کاربران ، بانکهای اطلاعاتی ، API) را به صورت سریع در را برای حملات تزریق سریع باز می کند ، جایی که ورودی مخرب دستورالعمل های مدل را ربوده می کند. برنامه های قوی نیاز به ضد عفونی و محافظت از معماری فراتر از یک ترفند تعیین کننده دارند.

آنچه در مقالات سریع “اسرار” به شما نمی گوید این است که دشواری با قابلیت اطمینان و پیچیدگی مورد نیاز ، به طور غیر خطی مقیاس می شود. دریافت یک خروجی نسخه ی نمایشی جالب با یک فوریت هوشمندانه یک چیز است. ساختن یک ویژگی که به طور مداوم برای هزاران کاربر در ورودی های متنوع کار می کند در حالی که امنیت و نگهداری می شود؟ این یک بازی کاملاً متفاوت است.

“راز” واقعی؟ این فقط مهندسی خوبی است.

اگر “راز” برای ایجاد برنامه های کاربردی مؤثر با LLM وجود دارد ، این یک رشته سریع نیست. این مدل را در یک سیستم به خوبی معماری ادغام می کند.

این شامل:

• خط لوله داده: دریافت داده های مناسب به مدل (برای پارچه ، تنظیم دقیق و غیره).
• چارچوب های ارکستراسیون: استفاده از ابزارهایی مانند Langchain ، Llamaindex یا ایجاد گردش کار سفارشی برای توالی تماس های مدل ، استفاده از ابزار و بازیابی داده ها.
• ارزیابی: توسعه روشهای قوی برای اندازه گیری کمی کیفیت خروجی LLM فراتر از آن که فقط آن را به چشم می اندازد. این سخت است
• GuardRails: اجرای بررسی های ایمنی ، اعتدال و اعتبارسنجی ورودی * در خارج از * خود LLM تماس می گیرد.
• مکانیسم های بازگشت: چه اتفاقی می افتد که مدل جواب بد می دهد یا شکست می خورد؟ برنامه شما نیاز به تخریب برازنده دارد.
• کنترل و آزمایش نسخه: درمان و منطق اطراف با همان سخت گیری مانند هر کد تولید دیگر.

مهندسی سریع یک مهارت مهم *، بخشی از ابزار کلی است. این مانند دانستن نحوه نوشتن نمایش داده های مؤثر SQL است. برای تعامل پایگاه داده ضروری است ، اما این بدان معنا نیست که می توانید یک برنامه وب مقیاس پذیر فقط با SQL بسازید. شما به کد برنامه ، زیرساخت ها ، جبهه و غیره نیاز دارید.

پیچیدن

بنابراین ، کاغذ سفید و منابع مشابه Google بهترین شیوه های ارزشمند را برای تعامل با LLMS ارائه می دهد. آنها رویکردهای عقل سلیم را برای ارتباطات و رفتارهای مدل مشاهده شده مانند یادگیری چند شات و پردازش گام به گام رسمی می کنند. اگر تازه شروع به کار کرده اید ، یا از LLMS برای کارهای ساده استفاده می کنید ، تسلط بر این تکنیک ها نتایج شما را کاملاً بهبود می بخشد.

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

در یافتن رشته فوری مناسب تثبیت نشوید. روی ساخت یک سیستم مقاوم در اطراف آن تمرکز کنید. اینجاست که پیشرفت واقعی اتفاق می افتد.

منتشر شده از طریق به سمت هوش مصنوعی