راهنمای توسعه‌دهنده شخصی‌سازی روی دستگاه، راهنمای توسعه‌دهنده شخصی‌سازی روی دستگاه، راهنمای توسعه‌دهنده شخصی‌سازی روی دستگاه

شخصی‌سازی روی دستگاه (ODP) برای محافظت از اطلاعات کاربران نهایی در برابر برنامه‌ها طراحی شده است. برنامه‌ها از ODP برای سفارشی‌سازی محصولات و خدمات خود برای کاربران نهایی استفاده می‌کنند، اما نمی‌توانند سفارشی‌سازی‌های دقیق انجام شده برای کاربر را ببینند (مگر اینکه تعاملات مستقیمی خارج از ODP بین برنامه و کاربر نهایی وجود داشته باشد). برای برنامه‌هایی با مدل‌های یادگیری ماشین یا تجزیه و تحلیل‌های آماری، ODP مجموعه‌ای از خدمات و الگوریتم‌ها را ارائه می‌دهد تا اطمینان حاصل شود که آنها با استفاده از مکانیسم‌های مناسب حریم خصوصی تفاضلی (Differential Privacy) به درستی ناشناس می‌شوند. برای جزئیات بیشتر، به توضیح مربوط به شخصی‌سازی روی دستگاه مراجعه کنید.

ODP کد توسعه‌دهنده را در یک IsolatedProcess اجرا می‌کند که هیچ دسترسی مستقیمی به شبکه، دیسک‌های محلی یا سایر سرویس‌های در حال اجرا روی دستگاه ندارد، اما به منابع داده محلی زیر دسترسی دارد:

  • RemoteData - داده‌های کلید-مقدار تغییرناپذیر که در صورت لزوم از بک‌اندهای کنترل‌شده توسط توسعه‌دهنده از راه دور دانلود می‌شوند.
  • LocalData - داده‌های کلید-مقدار قابل تغییر که در صورت وجود، به صورت محلی توسط توسعه‌دهنده ذخیره می‌شوند.
  • UserData - داده‌های کاربر ارائه شده توسط پلتفرم.

خروجی‌های زیر پشتیبانی می‌شوند:

  • خروجی پایدار: این خروجی‌ها می‌توانند در پردازش‌های محلی آینده، تولید خروجی‌های نمایش داده شده، آموزش مدل تسهیل‌شده با یادگیری فدرال یا تجزیه و تحلیل آماری بین دستگاهی تسهیل‌شده با تجزیه و تحلیل فدرال مورد استفاده قرار گیرند.
    • توسعه‌دهندگان می‌توانند درخواست‌ها و همچنین نتایج پردازش آنها را در جدول REQUESTS محلی بنویسند.
    • توسعه‌دهندگان می‌توانند داده‌های اضافی مرتبط با درخواست قبلی را در جدول EVENTS بنویسند.
  • خروجی نمایش داده شده:
    • توسعه‌دهندگان می‌توانند HTML ای را که توسط ODP در یک WebView درون یک SurfaceView رندر شده است، برگردانند. محتوای رندر شده در آنجا برای برنامه‌ی فراخوانی کننده قابل مشاهده نخواهد بود.
    • توسعه‌دهندگان می‌توانند URLهای رویداد ارائه شده توسط ODP را در خروجی HTML جاسازی کنند تا ثبت و پردازش تعاملات کاربر با HTML رندر شده را آغاز کنند. ODP درخواست‌های ارسالی به آن URLها را رهگیری کرده و کدی را برای تولید داده‌هایی که در جدول EVENTS نوشته می‌شوند، فراخوانی می‌کند.

برنامه‌های کلاینت و SDKها می‌توانند با استفاده از APIهای ODP، ODP را برای نمایش محتوای HTML در SurfaceView فراخوانی کنند. محتوای رندر شده در SurfaceView برای برنامه فراخوانی کننده قابل مشاهده نیست. برنامه کلاینت یا SDK می‌تواند موجودیتی متفاوت از آنچه که با ODP در حال توسعه است، باشد.

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

