تولید سرتاسری: تأیید، نظارت و اخلاق

سود:

• می تواند معماری سرتاسری را طراحی کند که ویژگی LLM را از ایده تا تولید می برد
• لایه‌هایی از اجرای راستی‌آزمایی، تأیید انسانی، و ردیابی (ورود به سیستم/سنجه‌ها) را ایجاد می‌کند.
• مرزها اصول اخلاقی و حریم خصوصی را به تصمیمات تولید تبدیل می کند

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

لایه های معماری تولید

یک مدرک تحصیلی جامد LLM تقریباً از پنج لایه تشکیل شده است:

1. لایه ورودی: داده ها را جمع آوری کنید، آن ها را تمیز کنید، مناطق حساس را بپوشانید، فقط آنچه لازم است را انتقال دهید.
2. لایه مدل: مدل صحیح (واحد 5) را انتخاب کنید، اعلان و پارامترهای سیستم را تنظیم کنید (واحد 4)، حافظه پنهان (واحد 6).
3. لایه اعتبار سنجی: در صورت لزوم خروجی را در برابر طرح و قانون، منبع و تایید انسانی بررسی کنید.
4. لایه عمل: انجام عمل با خروجی معتبر. اقدامات با تاثیر بالا را ضبط کنید.
5. لایه نظارت: هر تماس، هزینه، خطا و کیفیت را ثبت و اندازه گیری کنید.

این لایه ها یک خط لوله هستند. هر کدام خروجی قبلی را بررسی می کند.

چرا تأیید لازم است؟

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

لایه های تأیید (افزایش بر اثر ضربه):

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

احتیاط: "مدل بسیار خوب است، نیازی به تأیید بیشتر نیست" خطرناک ترین اشتباه تولید است. مهم نیست که چقدر مدل خوب است، لایه تایید یک شبکه ایمنی در تصمیم گیری های پر تاثیر است. حتی یک تصمیم اشتباه خودکار می تواند تمام زمان ذخیره شده را از بین ببرد.

انسان در حلقه

Not every decision has to be fully automatic. در رویکرد انسان در حلقه، مدل سرعت کار را افزایش می دهد و انسان آن را تایید می کند. تعادل مناسب به تاثیر تصمیم و قابلیت اطمینان مدل بر آن کار بستگی دارد.

تاثیر تصمیم

رویکرد

کم (پیشنهاد برچسب، پیش‌نویس)

اتوماسیون کامل؛ خطا ارزان و قابل برگشت است

متوسط (مسیریابی، اولویت بندی)

اتوماسیون + کنترل نمونه برداری

بالا (پول، قرارداد، سلامت، حذف)

رضایت انسان اجباری است؛ مدل فقط پیشنهاد می کند

نظارت: شما نمی توانید آنچه را که نمی بینید مدیریت کنید

در تولید، شما باید بر هر تماس نظارت داشته باشید. بدون نظارت، نمی‌توانید هزینه، کیفیت را بهبود ببخشید یا مشکل را زودتر حل کنید. معیارهای کلیدی برای ثبت:

• استفاده/هزینه: به ازای درخواست و کل توکن ها، توزیع مدل، هزینه روزانه.
• تأخیر: میانگین و بدترین زمان پاسخ.
• میزان خطا: نرخ 429/500، تلاش مجدد، رها کردن.
• کیفیت: نرخ خروجی رد شده در لایه تأیید، نرخ تصحیح در تأیید انسانی، بازخورد کاربر.

نکته: داده های حساس (اطلاعات شخصی، کلیدها) را در گزارش های نظارت ننویسید. گزارش ها را در محدوده محرمانه بودن در نظر بگیرید. در صورت لزوم با ماسک کردن ضبط کنید (واحد 9).

اخلاق و مرزها

مسئولیت اخلاقی به اندازه دقت فنی بخشی از تصمیم تولید است:

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

قالب های قابل کپی

# Validation checklist (after output generation)1) Is the schema valid? (تأیید اعتبار خروجی ساختاریافته) 2) آیا مقادیر منطقی هستند؟ (بررسی قوانین: محدوده، تاریخ، شماره) 3) آیا ادعا بر اساس منبع است؟ (اگر در سند نیست رد شود) 4) تاثیر زیاد است؟ ← ارسال برای تایید انسانی 5) اگر همه تایید شد ← اجازه اقدام، ذخیره کنید

# اعلان سیستم که نیروهای متکی به منبع فقط بر اطلاعات موجود در سند ارائه شده تکیه می کنند. چیزی که در سند نیست اضافه نکنید. اگر اطلاعاتی در سند نیست، بنویسید "در سند یافت نشد". هرگز چیزها را حدس نزنید یا درست نکنید.

# آستانه تایید انسانی (قاعده تصمیم) IF نوع_تصمیم در [پول، قرارداد، حذف، سلامت] ← تایید انسانی اجباریIF model_trust < آستانه یا اعتبارسنجی "نامشخص" → ارسال به تایید انسانی Other → اعمال خودکار + کنترل نمونه

# Trace log template (نوشتن داده‌های حساس){ "time":"..."، "model":"...، "input_token":...، "output_token":...، "delay_ms":...، "stop_reason":"...، "Authentication":" تصویب شد|رد شد|رد شد|کلیدهای انسانی: NE/شخصی_نوشته شدند،

اعلان ضعیف / اعلان قوی (قابلیت اطمینان تولید)

# ضعیف (بدون تأیید، بدون منبع، به طور خودکار اعمال می شود) این درخواست را ارزیابی کنید، تصمیم به بازپرداخت بگیرید و درخواست دهید.

# STRONG (مبتنی بر منبع، ایجاد توصیه، موکول به تایید انسانی) این درخواست بازگشت را فقط بر اساس سند سیاست بازگشت ارزیابی کنید. تصمیم را با توجیه توصیه کنید اما اجرا نکنید: {"توصیه":"تأیید|رد"، "دلیل":"..."،"بند_policy":"..."}.اگر مبنای روشنی در سند خط مشی وجود ندارد، "نامشخص" بدهید. یک نماینده تصمیم نهایی را تایید خواهد کرد.

نسخه قدرتمند؛ این تصمیم را به منبع نسبت می‌دهد، مدل را به‌عنوان «پیشنهادکننده» به جای «انجام‌دهنده» قرار می‌دهد، و گام مهم را پشت تأیید انسان قرار می‌دهد. این ماهیت قابلیت اطمینان تولید است.

سه کیف کوچک

مورد 1 - روزی که لایه تأیید ذخیره شد. یک فین‌تک از مدلی برخوردار بود که توصیفات تراکنش‌ها را طبقه‌بندی کرده و سوابق حسابداری خودکار ایجاد کند. آنها اعتبار قاعده را اضافه کردند: زمانی که مدل مقدار را به اشتباه (12500 به جای 1250 در سند) خروجی داد، قانون "مقدار با سند مطابقت ندارد" خروجی را رد کرد و رکورد به دست انسان افتاد. اگر تأییدی وجود نداشت، رکورد نادرست بی‌صدا وارد سیستم می‌شد.

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

مورد 3 - پذیرش حد. یک استارت‌آپ مراقبت‌های بهداشتی در حال برنامه‌ریزی بود تا توصیه‌های تشخیصی را کاملاً خودکار انجام دهد و آن را به بیمار نشان دهد. در یک بررسی اخلاقی و مسئولیت، آنها به این نتیجه رسیدند که این غیرمحدود است: این مدل فقط خلاصه و نکات ممکن را برای یک پزشک ارائه می‌کند، پزشک تشخیص می‌دهد. خودکار نکردن یک کار نیز یک تصمیم طراحی بالغ است.

اشتباهات رایج