برنامه‌های کلاینت از متدهای کلاس OnDevicePersonalizationManager برای تعامل با کد توسعه‌دهنده که در یک IsolatedProcess اجرا می‌شود، استفاده می‌کنند. کد توسعه‌دهنده که در یک IsolatedProcess اجرا می‌شود، کلاس IsolatedService را ارث‌بری می‌کند و رابط IsolatedWorker پیاده‌سازی می‌کند. IsolatedService برای هر درخواست باید یک نمونه از IsolatedWorker ایجاد کند.

نمودار زیر رابطه بین متدهای موجود در OnDevicePersonalizationManager و IsolatedWorker را نشان می‌دهد.

نمودار رابطه بین OnDevicePersonalizationManager و IsolatedWorker .

یک برنامه‌ی کلاینت، ODP را با استفاده از متد execute با نام IsolatedService فراخوانی می‌کند. سرویس ODP فراخوانی را به متد onExecute از IsolatedWorker ارسال می‌کند. IsolatedWorker رکوردهایی را که باید ذخیره شوند و محتوایی را که باید نمایش داده شوند، برمی‌گرداند. سرویس ODP خروجی ذخیره شده را در جدول REQUESTS یا EVENTS می‌نویسد و یک ارجاع مبهم به خروجی نمایش داده شده را به برنامه‌ی کلاینت برمی‌گرداند. برنامه‌ی کلاینت می‌تواند از این ارجاع مبهم در فراخوانی requestSurfacePackage در آینده برای نمایش هر یک از محتوای نمایشی در رابط کاربری خود استفاده کند.

خروجی مداوم

سرویس ODP پس از پیاده‌سازی onExecute توسط توسعه‌دهنده، یک رکورد را در جدول REQUESTS حفظ می‌کند. هر رکورد در جدول REQUESTS شامل برخی از داده‌های مشترک تولید شده توسط سرویس ODP برای هر درخواست و لیستی از Rows برگردانده شده است. هر Row شامل لیستی از جفت‌های (key, value) است. هر مقدار یک اسکالر، رشته یا blob است. مقادیر عددی را می‌توان پس از تجمیع گزارش کرد و داده‌های رشته یا blob را می‌توان پس از اعمال Differential Privacy محلی یا مرکزی گزارش کرد. توسعه‌دهندگان همچنین می‌توانند رویدادهای بعدی تعامل کاربر را در جدول EVENTS بنویسند - هر رکورد در جدول EVENTS با یک ردیف در جدول REQUESTS مرتبط است. سرویس ODP به طور شفاف یک مهر زمانی و نام بسته برنامه فراخوانی و APK توسعه‌دهنده ODP را با هر رکورد ثبت می‌کند.

قبل از اینکه شروع کنی

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

تنظیمات مانیفست بسته

برای استفاده از ODP موارد زیر لازم است:

  1. یک تگ <property> در AndroidManifest.xml که به یک منبع XML در بسته‌ای که حاوی اطلاعات پیکربندی ODP است اشاره می‌کند.
  2. یک تگ <service> در AndroidManifest.xml که کلاسی را که IsolatedService ارث بری می‌کند، مشخص می‌کند، همانطور که در مثال زیر نشان داده شده است. سرویس موجود در تگ <service> باید دارای ویژگی‌های exported و isolatedProcess باشد که روی true تنظیم شده‌اند.
  3. یک برچسب <service> در منبع XML مشخص شده در مرحله 1 که کلاس سرویس را از مرحله 2 مشخص می‌کند. برچسب <service> همچنین باید شامل تنظیمات اضافی مخصوص ODP در داخل خود برچسب باشد، همانطور که در مثال دوم نشان داده شده است.

فایل AndroidManifest.xml

<!-- Contents of AndroidManifest.xml -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.odpsample" >
    <application android:label="OdpSample">
        <!-- XML resource that contains other ODP settings. -->
        <property android:name="android.ondevicepersonalization.ON_DEVICE_PERSONALIZATION_CONFIG"
                  android:resource="@xml/OdpSettings"></property>
        <!-- The service that ODP binds to. -->
        <service android:name="com.example.odpsample.SampleService"
                android:exported="true" android:isolatedProcess="true" />
    </application>
</manifest>

مانیفست مخصوص ODP در منبع XML

فایل منبع XML مشخص شده در برچسب <property> باید کلاس سرویس را نیز در برچسب <service> تعریف کند و نقطه پایانی URL را که ODP از آن محتوا را برای پر کردن جدول RemoteData دانلود می‌کند، همانطور که در مثال زیر نشان داده شده است، مشخص کند. اگر از ویژگی‌های محاسبه فدرال استفاده می‌کنید، باید نقطه پایانی URL سرور محاسبه فدرال را که کلاینت محاسبه فدرال به آن متصل می‌شود، نیز مشخص کنید.

<!-- Contents of res/xml/OdpSettings.xml -->
<on-device-personalization>
   <!-- Name of the service subclass -->
   <service name="com.example.odpsample.SampleService">
     <!-- If this tag is present, ODP will periodically poll this URL and
          download content to populate REMOTE_DATA. Developers that do not need to
          download content from their servers can skip this tag. -->
     <download-settings url="https://example.com/get" />
     <!-- If you want to use federated compute feature to train a model, you
          need to specify this tag. -->
     <federated-compute-settings url="https://fcpserver.example.com/" />
   </service>
</on-device-personalization>

فعال کردن حالت توسعه‌دهنده

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

تنظیمات سوئیچ و فلگ

ODP مجموعه‌ای از سوئیچ‌ها و پرچم‌ها را دارد که برای کنترل قابلیت‌های خاص استفاده می‌شوند:

  • سوئیچ _global_kill : سوئیچ سراسری برای همه ویژگی‌های ODP؛ برای استفاده از ODP روی false تنظیم شده است.
  • سوئیچ_federated_compute_kill_switch: سوئیچی که تمام عملکردهای آموزشی (یادگیری فدرال) ODP را کنترل می‌کند؛ برای استفاده از آموزش، روی false تنظیم شده است.
  • لیست _caller_app_allow : کنترل می‌کند چه کسی مجاز به تماس با ODP و برنامه‌ها (نام pkg، گواهی [اختیاری]) است که می‌توان آن را در اینجا اضافه کرد یا برای اجازه دادن به همه، آن را روی * تنظیم کرد.
  • لیست _isolated_service_allow : کنترل می‌کند که کدام سرویس‌ها می‌توانند در فرآیند سرویس ایزوله اجرا شوند.

شما می‌توانید دستورات زیر را برای پیکربندی همه سوئیچ‌ها و پرچم‌ها برای استفاده از ODP بدون محدودیت اجرا کنید:

# Set flags and killswitches
adb shell device_config set_sync_disabled_for_tests persistent
adb shell device_config put on_device_personalization global_kill_switch false
adb shell device_config put on_device_personalization federated_compute_kill_switch false
adb shell device_config put on_device_personalization caller_app_allow_list \"*\"
adb shell device_config put on_device_personalization isolated_service_allow_list \"*\"

APIهای سمت دستگاه

مستندات مرجع API اندروید برای ODP را بررسی کنید.

تعاملات با IsolatedService

کلاس IsolatedService یک کلاس پایه انتزاعی است که همه توسعه‌دهندگانی که قصد توسعه آن را در برابر ODP دارند، باید آن را توسعه دهند و در مانیفست بسته خود اعلام کنند که در یک فرآیند ایزوله اجرا می‌شود. سرویس ODP این سرویس را در یک فرآیند ایزوله شروع می‌کند و درخواست‌هایی را به آن ارسال می‌کند. IsolatedService درخواست‌ها را از سرویس ODP دریافت می‌کند و یک IsolatedWorker برای مدیریت درخواست ایجاد می‌کند.

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

کلاس OnDevicePersonalizationManager یک API برای برنامه‌ها و SDKها فراهم می‌کند تا با یک IsolatedService پیاده‌سازی‌شده توسط توسعه‌دهنده که در یک فرآیند ایزوله اجرا می‌شود، تعامل داشته باشند. موارد استفاده‌ی مورد نظر در زیر آمده است:

تولید محتوای HTML برای نمایش در SurfaceView

برای تولید محتوا برای نمایش، با OnDevicePersonalizationManager#execute ، برنامه فراخوانی می‌تواند از شیء SurfacePackageToken برگردانده شده در فراخوانی بعدی requestSurfacePackage استفاده کند تا درخواست کند نتیجه در SurfaceView رندر شود.