• پرش از اعتبارسنجی: کورکورانه خروجی را اعمال می‌کنید و می‌گویید «مدل خوب است».
• خودکارسازی تصمیم با تأثیر بالا: تأیید انسانی در پول / سلامت / قانون ضروری است.
• عدم نظارت: مشکلات هزینه و کیفیت دیر کشف می شود.
• نوشتن داده های حساس در گزارش ها: نقض حریم خصوصی. با ماسک کردن آن را ذخیره کنید.
• تلاش نکردن برای تکیه بر منبع: مدل ممکن است چیزی را که در سند نیست ایجاد کند.
• نادیده گرفتن محدودیت ها: خودکار نکردن برخی کارها تصمیم درستی است. شفافیت و مسئولیت با شماست.

Deeper: Release Management، Rollback و Incremental Deployment

استفاده از یک ویژگی LLM در تولید به معنای راه اندازی و فراموش کردن آن نیست. اصلاح ایمن یک سیستم زنده در طول زمان است. سه ستون دارد.

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

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

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

این سه روش، تکنیک‌های تمام واحدهای قبلی را ترکیب می‌کنند: ارزیابی (واحد 5) تغییرات را از قبل اندازه‌گیری می‌کند، نظارت (این واحد) در حین انتشار اخطار اولیه می‌دهد، لایه تأیید خروجی‌های اشتباه را قبل از عملی شدن می‌گیرد. تولید یک تنظیم صحیح نیست. این یک رشته مستمر است که اندازه گیری می کند، نظارت می کند و می تواند با اطمینان تغییر کند. کل ماژول برای شما است که این رشته را ایجاد کنید.

به طور خلاصه

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

وظیفه کاربردی

یک ویژگی LLM را به صورت سرتاسر طراحی کنید. (1) پنج لایه (ورودی، مدل، تأیید، اقدام، نظارت) را برای کار خاص خود پر کنید. (2) با تأثیر مشخص کنید که کدام تصمیمات به تأیید انسان نیاز دارند. (3) حداقل سه بررسی اعتبار سنجی (طرحواره، قانون، منبع) بنویسید. (4) معیارهای کلیدی را که ردیابی خواهید کرد و آنچه را که ثبت نمی کنید تعیین کنید. (5) یک حد و یک اصل اخلاقی که قبول دارید در این ویژگی بنویسید.

چک لیست

• [ ] من می توانم پنج لایه خط لوله تولید را طراحی کنم.
• [ ] من می توانم خروجی را در برابر طرحواره، قانون و منبع تأیید کنم.
• [ ] من می توانم یک آستانه تایید انسانی بر اساس تاثیر تصمیم تعیین کنم.
• [ ] من هزینه، خطا و کیفیت را کنترل می کنم و تمرین نمی کنم داده های حساس را در گزارش ها بنویسم.
• [ ] من می توانم اخلاق، مسئولیت و مرزها را به تصمیمات تولید تبدیل کنم.

امتحان ماژول

1. نقش «سیستم» در یک API چت LLM چیست؟

• الف) به مدل دستورات و قوانین رفتاری دائمی می دهد که در کل مکالمه اعمال می شود ✔
• ب) آخرین سوال نوشته شده توسط کاربر را نگه می دارد
• ج) پاسخ تولید شده توسط مدل را ذخیره می کند
• د) کلید API را رمزگذاری می کند

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

2. چرا تاریخچه مکالمه (پیام های قبلی) هر بار در یک درخواست API دوباره ارسال می شود؟

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

توضیح: تماس های API LLM بدون حالت هستند. این مدل دورهای قبلی را به خاطر نمی‌آورد، بنابراین تمام تاریخچه مربوطه در هر درخواست برای حفظ متن ارسال می‌شود.

3. "توکن" در قیمت گذاری LLM چیست؟

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

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

4. چرا توکن های خروجی در اکثر ارائه دهندگان LLM گران تر از توکن های ورودی هستند؟