در صورت موفقیت، گیرنده با یک SurfacePackage برای یک View که توسط سرویس ODP رندر شده است، فراخوانی می‌شود. برنامه‌های کلاینت باید SurfacePackage در یک SurfaceView در سلسله مراتب View خود وارد کنند.

وقتی یک برنامه requestSurfacePackage را با فراخوانی SurfacePackageToken که توسط فراخوانی قبلی OnDevicePersonalizationManager#execute برگردانده شده است، ارسال می‌کند، سرویس ODP، IsolatedWorker#onRender را برای دریافت قطعه کد HTML جهت رندر شدن در یک فریم محصور، فراخوانی می‌کند. توسعه‌دهنده در این مرحله به LocalData یا UserData دسترسی ندارد. این امر مانع از جاسازی UserData حساس بالقوه توسط توسعه‌دهنده در URLهای مربوط به دریافت دارایی در HTML تولید شده می‌شود. توسعه‌دهندگان می‌توانند از IsolatedService#getEventUrlProvider برای تولید URLهای ردیابی جهت گنجاندن در HTML تولید شده استفاده کنند. وقتی HTML رندر می‌شود، سرویس ODP درخواست‌های ارسالی به این URLها را رهگیری کرده و IsolatedWorker#onEvent را فراخوانی می‌کند. می‌توان هنگام پیاده‌سازی onRender() از getRemoteData() استفاده کرد.

پیگیری رویدادها در محتوای HTML

کلاس EventUrlProvider رابط‌های برنامه‌نویسی کاربردی (API) برای تولید URLهای ردیابی رویداد ارائه می‌دهد که توسعه‌دهندگان ممکن است در خروجی HTML خود بگنجانند. هنگامی که HTML رندر می‌شود، ODP با payload مربوط به URL رویداد IsolatedWorker#onEvent را فراخوانی می‌کند.

سرویس ODP درخواست‌های ارسالی به URLهای رویداد تولید شده توسط ODP را در HTML رندر شده رهگیری می‌کند، IsolatedWorker#onEvent را فراخوانی می‌کند و EventLogRecord برگشتی را در جدول EVENTS ثبت می‌کند.

نتایج ماندگار بنویسید

با استفاده از OnDevicePersonalizationManager#execute ، سرویس این امکان را دارد که داده‌ها را در حافظه دائمی (جداول REQUESTS و EVENTS ) بنویسد. ورودی‌هایی که می‌توان در این جداول نوشت عبارتند از:

  • یک RequestLogRecord که قرار است به جدول REQUESTS اضافه شود.
  • فهرستی از اشیاء EventLogRecord که قرار است به جدول EVENTS اضافه شوند، که هر کدام حاوی یک اشاره‌گر به RequestLogRecord نوشته شده قبلی هستند.

نتایج پایدار در حافظه داخلی دستگاه می‌توانند توسط Federated Learning برای آموزش مدل مورد استفاده قرار گیرند.

مدیریت وظایف آموزشی روی دستگاه

سرویس ODP زمانی که یک کار آموزش محاسباتی فدرال شروع می‌شود و می‌خواهد نمونه‌های آموزشی ارائه شده توسط توسعه‌دهندگانی که از ODP استفاده می‌کنند را دریافت کند IsolatedWorker#onTrainingExample را فراخوانی می‌کند. می‌توانید هنگام پیاده‌سازی onTrainingExample() getRemoteData() ، getLocalData() ، getUserData() و getLogReader() استفاده کنید.

برای زمان‌بندی یا لغو کارهای محاسباتی فدرال، می‌توانید از کلاس FederatedComputeScheduler استفاده کنید که APIهایی را برای همه ODP IsolatedService فراهم می‌کند. هر کار محاسباتی فدرال را می‌توان با نام جمعیت آن شناسایی کرد.

قبل از اینکه یک کار محاسباتی فدرال جدید را برنامه‌ریزی کنید:

  • یک وظیفه با این نام جمعیت باید از قبل روی سرور محاسباتی فدرال راه دور ایجاد شده باشد.
  • نقطه پایانی URL سرور محاسباتی فدرال باید از قبل در تنظیمات مانیفست بسته با برچسب federated-compute-settings مشخص شده باشد.

تعاملات با خروجی پایدار

بخش زیر نحوه تعامل با خروجی پایدار در ODP را شرح می‌دهد.

جداول محلی را بخوانید