• الف) نشانه های خروجی همیشه طولانی تر از ورودی هستند
• ب) توکن های ورودی رایگان هستند
• ج) توکن های خروجی دو بار از طریق اینترنت ارسال می شوند
• د) هزینه واحد بیشتر است زیرا تولید خروجی به محاسبات اضافی برای هر توکن نیاز دارد ✔

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

5. استفاده از استریم در چه شرایطی سودمندتر است؟

• الف) در پاسخ های طولانی؛ تاخیر درک شده را کاهش می دهد و از وقفه جلوگیری می کند ✔
• ب) فقط در پاسخ های بسیار کوتاه و تک کلمه ای
• ج) به صفر رساندن هزینه
• د) برای مخفی کردن کلید API

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

6. افزایش پارامتر "تلاش" در مدل های مدرن به طور کلی چه تاثیری دارد؟

• الف) همیشه پاسخ را کوتاه کنید
• ب) کلید API را به صورت خودکار می چرخاند
• ج) فقط قیمت توکن ورودی را کاهش می دهد
• د) عمق تفکر و مخارج نمادین را افزایش می دهد. ممکن است کیفیت را بهبود بخشد، اما تاخیر و هزینه را نیز افزایش می دهد ✔

توضیحات: پارامتر تلاش تنظیم می‌کند که مدل تا چه حد به یک کار فکر می‌کند و چه تعداد توکن را صرف می‌کند. ارتقاء ممکن است کیفیت را بهبود بخشد، اما تاخیر و هزینه را نیز افزایش می دهد. برای کارهای ساده، تلاش کم کافی است.

7. به طور کلی مقرون به صرفه ترین رویکرد برای یک کار طبقه بندی ساده و با حجم بالا چیست؟

• الف) همیشه از گران ترین و قوی ترین مدل استفاده کنید
• ب) فراخوانی همه مدل ها به طور همزمان برای هر درخواست
• ج) انتخاب سبک‌ترین/ارزان‌ترین مدلی که کار را با بررسی کمی ارزش انجام می‌دهد ✔
• د) بالا نگه داشتن مقدار max_tokens به صورت غیر ضروری

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

8. در کدام سناریو حافظه پنهان سریع هزینه را بیشتر کاهش می دهد؟

• الف) هنگامی که یک زمینه بزرگ و ثابت به طور مکرر در بسیاری از درخواست ها استفاده می شود ✔
• ب) زمانی که با هر درخواست متنی کاملا متفاوت ارسال می شود
• ج) زمانی که فقط یک درخواست ارائه می شود
• D) To reduce output tokens

توضیحات: ذخیره کردن یک پیشوند تطبیق است. در مواردی که یک زمینه بزرگ و تغییرناپذیر (اعلام سیستم، اسناد) در بسیاری از درخواست‌ها مجدداً استفاده می‌شود، خواندن از حافظه پنهان کسری کوچک (~0.1x) از قیمت کامل است.

9. چگونه باید دستور را طوری ویرایش کنم که کش اعلان بزند؟

• الف) قرار دادن محتوای متغیر در ابتدا و محتوای ثابت در پایان
• ب) تاریخ و زمان فعلی را برای هر درخواست در اعلان سیستم جاسازی کنید
• ج) قرار دادن محتوای ثابت (اعلان سیستم، اسناد) در ابتدا و محتوای متغیر در پایان ✔
• د) تغییر ترتیب فهرست ابزار با هر درخواست

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

10. پردازش دسته ای برای چه نوع حجم کاری مناسب تر است؟

• الف) چت زنده که در آن کاربر انتظار پاسخ فوری روی صفحه را دارد
• ب) فقط یک سوال کوتاه
• ج) ایجاد کلید API
• د) مشاغلی که تحمل تاخیر، حجم زیاد و نیاز به نتیجه فوری ندارند✔

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

11. از چه چیزی برای مطابقت با اطمینان درخواستی استفاده می شود که نتایج به یک دسته تعلق دارد؟