کلاس LogReader رابط‌های برنامه‌نویسی کاربردی (API) برای خواندن جداول REQUESTS و EVENTS ارائه می‌دهد. این جداول حاوی داده‌هایی هستند که توسط IsolatedService در طول فراخوانی‌های onExecute() یا onEvent() نوشته شده‌اند. داده‌های موجود در این جداول می‌توانند برای آموزش مدل تسهیل‌شده با Federated Learning یا تجزیه و تحلیل آماری بین دستگاهی تسهیل‌شده با Federated Analytics استفاده شوند.

تعامل با محتوای دانلود شده

بخش زیر نحوه تعامل با محتوای دانلود شده در ODP را شرح می‌دهد.

دانلود محتوا از سرورها

سرویس ODP به صورت دوره‌ای محتوا را از URL اعلام شده در مانیفست بسته‌ی IsolatedService دانلود می‌کند و پس از اتمام دانلود، تابع onDownloadCompleted را فراخوانی می‌کند. دانلود یک فایل JSON حاوی جفت‌های کلید-مقدار است.

توسعه‌دهندگانی که از ODP استفاده می‌کنند می‌توانند انتخاب کنند که کدام زیرمجموعه از محتوای دانلود شده باید به جدول RemoteData اضافه شود و کدام یک باید حذف شود. توسعه‌دهندگان نمی‌توانند محتوای دانلود شده را تغییر دهند - این تضمین می‌کند که جدول RemoteData حاوی هیچ داده کاربری نباشد. علاوه بر این، توسعه‌دهندگان آزاد هستند که جدول LocalData را به دلخواه خود پر کنند. به عنوان مثال، آنها می‌توانند برخی از نتایج از پیش محاسبه شده را ذخیره کنند.

دانلود فرمت درخواست

ODP به صورت دوره‌ای نقطه پایانی URL اعلام شده در مانیفست بسته توسعه‌دهنده را بررسی می‌کند تا محتوا را برای پر کردن جدول RemoteData دریافت کند.

انتظار می‌رود که نقطه پایانی، همانطور که بعداً توضیح داده خواهد شد، یک پاسخ JSON برگرداند. پاسخ JSON باید حاوی یک syncToken باشد که نسخه داده‌های ارسالی را به همراه لیستی از جفت‌های کلید-مقدار که باید پر شوند، مشخص می‌کند. مقدار syncToken باید یک مهر زمانی بر حسب ثانیه باشد که در مرز ساعت UTC قرار دارد. به عنوان بخشی از درخواست دانلود، ODP، syncToken مربوط به دانلود قبلی تکمیل شده و کشور دستگاه را به عنوان پارامترهای syncToken و country در URL دانلود ارائه می‌دهد. سرور می‌تواند از syncToken قبلی برای پیاده‌سازی دانلودهای افزایشی استفاده کند.

فرمت فایل دانلود

فایل دانلود شده یک فایل JSON با ساختار زیر است. انتظار می‌رود فایل JSON حاوی یک syncToken برای شناسایی نسخه داده‌هایی که دانلود می‌شوند باشد. syncToken باید یک مهر زمانی UTC باشد که در یک مرز ساعتی قرار دارد و باید از syncToken دانلود قبلی بیشتر باشد. اگر syncToken هر دو الزام را برآورده نکند، محتوای دانلود شده بدون پردازش حذف می‌شود.

فیلد محتوا (contents) فهرستی از تاپل‌های (key، data، encoding) است. انتظار می‌رود key یک رشته UTF-8 باشد. فیلد encoding یک پارامتر اختیاری است که نحوه کدگذاری فیلد data را مشخص می‌کند - می‌تواند روی "utf8" یا "base64" تنظیم شود و به طور پیش‌فرض "utf8" فرض می‌شود. فیلد key به یک شیء String تبدیل می‌شود و فیلد data قبل از فراخوانی onDownloadCompleted().

{
  // syncToken must be a UTC timestamp clamped to an hour boundary, and must be
  // greater than the syncToken of the previously completed download.
  "syncToken": <timeStampInSecRoundedToUtcHour>,
  "contents": [
    // List of { key, data } pairs.
    { "key": "key1",
      "data": "data1"
    },
    { "key": "key2",
      "data": "data2",
      "encoding": "base64"
    },
    // ...
  ]
}