• الف) ارسال سفارش (موقعیت) درخواستها
• ب) طول پاسخ ها
• ج) 4 رقم آخر کلید API
• د) یک custom_id منحصر به فرد که به هر درخواست داده می شود ✔

Remark: Bulk results may be returned in a different order than the submission order; بنابراین لازم است نتایج را بر اساس شناسه، نه مکان، با یک custom_id منحصربفرد که به هر درخواست داده می شود، مطابقت دهیم.

12. هنگام دریافت خطای 429 (محدودیت نرخ) از API، رفتار توصیه شده چیست؟

• الف) اجبار با ارسال درخواست های بسیار بیشتر به طور همزمان
• ب) تلاش مجدد با عقب نشینی نمایی، به دنبال سرفصل سعی مجدد پس از ✔
• ج) درخواست را به طور کامل لغو کنید و خطا را به صورت کرش به کاربر نشان دهید
• د) تغییر کلید API

توضیح: 429 یک خطای قابل امتحان مجدد است. روش صحیح این است که دوباره با عقب‌نشینی نمایی، با رعایت هدر سعی مجدد بعد از آن، دوباره امتحان کنید. اکثر SDK های رسمی این کار را به صورت خودکار انجام می دهند.

13. کدام یک از کدهای خطای HTTP زیر به طور کلی قابل امتحان مجدد در نظر گرفته می شوند؟

• الف) 400 (درخواست نامعتبر)
• ب) 401 (خطای احراز هویت)
• ج) 529 (سرور اضافه بار) ✔
• د) 404 (یافت نشد)

توضیح: 429 (محدودیت سرعت)، 500 (خطای سرور) و 529 (بیش از حد بار) خطاهای موقتی هستند و با عقب نشینی می توان آنها را دوباره امتحان کرد. خطاهایی مانند 400 و 401 مسائل مربوط به درخواست/هویت هستند. تلاش مجدد آن را حل نمی کند.

14. کدام یک از موارد زیر روش امن برای مدیریت کلیدهای API است؟

• الف) ذخیره در محیط متغیر/مدیر مخفی، عدم جاسازی آن در کد و چرخش منظم ✔
• ب) کلید را مستقیماً در کد منبع بنویسید و آن را به مخزن ارسال کنید
• ج) قرار دادن کلید در سمت کلاینت (مرورگر) جاوا اسکریپت
• د) اشتراک گذاری یک کلید با کل تیم از طریق ایمیل

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

15. بهترین رویکرد برای ادغام LLM با ابزار اتوماسیون (n8n، Zapier، Make) از نظر حریم خصوصی چیست؟

• الف) ارسال تمام داده های خام به مدل، حتی اگر ضروری نباشد
• ب) نوشتن کلید API به صورت متن ساده در داخل مرحله جریان
• ج) به حداقل رساندن و پوشاندن داده های حساس و ذخیره کلید به عنوان اعتبار مخفی ✔
• د) نگهداری دائمی داده های شخصی در تاریخچه جریان

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

16. چرا اعتبار سنجی خروجی در ویژگی تولید مبتنی بر LLM اجباری است؟

• الف) فقط قالب بندی مورد نیاز است زیرا مدل هرگز اشتباه نمی کند
• ب) از آنجا که مدل می تواند به صورت سیال، اما گاهی اوقات نادرست تولید کند. طرح و قانون باید با منابع و تایید انسانی بررسی شود ✔
• ج) باید از اعتبار سنجی خودداری کرد زیرا فقط هزینه را افزایش می دهد
• د) تأیید فقط برای کاهش تعداد توکن ها است

توضیحات: LLM ها می توانند خروجی روان اما گاهی نادرست (توهم) تولید کنند. بنابراین در تصمیمات با تأثیرگذاری بالا ظاهر شد. باید با بررسی طرح‌واره/قوانین، اعتبارسنجی منبع، و تأیید انسانی در صورت لزوم ممیزی شود.