API های سمت سرور

این بخش نحوه تعامل با APIهای سرور محاسباتی فدرال را شرح می‌دهد.

APIهای سرور محاسباتی فدرال

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

نمودار توپولوژی کلاینت-سرور محاسباتی فدرال.

هنگام ایجاد یک وظیفه جدید برای Task Builder، توسعه‌دهندگان ODP باید دو مجموعه فایل ارائه دهند:

  1. یک مدل tff.learning.models.FunctionalModel ذخیره شده از طریق فراخوانی فراخوانی API tff.learning.models.save_functional_model . می‌توانید یک نمونه را در مخزن گیت‌هاب ما پیدا کنید.
  2. یک فایل fcp_server_config.json که شامل سیاست‌ها، تنظیمات یادگیری فدرال و تنظیمات حریم خصوصی دیفرانسیلی است. در زیر مثالی از یک فایل fcp_server_config.json آمده است:
{
  # Task execution mode.
  mode: TRAINING_AND_EVAL
  # Identifies the set of client devices that participate.
  population_name: "mnist_cnn_task"
  policies {
    # Policy for sampling on-device examples. It is checked every
    # time a device is attempting to start a new training.
    min_separation_policy {
      # The minimum separation required between two successful
      # consective task executions. If a client successfully contributes
      # to a task at index `x`, the earliest they can contribute again
      # is at index `(x + minimum_separation)`. This is required by
      # DP.
      minimum_separation: 1
    }
    data_availability_policy {
      # The minimum number of examples on a device to be considered
      # eligible for training.
      min_example_count: 1
    }
    # Policy for releasing training results to developers adopting ODP.
    model_release_policy {
      # The maximum number of training rounds.
      num_max_training_rounds: 512
    }
  }

  # Federated learning setups. They are applied inside Task Builder.
  federated_learning {
    # Use federated averaging to build federated learning process.
    # Options you can choose:
      # * FED_AVG: Federated Averaging algorithm
      #            (https://arxiv.org/abs/2003.00295)
      # * FED_SGD: Federated SGD algorithm
      #            (https://arxiv.org/abs/1602.05629)
    type: FED_AVG
    learning_process {
      # Optimizer used at client side training. Options you can choose:
      # * ADAM
      # * SGD
      client_optimizer: SGD
      # Learning rate used at client side training.
      client_learning_rate: 0.02
      # Optimizer used at server side training. Options you can choose:
      # * ADAM
      # * SGD
      server_optimizer: SGD
      # Learning rate used at server side training.
      server_learning_rate: 1.0
      runtime_config {
        # Number of participating devices for each round of training.
      report_goal: 2
      }
      metrics {
        name: "sparse_categorical_accuracy"
      }
    }
    evaluation {
      # A checkpoint selector controls how checkpoints are chosen for
      # evaluation. One evaluation task typically runs per training
      # task, and on each round of execution, the eval task
      # randomly picks one checkpoint from the past 24 hours that has
      # been selected for evaluation by these rules.
      # Every_k_round and every_k_hour are definitions of quantization
      # buckets which each checkpoint is placed in for selection.
      checkpoint_selector: "every_1_round"
      # The percentage of a populate that should delicate to this
      # evaluation task.
      evaluation_traffic: 0.2
      # Number of participating devices for each round of evaluation.
      report_goal: 2
    }
  }

  # Differential Privacy setups. They are enforced inside the Task
  # Builder.
  differential_privacy {
    # * fixed_gaussian: DP-SGD with fixed clipping norm described in
    #                   "Learning Differentially Private Recurrent
    #                   Language Models"
    #                   (https://arxiv.org/abs/1710.06963).
    type: FIXED_GAUSSIAN
    #   The value of the clipping norm.
    clip_norm: 0.1
    # Noise multiplier for the Gaussian noise.
    noise_multiplier: 0.1
  }
}

می‌توانید نمونه‌های بیشتری را در مخزن گیت‌هاب ما پیدا کنید.

پس از آماده‌سازی این دو ورودی، Task Builder را برای ساخت مصنوعات و تولید وظایف جدید فراخوانی کنید. دستورالعمل‌های دقیق‌تر در مخزن GitHub ما موجود است.