فصل چهارم: روش‌های هوش مصنوعی در زمینه کشاورزی

بخش دوم — مبانی هوش مصنوعی و داده

پرسش این بخش: از لحظه‌ای که یک سامانه هوش مصنوعی داده را دریافت می‌کند تا زمانی که پاسخ یا توصیه‌اش به کشاورز می‌رسد، درون آن چه می‌گذرد؟

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

فصل چهارم: روش‌های هوش مصنوعی در زمینه کشاورزی

پیام فصل

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

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

جداکردن این حلقه‌ها اهمیت دارد. ممکن است مدلی در طبقه‌بندی یک تصویر خوب باشد، در حالی که خود تصویر نماینده مزرعه نیست. ممکن است پیش‌بینی‌ای معقول باشد، اما بدل کردن آن به دُز یا زمان‌بندی نیازمند قواعد کشاورزی و قیدهای ایمنی‌ای است که مدل آن‌ها را نیاموخته است. در سامانه‌های بالغ، این تمایزها پشت واژه «هوشمند» ناپدید نمی‌شوند؛ به کاربر نشان داده می‌شوند تا بداند کجا اعتماد موجه است و کجا راستی‌آزمایی لازم است.

1. از پرسش تا بازنمایی

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

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

2. یادگیری نظارت‌شده: یادگیری از نمونه‌هایی با نتایج معلوم

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

• چه کسی وضعیت مرجع یا مقدار مرجع را تعیین کرده، و از چه قواعدی پیروی کرده است؟
• آیا نتیجه را یک متخصص تأیید کرده، بیش از یک متخصص بازبینی کرده، یا آزمونی مرجع آن را تثبیت کرده است؟
• آیا سطح اطمینان ثبت شده، و آیا هنگام ناکافی‌بودن شواهد نتیجه «غیرقطعی» مجاز بوده است؟
• آیا تعریف هر وضعیت در مزارع، نهادها و فصل‌های گوناگون یکدست مانده است؟
• آیا نمونه‌ها وضعیت‌های آسان و دشوار، نشانه‌های اولیه و پیشرفته، و موارد آمیخته را در بر می‌گیرند؟
• آیا تصاویر و رکوردها نماینده تنوع در ارقام، مکان‌ها، دستگاه‌ها و نورپردازی‌اند؟
• آیا تصاویر یا رکوردهای بسیار شبیه به هم میان آموزش و آزمون تفکیک شده‌اند، تا سامانه روی نسخه‌هایی بسیار مشابه آنچه پیش‌تر دیده است آزموده نشود؟

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

3. یادگیری بدون نظارت و نیمه‌نظارتی: وقتی نتایج مستند کمیاب‌اند چه کنیم؟

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

• یک پهنه ممکن است از زهکشی نامناسب رنج ببرد.
• پهنه‌ای دیگر ممکن است از سایه تأثیر پذیرفته باشد.
• پهنه سوم ممکن است در نوع خاک متفاوت باشد.
• و قرائت پهنه چهارم ممکن است به سبب حسگری کالیبره‌نشده پایین باشد.

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

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

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

• جدی‌بودن وضعیتی که ممکن است در تشخیص آن ناکام بماند.
• شمار هشدارهای کاذبی که تیم می‌تواند از عهده آن برآید.
• توان کارگر یا متخصص برای بررسی به‌موقع هشدار.

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

• برگی سالم.
• نشانه‌های یک بیماری مشخص.
• نشانه‌های کمبود یک عنصر غذایی.
• تصویری که برای داوری کافی نیست.

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

• یک مزرعه.
• یک رقم.
• یک گوشی تلفن.
• شرایط نورپردازی مشابه.
• مرحله‌ای پیشرفته از بیماری.

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

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

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

1. تیم نخست سلامت حسگرها و داده‌ها را تأیید می‌کند.
2. تیم از نقاط نماینده در هر پهنه بازدید می‌کند.
3. خاک، زهکشی، سایه و تاریخچه مدیریت را بررسی می‌کند.
4. در صورت نیاز نمونه‌های مناسب برمی‌دارد.
5. تفسیر محاسباتی را با مشاهده و اندازه‌گیری میدانی مقایسه می‌کند.
6. سپس تعیین می‌کند که آیا پهنه‌ها واقعاً به درمان‌های متفاوت نیاز دارند.

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

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

و اصل وحدت‌بخش این است: داده فراوان به سامانه کمک می‌کند الگوها را ببیند، اما معنای کشاورزی از کمیت به‌تنهایی برنمی‌خیزد؛ بلکه از اندازه‌گیری درست، نمونه‌های مستند، زمینه میدانی و راستی‌آزمایی انسانی برمی‌خیزد.

4. بینایی ماشین: سامانه در تصویر چه می‌بیند؟

وقتی کشاورز یا متخصصی به برگ گیاهی نگاه می‌کند، تنها رنگ و شکل نمی‌بیند. بلکه آنچه را می‌بیند به سن گیاه، گسترش نشانه‌ها، وضعیت مزرعه، وضع هوا، آبیاری، و تجربه خود با موارد پیشین پیوند می‌دهد. سامانه بینایی ماشین، در مقابل، از چیزی محدودتر آغاز می‌کند: تصویر یا قطعه ویدئویی که به داده‌ای دیجیتال بدل شده تا رایانه بتواند آن را تحلیل کند. بینایی ماشین مجموعه‌ای از روش‌هاست که به سامانه کمک می‌کند الگوها را درون تصاویر و ویدئو بیابد. ممکن است از مدل‌هایی به نام شبکه‌های عصبی پیچشی، یا مدل‌های بینایی جدیدتر، برای شناسایی شکل‌ها، رنگ‌ها، بافت‌ها و روابط فضایی استفاده کند. کاربردهای کشاورزی آن شامل بازرسی بیماری‌های گیاهی، شناسایی علف‌های هرز و میوه‌ها، تخمین رسیدگی، دسته‌بندی محصولات، و پایش حرکت و رفتار حیوان است. مرورهای علمی گستره این کاربردها را در مهندسی کشاورزی و غذا بررسی می‌کنند [SRC001][SRC002]. اما گفتن اینکه سامانه «تصویر را می‌فهمد» ممکن است این‌گونه القا کند که آن را همچون انسان می‌بیند و تفسیر می‌کند. در واقع، همان تصویر واحد را می‌توان برای پاسخ‌دادن به پرسش‌های متفاوت به کار برد، و هر پرسش روش، نتیجه و محدودیت‌های خود را دارد. 1\. تعیین وضعیت کلی تصویر — طبقه‌بندی در این وظیفه، سامانه تصویر را همچون واحدی یکپارچه می‌بیند، سپس نزدیک‌ترین وضعیت را از میان مجموعه‌ای از وضعیت‌هایی که پیش‌تر آموخته است برمی‌گزیند. نتیجه ممکن است، برای نمونه، چنین باشد:

• برگ سالم به نظر می‌رسد.
• نشانه‌هایی هست که بر ابتلا دلالت می‌کند.
• میوه به نظر می‌رسد در درجه کیفی معینی جای می‌گیرد.
• تصویر برای رسیدن به نتیجه‌ای قابل اطمینان کافی نیست.

این نوع تحلیل برای دسته‌بندی اولیه سودمند است. اما لزوماً نشان نمی‌دهد که نشانه در کجای تصویر است، علت آن را تثبیت نمی‌کند، و احتمال را به تشخیصی نهایی بدل نمی‌کند. پس اگر سامانه بگوید تصویر «مشکوک» است، این یعنی الگوی کلی به نمونه‌هایی که از آن‌ها آموخته است شباهت دارد. این به‌تنهایی به معنای آن نیست که بیماری تأیید شده، یا اینکه درمان اکنون معلوم است. 2\. تعیین موقعیت شیء یا نشانه — تشخیص گاه دانستن اینکه تصویر شامل میوه، علف هرز یا لکه‌ای مشکوک است کافی نیست؛ باید بدانیم کجاست. در این حالت، سامانه دایره یا کادری آشکار پیرامون بخشی که تشخیص داده است می‌کشد. برای نمونه، هنگام بررسی برگ گیاه، ممکن است کادری پیرامون لکه‌ای خاص پدیدار شود. هنگام تحلیل تصویر یک مزرعه، ممکن است سامانه پیرامون هر میوه یا علف هرزی که توانسته بیابد کادری بگذارد. این نتیجه به پاسخ‌دادن به این پرسش کمک می‌کند: چیزی که سامانه تشخیص داد کجاست؟ همچنین به کاربر کمک می‌کند راستی‌آزمایی کند که سامانه بر بخش درست متمرکز شده است. ممکن است سامانه گمان کند نشانه‌ای از بیماری را تشخیص داده است در حالی که در واقع بر سایه، لکه‌ای از خاک، یا بخشی از پس‌زمینه تصویر متمرکز شده است. اما شناسایی موقعیت لکه علت پدیدارشدن آن را تثبیت نمی‌کند. ممکن است سامانه موقعیت آسیب را به‌درستی شناسایی کند، در حالی که تعیین بیماری یا تنشی که سبب آن شده است همچنان به اطلاعات دیگری نیاز دارد. 3\. رسم مرزهای ناحیه مبتلا — قطعه‌بندی ممکن است به چیزی بیش از موقعیت شیء نیاز داشته باشیم؛ ممکن است بخواهیم به‌دقت بدانیم چه مساحتی را اشغال می‌کند. در این وظیفه، سامانه ناحیه‌ای را که آسیب‌دیده می‌پندارد رنگ می‌کند، یا مرزهای آن را روی تصویر می‌کشد. به‌جای گذاشتن کادری گسترده پیرامون کل برگ، می‌کوشد بخش مبتلا را درون آن شناسایی کند. این می‌تواند در این موارد کمک کند:

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

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

• ردیابی حرکت یک حیوان درون آغل.
• ردیابی یک میوه بر خط درجه‌بندی.
• شمارش اشیا بدون آنکه یک شیء بیش از یک بار شمرده شود.
• پایش گسترش ناحیه‌ای آسیب‌دیده در تصاویر پیاپی.
• ردیابی حرکت یک ماشین یا یک کارگر در محدوده بهره‌برداری.

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

• فاصله میان ابزار و میوه.
• ارتفاع گیاه یا اندازه یک شیء مشخص.
• میزان نزدیکی یک انسان یا حیوان به محدوده حرکت.
• موقعیت شاخه نسبت به بازوی رباتیک.
• شکل شیئی که باید گرفته شود یا از آن پرهیز شود.

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

1. شناسایی هر علف هرز.
2. تمایز آن‌ها از محصول.
3. تعیین موقعیت آن نسبت به ماشین.
4. محاسبه حرکت ابزار.
5. راستی‌آزمایی اینکه هیچ انسان، حیوان یا شیء غیرمنتظره‌ای حضور ندارد.
6. توقف اجرا اگر اطمینان کاهش یابد یا داده‌ها ناسازگار باشند.

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

• نور صبح یا نیمروز.
• سایه.
• زاویه دوربین.
• نوع تلفن یا دوربین.
• نزدیک‌تر یا دورتر بودن لنز.
• گردوغبار یا رطوبت.
• پس‌زمینه.
• مرحله رشد گیاه.
• هم‌پوشانی برگ‌ها.
• شدت نشانه‌ها و مرحله آن‌ها.

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

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

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

• 950 تصویر سالم.
• 50 تصویر مبتلا به بیماری‌ای مهم.

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

• چند مورد بیمار را توانست تشخیص دهد؟
• چند مورد بیمار را سالم طبقه‌بندی کرد؟
• چند هشدار کاذب صادر کرد؟
• آیا عملکرد در بیماری‌ها یا ارقام گوناگون متفاوت است؟
• آیا می‌تواند هنگامی که تصویر ناروشن است از اظهارنظر خودداری کند؟
• وقتی با موردی روبه‌رو می‌شود که در داده آموزش گنجانده نشده بود چه رخ می‌دهد؟

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

• محدودیت‌هایی بر سرعت و نیرو.
• یک ناحیه ایمنی پیرامون انسان‌ها و حیوانات.
• سازوکار توقف محلی که به ارتباط وابسته نباشد.
• راستی‌آزمایی اینکه اقدام موفق بوده است.
• توانایی بازگشت به وضعیت ایمن.
• اختیار روشن کارگر برای توقف یا نادیده‌گرفتن بهره‌برداری.

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

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

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

1. آیا پرسش بصری به شیوه‌ای صورت‌بندی شده است که با تصمیم لازم تناسب داشته باشد؟
2. آیا تصاویر نماینده شرایط واقعی مزرعه‌اند؟
3. آیا نتیجه از راه سامانه‌ای ایمن با مسئولیت روشن به اقدام ترجمه شده است؟

این امر خواننده را قادر می‌سازد میان سامانه‌ای که در آزمایشی کوتاه تصویری متقاعدکننده ارائه می‌کند و سامانه‌ای که واقعاً برای کارکرد زیر نور، گردوغبار، تنوع و محدودیت‌های ایمنی مزرعه آزموده شده است تمایز بگذارد.

5. مدل‌های احتمالاتی و استنتاج علّی: چه چیزی انتظار می‌رود، و مداخله چه چیزی را می‌تواند تغییر دهد؟

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

• عملکرد مورد انتظار در پایان فصل چقدر است؟
• احتمال بروز تنش آبی در روزهای آینده چقدر است؟
• احتمال اینکه نشانه‌ها با بیماری خاصی مرتبط باشند چقدر است؟
• در هفته آینده چه مقدار از تولید ممکن است به انبار برسد؟

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

پرسش دوم، در مقابل، این است: اگر چیزی را تغییر دهیم چه رخ خواهد داد؟ برای نمونه، ممکن است بپرسیم:

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

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

ممکن است توضیح‌های دیگری وجود داشته باشد، مانند اینکه:

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

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

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

1. مشاهده: چه رابطه‌ای در داده‌ها ظاهر شد؟
2. تفسیر: دلایل ممکن این رابطه چیست؟
3. مداخله: چه شواهدی وجود دارد که تغییر یک عامل معین نتیجه را تغییر خواهد داد؟

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

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

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

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

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

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

با رسیدن هر قطعه اطلاعات تازه، سامانه رتبه‌بندی احتمال‌ها را بازبینی می‌کند. ارزش در اینجا نه در سرعت نسبت‌دادن یک نام، بلکه در سامان‌دادن به آنچه می‌دانیم و آنچه نمی‌دانیم، و شناسایی سودمندترین قطعه اطلاعات بعدی نهفته است. احتمال، قطعیتی متقاعدکننده در قالب عدد نیست سامانه ممکن است بگوید: احتمال این وضعیت 80% است. اما این عدد چه معنایی دارد؟ به این معنا نیست که آن برگ به‌طور فردی «80% آلوده» است، و به این معنا هم نیست که 80% برگ آلوده است. اگر سامانه به‌خوبی کالیبره شده باشد، معنایش این است که وقتی به شمار زیادی از موارد مشابه احتمالی نزدیک به 80% نسبت می‌دهد، نتیجه باید در حدود هشتاد مورد از هر صد مورد رخ دهد، نه در همه موارد. سازگاری میان اعداد اطمینان و آنچه واقعاً رخ می‌دهد کالیبراسیون احتمال نامیده می‌شود. فرض کنید سامانه‌ای به صد مورد احتمالی نزدیک به 80% نسبت داده است:

• اگر نتیجه در حدود هشتاد مورد تأیید شود، اطمینان آن نسبتاً با واقعیت سازگار است.
• اگر تنها در پنجاه مورد تأیید شود، سامانه بیش از آنچه باید مطمئن است.
• اگر در نود و پنج مورد تأیید شود، سامانه شاید کمتر از آنچه نتایجش اقتضا می‌کند مطمئن باشد.

این مقایسه بر یک مورد منفرد انجام نمی‌شود، بلکه بر شمار مناسبی از موارد مشابه انجام می‌گیرد. رتبه‌بندی موارد به معنای درست بودن اعداد احتمال نیست سامانه ممکن است در رتبه‌بندی موارد از محتمل‌ترین تا کم‌احتمال‌ترین موفق باشد، اما در عین حال اعداد اطمینانی گمراه‌کننده نسبت دهد. موردی که به آن 90% داده است ممکن است واقعاً محتمل‌تر از موردی باشد که به آن 60% داده است، و از این حیث رتبه‌بندی سامانه سودمند است. اما اگر مواردی که به آن‌ها 90% داده است تنها در 65% مواقع تأیید شوند، آنگاه اعداد اطمینانش اغراق‌آمیزند. پس دو پرسش جداگانه در میان است:

1. آیا سامانه موارد را به شیوه‌ای سودمند رتبه‌بندی می‌کند؟
2. آیا اعداد احتمال تا اندازه‌ای پذیرفتنی بازتاب واقعیت‌اند؟

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

• رقم گیاهی.
• مرحله رشد.
• اقلیم.
• گستره انتشار آن وضعیت.
• دوربین یا حسگر.
• کیفیت تصویر.
• شیوه‌های مدیریت.
• نسبت موارد نادر و رایج.
• روش به‌کاررفته برای تأیید تشخیص.

بنابراین کافی نیست که تأمین‌کننده نشان دهد احتمال‌ها در داده‌های توسعه مناسب بوده‌اند. اطمینان باید پس از انتقال پایش شود، با نتایج واقعی مقایسه گردد، و در صورت نیاز بازکالیبره شود. اگر محیط جدید به‌گونه‌ای بنیادی متفاوت باشد، بازکالیبراسیون به‌طور خودکار مدل را مناسب نمی‌کند؛ ممکن است داده‌های جدید یا بازنگری در خودِ دامنه استفاده لازم باشد. نتیجه چگونه باید به کاربر ارائه شود؟ در حالت مطلوب، سامانه نباید عددی عریان یا پاسخی قطعی ارائه کند، بلکه باید نتیجه را در چهار لایه نمایش دهد: 1\. محتمل‌ترین نتیجه و عدم قطعیت برای نمونه: چند علت ممکن وجود دارد، و داده‌های کنونی برای تأیید هیچ‌یک از آن‌ها کافی نیست. یا: برآورد در محدوده‌ای معین قرار می‌گیرد و اگر وضع هوا یا مدیریت تغییر کند ممکن است تغییر کند. 2\. شواهدی که بر وزن‌دهی اثر گذاشته‌اند برای نمونه: احتمال تنش آبی به سبب قرائت‌های پایین رطوبت و دماهای بالا افزایش یافت، اما یکی از قرائت‌های حسگر مفقود است. 3\. اطلاعات مفقود و گام بعدی برای نمونه: پیش از آنکه بتوان احتمال‌ها را محدود کرد، باید حسگر بررسی شود، یا تصویری افزون بر آن لازم است، یا شرحی از توزیع نشانه‌ها، یا بازبینی متخصص. 4\. حدود تصمیم و مسئولیت برای نمونه: این نتیجه هشداری مقدماتی است، نه تشخیصی تأییدشده یا دستوری برای اجرای یک درمان. بدین‌سان، احتمال به ابزاری برای ساختاردهی یک تصمیم بدل می‌شود، نه عددی که به سامانه اقتداری می‌بخشد که از آن او نیست. نمونه‌ای عملی: پیش‌بینی عملکرد دستورالعملی برای افزایش آن نیست فرض کنید مدلی عملکرد را بر پایه موارد زیر پیش‌بینی می‌کند:

• نوع خاک.
• وضع هوا.
• رقم.
• زمان‌بندی عملیات.
• سوابق آبیاری.
• داده‌های فصل‌های پیشین.

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

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

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

• اکنون چه می‌گذرد؟ پرسشی سنجشی یا تشخیصی.
• بعداً احتمالاً چه رخ خواهد داد؟ پرسشی پیش‌بینانه.
• اگر مداخله کنیم چه تغییر خواهد کرد؟ پرسشی علّی که به شواهد قوی‌تری نیاز دارد.

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

6. بهینه‌سازی و پژوهش در عملیات

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

1. تصمیم‌هایی که می‌توان تغییرشان داد: چه زمانی آبیاری کنیم؟ خودرو چه مسیری را در پیش گیرد؟ کدام محموله نخست سرد شود؟
2. قیدهایی که نباید نادیده گرفته شوند: ظرفیت پمپ، زمان، موجودی، ایمنی، انرژی، نیروی کار، و مرزهای زراعی.
3. هدفی که می‌خواهیم بهبودش دهیم: کاهش آب، زمان یا ضایعات، یا ایجاد توازن میان چند هدف.

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

7. یادگیری تقویتی و کنترل: سامانه چگونه از یک توالی از کنش‌ها می‌آموزد؟

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

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

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

• دمای درون گلخانه.
• رطوبت.
• دمای بیرون.
• شدت نور خورشید.
• سرعت باد.
• وضعیت پنجره‌ها و فن‌ها.
• رطوبت بستر کشت.
• ساعت روز.
• وضعیت حسگرها و تجهیزات.

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

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

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

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

و امتیاز ممکن است در این موارد پایین بیاید:

• شرایط از حدود پذیرفتنی فراتر رود.
• سامانه بیش از نیاز انرژی یا آب مصرف کند.
• تجهیزات را مکرراً به‌گونه‌ای روشن و خاموش کند که فرسایش را شتاب دهد.
• حسگری معیوب را نادیده بگیرد.
• کنشی را برگزیند که به حدود ایمنی نزدیک می‌شود.

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

• شرایط گیاه.
• آب و انرژی.
• پایداری تجهیزات.
• ایمنی انسان و حیوان.
• حدود بهره‌برداری.
• هزینه تغییرات مکرر.
• توانایی بازگشت به حالت ایمن.
• مواردی که تصمیم باید به انسان واگذار شود.

قاعده اساسی: سامانه آنچه را در ذهن‌مان می‌خواهیم نمی‌آموزد؛ آنچه را در داده‌ها، امتیازها و قیدها بیان کرده‌ایم می‌آموزد. چرا جریمه محاسباتی برای حفاظت از ایمنی کافی نیست؟ طراح ممکن است به این فکر بیفتد که هنگام اجرای کنشی خطرناک توسط سامانه، امتیاز را پایین بیاورد. اما برخی کنش‌ها را از اساس نباید اجازه داد آزموده شوند، حتی اگر بعداً به امتیازی منفی بینجامند. برای نمونه، سامانه نباید مجاز باشد خطر قطع تهویه در شرایط دشوار را با اجرای آن کنش و به‌خطرانداختن گیاه بیاموزد. رباتی نیز نباید با یک‌بار برخورد با کارگر بیاموزد که نزدیک‌شدن به او ناایمن است. بنابراین باید میان این دو تمایز گذاشت:

• اهدافی که سامانه می‌تواند بهینه‌شان کند.
• حدود ایمنی که نباید از آن‌ها بگذرد.

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

• گذشتن از حد دمایی خطرناک.
• به‌کارانداختن ابزاری در حالی که انسانی در محدوده حرکت است.
• ادامه‌دادن در صورت از کار افتادن حسگرهای حیاتی.
• اجرای فرمانی با واحد یا مقداری خارج از حدود تأییدشده.
• ادامه حرکت پس از از دست دادن موقعیت یا ارتباط.
• از کار انداختن سازوکار توقف دستی.

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

1. یادگیری یا ارزیابی در شبیه‌سازی‌ای آغاز می‌شود که محیط را به‌قدر معقولی بازنمایی می‌کند.
2. از داده‌های تاریخی برای فهم آنچه در شرایط پیشین رخ داده است استفاده می‌شود، با در نظر داشتن اینکه این داده‌ها همه کنش‌های ممکن را پوشش نمی‌دهند.
3. سامانه در حالت پایشی آزموده می‌شود و کنش‌ها را پیشنهاد می‌دهد بی‌آنکه اجرایشان کند.
4. پیشنهادهایش با آنچه اپراتور انجام داده و آنچه پس از آن رخ داده مقایسه می‌شود.
5. به آزمایشی محدود در محدوده‌ای کم‌مخاطره منتقل می‌شود.
6. قیدهای مستقل و اختیار توقف انسانی فعال باقی می‌مانند.
7. بهره‌برداری تنها پس از پدیدار شدن شواهد کافی از ایمنی و پایداری گسترش می‌یابد.

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

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

اما اگر هدف صرفاً تشخیص یک بیماری در تصویر، پیش‌بینی عملکرد، یا صدور یک هشدار منفرد باشد، روش‌های دیگر ممکن است مناسب‌تر باشند. یادگیری تقویتی نباید صرفاً به این دلیل که تازه‌تر یا هیجان‌انگیزتر به گوش می‌رسد به کار گرفته شود. چه کسی درون سامانه کنترل چه می‌کند؟ در یک سامانه واقعی کشاورزی، چند کارکرد باید از هم جدا نگه داشته شوند: 1. اندازه‌گیری وضعیت حسگرها و دوربین‌ها اطلاعاتی درباره محیط و تجهیزات گردآوری می‌کنند. این اطلاعات ممکن است ناقص، با تأخیر، یا نادقیق باشد. 2. تخمین یا پیش‌بینی وضعیت ممکن است مدلی برای تخمین آنچه مستقیماً اندازه‌گیری نمی‌شود، یا برای پیش‌بینی آنچه ممکن است پس از انجام کنشی معین رخ دهد، به کار رود. 3. انتخاب کنش راهبرد کنترل، کنش پیشنهادی را با توجه به وضعیت، هدف و قیدها تعیین می‌کند. 4. بررسی ایمنی لایه‌ای مستقل بازبینی می‌کند که آیا کنش مجاز است، آیا داده‌ها کفایت می‌کنند، و آیا تجهیزات و محیط در وضعیتی ایمن‌اند. 5. اجرا فرمان‌ها به پنجره‌ها، فن‌ها، پمپ‌ها یا موتورها فرستاده می‌شود، و باید تأیید شود که فرمان واقعاً اجرا شده است، نه اینکه صرفاً ارسال شده باشد. 6. راستی‌آزمایی نتیجه سامانه آنچه را انتظار می‌رفت با آنچه پس از اجرا رخ داد مقایسه می‌کند. اگر دستگاه پاسخ ندهد، یا به شکلی متفاوت حرکت کند، این باید تشخیص داده شود. 7. نظارت انسانی انسان اختیار تأیید، توقف یا نادیده‌گرفتن را دارد، و می‌تواند هنگام از کار افتادن اپلیکیشن یا اتصال به بهره‌برداری دستی روشن بازگردد. این جداسازی اهمیت دارد زیرا موفقیت یک بخش موفقیت کل سامانه را ثابت نمی‌کند. نرم‌افزار ممکن است کنشی مناسب برگزیند، اما شیر پاسخ ندهد. شیر ممکن است فرمان را اجرا کند، اما حسگری که نتیجه را تأیید می‌کند معیوب باشد. اجزا ممکن است از نظر فنی کار کنند، اما خود هدف ناقص باشد. مقصود از یادگیری تقویتی عمیق چیست؟ یادگیری تقویتی عمیق همان یادگیری تقویتی است که از شبکه‌های عصبی عمیق بهره می‌گیرد تا به سامانه کمک کند وضعیت‌های پیچیده را بازنمایی کند، ارزش کنش‌ها را تخمین بزند، یا آن‌ها را برگزیند. و واژه «عمیق» به این معنا نیست که سامانه:

• محیط را به شیوه‌ای انسانی می‌فهمد.
• ایمن‌تر است.
• لزوماً به یک ربات نیاز دارد.
• به‌طور خودکار تصاویر را می‌بیند.
• برای استقرار میدانی مناسب است.
• از قواعد یا کنترل متعارف بهتر است.

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

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

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

• دمای درونی اندکی بالا رفته.
• رطوبت بالا.
• دمای بیرونی پایین‌تر.
• بادهای ملایم.
• نبود هیچ هشدار تجهیزات.

می‌تواند میان این‌ها انتخاب کند:

• رهاکردن اوضاع به همان حال.
• بازکردن جزئی پنجره.
• بازکردن بیشتر آن.
• روشن‌کردن فن.
• استفاده هم‌زمان از پنجره و فن.
• درخواست بازبینی کارگر.

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

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

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

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

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

1. اینکه اطلاعات در دسترس حقیقتاً وضعیت مربوط را توصیف کند.
2. اینکه امتیاز عددی هدف کشاورزی را بازنمایی کند بی‌آنکه آن را به عددی گمراه‌کننده فروبکاهد.
3. اینکه ایمنی در قواعدی مستقل باقی بماند که نباید نادیده گرفته شوند.
4. اینکه گذار از شبیه‌سازی به بهره‌برداری تدریجی و برگشت‌پذیر باشد.
5. اینکه انسان‌ها همچنان کسانی باقی بمانند که اختیار توقف سامانه و تأیید نهایی را دارند.

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

8. مدل‌های زبانی، تولید و بازیابی: از پرسش تا پاسخ مستند

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

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

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

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

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

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

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

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

بازیابی لزوماً پاسخ نهایی را صورت‌بندی نمی‌کند؛ بلکه مصالحی را می‌یابد که پاسخ از آن‌ها ساخته می‌شود. وقتی سامانه جست‌وجوی منابع را با صورت‌بندی پاسخ بر پایه آنچه بازیابی کرده ترکیب می‌کند، این گردش کار تولید تقویت‌شده با بازیابی نامیده می‌شود که معمولاً به RAG اختصار می‌یابد. در تولید تقویت‌شده با بازیابی چه رخ می‌دهد؟ گردش کار را می‌توان به شش مرحله ساده کرد:

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

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

• صورت‌بندی پرسش.
• مجموعه منابع در دسترس.
• شیوه سازمان‌دهی و نمایه‌گذاری آن‌ها.
• معیارهای جست‌وجو.
• بندهایی که به مدل ارائه می‌شود.
• دستورالعمل‌هایی که صورت‌بندی را مقید می‌کنند.
• توان سامانه برای خودداری از پاسخ هنگامی که پشتوانه کافی نمی‌یابد.

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

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

بنابراین، بازیابی نباید تنها بر شباهت واژگانی تکیه کند. جست‌وجو باید با اطلاعاتی از این دست محدود شود:

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

این شرط‌ها را گاه فیلترهای جست‌وجو می‌نامند. این‌ها قواعدی‌اند که مانع می‌شوند سامانه هر متنِ از نظر زبانی مشابه را مرتبط با پرسش تلقی کند. چه کسی منابع را تأیید می‌کند؟ عبارت «منابع تأییدشده» نباید مبهم بماند. باید بدانیم:

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

یک مقاله علمی می‌تواند به فهم یک پدیده یا یک یافته پژوهشی کمک کند، اما ثبت قانونی یک محصول را اثبات نمی‌کند. و دستورالعمل رسمی مصرف شرایط یک محصول ثبت‌شده را تعیین می‌کند، اما به‌خودی‌خود اثری اقتصادی و عمومی را اثبات نمی‌کند. و قیمتی که در یک بازار رسمی منتشر می‌شود ممکن است برای همان بازار و همان تاریخ درست باشد، اما لزوماً برابر با آنچه کشاورزی در منطقه‌ای دیگر پس از حمل و کارمزد دریافت می‌کند نیست. پس اعتبار یک منبع بسته به پرسش تغییر می‌کند. سه لایه همیشه کافی نیست سودمند است که یک پاسخ میان آنچه منابع می‌گویند، آنچه سامانه استنتاج کرده، و آنچه به تصمیم انسانی نیاز دارد تمایز بگذارد. اما در تصمیم‌های حساس کشاورزی، بهتر است پنج لایه ارائه شود: 1\. آنچه سامانه از پرسش فهمید برای نمونه: فهمیدم که درباره علت لکه‌هایی می‌پرسید که بر برگ‌های محصولی مشخص در مرحله رشد معینی پدیدار شده‌اند. این کار به کاربر فرصت می‌دهد پیش از ساخته‌شدن پاسخ، آن برداشت را تصحیح کند. 2\. آنچه منابع می‌گویند ادعایی که منبع از آن پشتیبانی می‌کند، همراه با نام منبع، تاریخ و دامنه آن ارائه می‌شود. 3\. آنچه سامانه از چند تکه اطلاعات کنار هم نهاده است اگر سامانه بیش از یک منبع را ترکیب کند یا رابطه‌ای را استنتاج کند، باید اعلام کند که این صورت‌بندی یا مقایسه خودِ اوست، نه نقل‌قولی مستقیم. 4\. آنچه ناشناخته می‌ماند مانند نبود تصویری روشن، نبود یک آزمون، ندانستن کشور، یا راستی‌آزمایی‌نشدن اینکه آیا سند هنوز معتبر است. 5\. آنچه به تصمیم انسانی یا مرجع صلاحیت‌دار نیاز دارد مانند تشخیص نهایی، انتخاب یک ماده تحت مقررات، تأیید دز مصرف، یا اجرای مداخله‌ای که ممکن است به محصول یا به مردم آسیب بزند. این کار مانع می‌شود اطلاعات پشتیبانی‌شده با استنتاج خودکار یا داوری حرفه‌ای درهم آمیخته شود. ارجاع تزئین نیست کاربر باید بتواند ارجاع را وارسی کند و رابطه آن را با پاسخ بفهمد. یک ارجاع خوب این موارد را روشن می‌کند:

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

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

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

سپس گام امن بعدی را پیشنهاد می‌دهد:

• درخواست تصویری اضافی.
• مشخص‌کردن موقعیت مکانی.
• ارائه نام محصول دقیقاً همان‌گونه که روی بسته آمده است.
• بررسی وضعیت ثبت.
• بازبینی دستورالعمل رسمی مصرف جاری.
• تماس با خدمات ترویج یا یک متخصص صلاحیت‌دار.

بدین‌سان، خودداری از پاسخ نه بن‌بست، بلکه مسیری روشن برای تکمیل شواهد می‌شود. نمونه‌ای از مسیری غیرمسئولانه کاربر می‌پرسد: «روی محصولم لکه‌هایی پدیدار شده؛ چه چیزی مصرف کنم؟» سامانه مستقیم پاسخ می‌دهد: «محصول X را با فلان دز مصرف کنید.» این پاسخ غیرمسئولانه است، زیرا از توصیفی کلی به یک ماده و یک دز می‌رسد بی‌آنکه بداند:

• محصول چیست.
• کشور کجاست.
• تشخیص چیست.
• مرحله رشد چیست.
• وضعیت ثبت چگونه است.
• دستورالعمل رسمی مصرف چیست.
• فاصله ایمنی چقدر است.
• آیا علت‌های دیگری برای این نشانه‌ها وجود دارد.
• آیا کاربر توان اجرای ایمن درمان را دارد.

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

• توضیح می‌دهد چرا اطلاعات ناکافی است.
• نشان می‌دهد بیش از یک تفسیر ممکن است.
• داده‌های مشخصی را درخواست می‌کند.
• روشن می‌کند سامانه چه می‌تواند بکند.
• مشخص می‌کند چه چیزی به منبعی رسمی یا به یک متخصص نیاز دارد.
• مانع می‌شود روانی زبانی به اقتدار درمانی ناموجه بدل شود.

نمونه‌ای دیگر: پرسشی درباره قیمت اگر کشاورزی بپرسد: «قیمت محصول من امروز چقدر است؟» کافی نیست که سامانه رقمی را بازیابی کند که نام محصول در آن آمده است. باید بداند:

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

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

• واحد اندازه‌گیری.
• نفی.
• دوره انتظار.
• نام آفت.
• محصول ثبت‌شده.
• درجه الزام.
• هشدار.
• حوزه صلاحیت قانونی.

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

• آیا سامانه محصول، موقعیت مکانی و معنای مقصود را تشخیص داد؟
• آیا اطلاعات مفقود را درخواست کرد؟

بازیابی

• آیا منبع مناسب را یافت؟
• آیا منبع قدیمی یا غیرمحلی را کنار گذاشت؟
• آیا بخشی را که به پرسش پاسخ می‌دهد بازیابی کرد؟

عبارت‌پردازی

• آیا پاسخ به آنچه منبع بیان می‌کند پایبند ماند؟
• آیا ادعایی بدون پشتیبان افزود؟
• آیا قیدها و عدم قطعیت را حفظ کرد؟

ارجاع‌دهی

• آیا خواننده می‌تواند به منبع دسترسی یابد؟
• آیا منبع واقعاً از آن جمله پشتیبانی می‌کند؟
• آیا تاریخ و وضعیت سند نمایش داده شده است؟

ایمنی

• آیا سامانه هنگام ناکافی‌بودن شواهد از ارائه دز یا تشخیص خودداری کرد؟
• آیا روشن کرد چه زمانی باید با متخصص یا مرجع مقرراتی مشورت شود؟
• آیا مانع شد اطلاعات عمومی به دستورالعملی قابل اجرا بدل شود؟

کاربرد کشاورزی

• آیا پاسخ برای آن محصول، موقعیت مکانی و زمان معتبر است؟
• آیا کاربر می‌تواند آن را بفهمد و اجرا کند؟
• آیا مسئولیت انسانی روشن باقی ماند؟

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

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

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

9. هوش مصنوعی توضیح‌پذیر

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

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

اما این ابزارها به همه معانی واژه «چرا» پاسخ نمی‌دهند. آن‌ها معمولاً توضیح می‌دهند چرا مدل بنا بر محاسباتش این خروجی را تولید کرده است، اما لزوماً اثبات نمی‌کنند چرا آن پدیده در مزرعه رخ داده است. سه پرسش متفاوت درون واژه «چرا» پنهان است وقتی کاربر می‌پرسد «چرا؟»، ممکن است یکی از این سه پرسش را در نظر داشته باشد: 1\. چرا مدل این خروجی را تولید کرد؟ این پرسشی درباره رفتار مدل است. پاسخ ممکن است چنین باشد: مدل برآورد مخاطره را بالا برد چون قرائت رطوبت افت کرد، دمای پیش‌بینی‌شده بالا رفت، و هیچ قرائت تازه‌ای از یکی از حسگرها نرسید. این پاسخ نشان می‌دهد مدل از چه اطلاعاتی استفاده کرده است. 2\. چرا آن پدیده کشاورزی رخ داد؟ این پرسشی درباره واقعیت کشاورزی است. پاسخی ممکن چنین است: شاید رطوبت افت کرد چون تقاضای آب بالا رفت، یا چون آبیاری به‌درستی به آن بخش نمی‌رسید، یا به سبب مشکلی در خاک، یا به سبب خطای حسگر. ابزار تفسیر مدل به‌تنهایی نمی‌تواند تعیین کند کدام‌یک از این علت‌ها درست است. اینکه مدل از قرائت رطوبت استفاده کرده، علت افت آن را اثبات نمی‌کند، و نیز اثبات نمی‌کند که گیاه واقعاً زیر تنش است. 3\. چرا باید این اقدام را انجام دهیم؟ این پرسشی درباره تصمیم است. حتی اگر هشدار مدل معقول باشد، به‌طور خودکار نتیجه نمی‌شود که اقدام درست افزایش آبیاری است. ممکن است حسگر معیوب باشد، ممکن است بارش در راه باشد، ممکن است مشکل در رسیدن آب تنها به ناحیه‌ای محدود باشد، یا ممکن است مرحله رشد محصول با آنچه سامانه فرض کرده متفاوت باشد. پس باید میان این موارد تمایز گذاشت: توضیح خروجی مدل ← توضیح وضعیت کشاورزی ← توجیه اقدام و حرکت از هر سطح به سطح بعدی نیازمند داده و شواهد افزون‌تر است. توضیح برای چه کسی است؟ هیچ توضیح واحدی وجود ندارد که برای همه کاربران کارساز باشد. هر طرف به سطحی متفاوت نیاز دارد. توسعه‌دهنده می‌خواهد بداند:

• آیا مدل بر داده‌های معتبر تکیه کرده است؟
• آیا میان‌بری نادرست آموخته است؟
• آیا به‌جای گیاه بر پس‌زمینه تصویر متمرکز شده است؟
• آیا رفتار آن پس از به‌روزرسانی داده تغییر کرده است؟
• آیا خروجی در برابر تغییری اندک در ورودی پایدار است؟

متخصص کشاورزی می‌خواهد بداند:

• آیا عواملی که مدل به کار برده از نظر کشاورزی معنادارند؟
• آیا متغیری مهم را نادیده گرفته است؟
• آیا رابطه‌ای آماری را با علتی کشاورزی اشتباه گرفته است؟
• آیا نتیجه برای این رقم، فصل و موقعیت مکانی محتمل است؟
• چه اندازه‌گیری یا آزمونی می‌تواند آن را تأیید یا رد کند؟

کشاورز یا بهره‌بردار به پاسخی عملی نیاز دارد:

• سامانه چه گفت؟
• نتیجه بر چه اطلاعاتی استوار بود؟
• آیا این اطلاعات جاری و قابل اطمینان است؟
• سامانه چه چیزی را نمی‌داند؟
• گام امن بعدی چیست؟

بازبین یا مرجع مسئول به سابقه‌ای قابل حسابرسی نیاز دارد:

• نسخه مدل چیست؟
• در زمان تصمیم چه داده‌هایی در دسترس بود؟
• چه قواعد یا محدودیت‌هایی اعمال شد؟
• آیا انسانی نتیجه را لغو کرد؟ چرا؟
• آیا منبع یا حسگر در آن زمان معتبر بود؟

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

• مدل معمولاً بر چه نوع اطلاعاتی تکیه می‌کند؟
• آیا با تغییر متغیری معین، پیش‌بینی عملکرد بالا می‌رود یا پایین می‌آید؟
• آیا رفتار آن میان ارقام یا مناطق متفاوت است؟
• کدام متغیرها به‌کرات در میان عوامل مؤثر ظاهر می‌شوند؟
• آیا با نبودِ نوع معینی از داده تضعیف می‌شود؟

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

• رطوبت پایین خاک: برآورد مخاطره را افزایش داد.
• دمای پیش‌بینی‌شده بالا: برآورد را افزایش داد.
• احتمال بارش: برآورد را کاهش داد.
• نبود قرائت اخیر: اطمینان را کاهش داد.

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

• لکه مربوطه.
• لبه برگ.
• پس‌زمینه تصویر.
• برچسبی که کنار گیاه قرار گرفته است.
• سایه یا بازتابی بی‌ارتباط با آن وضعیت.

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

• آیا نمونه‌های پیشین مستند شده‌اند؟
• آیا از محصول، رقم و محیطی مشابه آمده‌اند؟
• آیا شباهت در نشانه‌هاست یا در پس‌زمینه و نورپردازی؟
• آیا نمونه‌های مشابهی وجود دارد که به نتیجه‌ای متفاوت انجامیده باشد؟

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

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

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

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

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

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

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

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

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

• نوع خاک.
• سامانه آبیاری.
• وضع هوا.
• مرحله رشد.
• مدیریت مزرعه.
• رقم.

برای تعیین اثر یک مداخله خاص، به آزمایش یا طرحی علّی نیاز داریم، همراه با دانش کشاورزی مناسب، چنان‌که بخش پیشین توضیح داد. یک قاعده کلیدی: توضیح‌پذیری مدل به ما می‌گوید محاسبه آن چگونه تغییر کرد، نه اینکه اگر یکی از ورودی‌ها را تغییر دهیم مزرعه لزوماً چگونه تغییر خواهد کرد. محدودیت‌های استنتاج از مطالعه پیش‌بینی عملکرد مطالعه پیش‌بینی عملکرد [SRC006] نمونه‌ای از کاربرد مدل‌های رگرسیون همراه با ابزارهایی به دست می‌دهد که به تفسیر نتایج آن‌ها در یک چارچوب پژوهشی مشخص کمک می‌کنند. از این مطالعه می‌توان برای فهم موارد زیر استفاده کرد:

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

اما رتبه‌بندی متغیرها یا اهمیت آن‌ها در مطالعه را نباید به قاعده‌ای علّی و عام برای هر مزرعه بدل کرد. اگر متغیری خاص در پیش‌بینی مدل اثرگذار به نظر برسد، این ثابت نمی‌کند:

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

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

1. نتیجه چیست؟

سامانه دقیقاً چه گفت؟

2. بر چه اطلاعاتی تکیه کرد؟

کدام قرائت‌ها، تصاویر یا سوابق بر نتیجه اثر گذاشتند؟

3. وضعیت این اطلاعات چگونه است؟

آیا تازه، کامل و کالیبره‌اند، یا قرائتی قدیمی یا مفقود در کار است؟

4. درجه عدم قطعیت چقدر است؟

آیا نتیجه روشن است، نزدیک به آستانه است، یا بیرون از دامنه تجربه مدل قرار دارد؟

5. توضیح چه چیزی را اثبات نمی‌کند؟

آیا نتیجه یک هشدار مقدماتی است، یک تشخیص، یا صرفاً یک پیش‌بینی؟

6. گام بعدی ایمن چیست؟

پیش از تغییر تصمیم، چه اندازه‌گیری، بازرسی یا بازبینی‌ای لازم است؟

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

• که سخن بر سر برآورد مدل است، نه علتی تأییدشده.
• کدام داده‌ها بر برآورد اثر گذاشته‌اند.
• که یکی از ورودی‌های داده ناقص است.
• که این کمبود چگونه بر اطمینان اثر می‌گذارد.
• که گام بعدی چیست.
• که تعدیل آبیاری به دستوری خودکار بدل نشده است.

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

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

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

• علتی تأییدشده.
• وعده‌ای درباره عملکرد.
• توصیه‌ای برای مداخله.
• تعمیمی فراتر از دامنه آزمون.

چه زمانی توضیح کافی نیست؟ در این موارد نباید تنها بر توضیح تکیه کرد:

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

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

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

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

• مدل از چه اطلاعاتی استفاده کرد؟
• آیا آن اطلاعات دقیق و به‌روز بود؟
• آیا بر آنچه قرار بود بر آن متمرکز شود متمرکز شد؟
• چه چیزی را به حساب نیاورد؟
• محدودیت‌های اطمینان آن چیست؟
• و پیش از اقدام چه چیزی باید راستی‌آزمایی شود؟

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

10. سامانه کشاورزی هوشمند سامانه‌ای یکپارچه است، نه مدلی مستقل

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

1. گردآوری اطلاعات:

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

2. بررسی کیفیت داده:

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

3. شکل‌دادن به یک برآورد یا پیش‌بینی:

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

4. اعمال قواعد کشاورزی و مقرراتی:

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

5. سنجیدن جایگزین‌های در دسترس:

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

6. ارائه نتیجه، مبنا و محدودیت‌های آن:

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

7. بازبینی یا اجرا:

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

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

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

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

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

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

11. راهنمایی مقدماتی برای پیوند دادن وظیفه، روش و راستی‌آزمایی

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

1. وظیفه: می‌خواهیم به چه پرسش کشاورزی‌ای پاسخ دهیم؟
2. داده: برای پاسخ به آن چه اطلاعاتی لازم است؟
3. خانواده روش: چه نوع تحلیلی می‌تواند به آن پرسش بپردازد؟
4. خروجی: سامانه باید چه نتیجه‌ای فراهم کند؟
5. معیار عملکرد: از کجا بدانیم نتیجه سودمند است و نه صرفاً خوش‌ظاهر؟
6. پرسش ایمنی و راستی‌آزمایی: پیش از آنکه نتیجه به تصمیم یا کنش بدل شود چه چیزی باید بررسی شود؟

پاسخ به این پرسش‌ها تا زمانی که محصول، محیط، زمان‌بندی تصمیم، هزینه خطا، و توان کاربر برای پاسخ‌دهی مشخص نشده باشد کامل نیست. 1. طبقه‌بندی وضعیت یک برگ از روی تصویر وظیفه: تعیین اینکه کدام دسته بهتر با تصویر برگ مطابقت دارد، مانند سالم، مبتلا به وضعیتی خاص، یا نامعین. داده لازم: تصاویر متنوع از بافت سالم و وضعیت‌های بیمار، که هر یک به دسته مرجعی راستی‌آزمایی‌شده توسط متخصص یا آزمونی قابل اتکا پیوند خورده باشد. کافی نیست تصاویر صرفاً پرشمار باشند؛ باید تنوع در ارقام، مراحل رشد، نورپردازی، دستگاه‌های تصویربرداری، و شدت علائم را نیز بازنمایی کنند. خانواده روش: مدل‌های طبقه‌بندی تصویر. خروجی موردنظر: نام محتمل‌ترین وضعیت و یک امتیاز اطمینان، همراه با این گزینه که سامانه بگوید «نامعین» یا هنگام ناکافی بودن شواهد تصویری اضافی درخواست کند. چه چیزی را می‌سنجیم؟ نرخ موفقیت کلی کافی نیست. باید توان سامانه در تشخیص هر وضعیت مهم، شمار مواردی که از دست می‌دهد، شمار هشدارهای کاذب، و مواردی که با یکدیگر اشتباه می‌گیرد را بسنجیم. پرسش ایمنی و راستی‌آزمایی: اگر سامانه با بیماری‌ای مواجه شود که نیاموخته است، با علائمی که از بیش از یک علت ناشی می‌شوند، یا با تصویری بی‌کیفیت، چه می‌کند؟ آیا موارد نامشخص را به متخصص ارجاع می‌دهد، یا آن‌ها را به زور در یکی از دسته‌های شناخته‌شده جای می‌دهد؟ 2. تعیین محل علف هرز در آماده‌سازی برای برخورد با آن وظیفه: تشخیص علف هرز در تصویر و تعیین محل آن با دقتی کافی برای هدایت یک کارگر یا یک ماشین به سوی آن. داده لازم: تصاویر یا کلیپ‌های ویدئویی که محل علف‌های هرز و محصول را نشان می‌دهند، همراه با برچسب‌گذاری مرجع موقعیت‌هایشان. اگر قرار باشد سامانه ماشینی را هدایت کند، به اطلاعات کالیبراسیون نیز نیاز دارد که موقعیت جسم در تصویر را به موقعیت واقعی آن در برابر ادوات پیوند دهد. خانواده روش: کار با تشخیص اشیا یا ترسیم مرزهای اشیا درون تصویر آغاز می‌شود؛ سپس نتیجه به سامانه کنترلی می‌رسد که حرکت ادوات را تعیین می‌کند. خروجی موردنظر: محل علف هرز، مرزهای آن، و امتیاز اطمینان تشخیص آن، و پس از آن مختصاتی که ماشین بتواند به‌موقع از آن استفاده کند. چه چیزی را می‌سنجیم؟ می‌سنجیم که کدام علف‌های هرز تشخیص داده شدند و کدام‌ها از دست رفتند، دقت تعیین محل آن‌ها، سرعت رسیدن نتیجه، و شمار بوته‌های محصول که در حین اجرا آسیب دیدند. پرسش ایمنی و راستی‌آزمایی: آیا ادوات در صورت از دست رفتن اطمینان سامانه، ورود انسان یا حیوان به محدوده کار، یا ناممکن شدن تمایز علف هرز از محصول متوقف می‌شود؟ و آیا کل زنجیره، از دوربین تا حرکت ادوات، آزمایش شده است، نه فقط مدل تصویر؟ 3. پیش‌بینی عملکرد وظیفه: برآورد مقدار محصولی که انتظار می‌رود از مساحتی مشخص برداشت شود. داده لازم: اندازه‌گیری‌های پیشین عملکرد، و داده‌های هواشناسی، خاک، رقم، مرحله رشد، و شیوه‌های کشاورزی، با بیان روشن منبع هر مقدار و واحد اندازه‌گیری آن. خانواده روش: مدل‌های رگرسیون، یا مدل‌هایی که چگونگی تغییر داده‌ها در طول زمان را مطالعه می‌کنند؛ اگر شرایط درون مزرعه یا میان مناطق متفاوت باشد ممکن است مدل‌های مکانی نیز افزوده شود. خروجی موردنظر: برآوردی از عملکرد در واحدی قابل فهم، مانند کیلوگرم در هکتار، همراه با بازه‌ای که درجه عدم قطعیت را نشان دهد، به‌جای عددی یگانه که دقتی کاذب را القا می‌کند. چه چیزی را می‌سنجیم؟ خطا با همان واحد عملکرد سنجیده می‌شود، و در عین حال بررسی می‌شود که آیا بازه‌های اطمینان اعلام‌شده با نتایج واقعی همخوانی دارند. اگر سامانه بگوید که عملکرد احتمالاً در بازه‌ای معین قرار می‌گیرد، باید آزمود که این امر در عمل چند بار رخ می‌دهد. پرسش ایمنی و راستی‌آزمایی: آیا مدل روی مزارع، فصل‌ها، یا مناطقی که بخشی از آموزش آن نبوده‌اند آزمایش شده است؟ و آیا کاربر می‌فهمد که پیش‌بینی بر شرایط گذشته مبتنی است که ممکن است بازنمای فصلی استثنایی یا رقمی جدید نباشد؟ 4. تهیه برنامه زمان‌بندی آبیاری وظیفه: تعیین اینکه بخش‌ها چه زمانی باید آبیاری شوند و هر بخش چقدر آب دریافت کند، با در نظر گرفتن نیازهای محصول و ظرفیت شبکه آبیاری. داده لازم: رطوبت خاک، وضع هوا، مرحله رشد محصول، ویژگی‌های خاک، منابع آب، ظرفیت پمپ، وضعیت شیرها، و محدودیت‌های زمانی و عملیاتی. خانواده روش: سامانه ممکن است مدلی که نیاز آبی را پیش‌بینی می‌کند، قواعد کشاورزی که از تصمیم‌های ناایمن جلوگیری می‌کنند، و برنامه‌ای رایانه‌ای برای برنامه‌ریزی که گزینه‌ها را مقایسه کرده و منابع در دسترس را تخصیص می‌دهد با هم ترکیب کند. خروجی موردنظر: برنامه‌ای قابل اجرا که بخش، زمان، مقدار و مدت کارکرد را مشخص کند، همراه با برنامه‌ای جایگزین در صورت کمیاب شدن آب یا از کار افتادن یکی از تجهیزات. چه چیزی را می‌سنجیم؟ موفقیت تنها با کاهش مصرف آب سنجیده نمی‌شود، بلکه با وضعیت گیاه، عملکرد، مصرف انرژی، یکنواختی توزیع، زمان‌بندی رساندن آب، و اینکه آیا برنامه با تجهیزات در دسترس قابل اجراست نیز سنجیده می‌شود. پرسش ایمنی و راستی‌آزمایی: وقتی داده‌ها قطع می‌شوند یا یکی از حسگرها از کار می‌افتد چه رخ می‌دهد؟ آیا سامانه به حالت دستی یا برنامه اضطراری ایمن تغییر وضعیت می‌دهد، یا بر پایه اطلاعات ناقص به صدور فرمان ادامه می‌دهد؟ 5. صدور هشدار درباره وضعیت یک حیوان وظیفه: تشخیص تغییری که ممکن است نشانه بیماری، آسیب، یا اختلال در حرکت یا تغذیه باشد. داده لازم: داده‌ها ممکن است صداها، تصاویر، کلیپ‌های ویدئویی، یا قرائت‌های فعالیت، دما و میزان خوراک مصرفی باشند. این داده‌ها باید تا حد امکان به مواردی پیوند بخورند که دامپزشک یا متخصص دیگری بازبینی کرده است. خانواده روش: تشخیص موارد غیرعادی هنگامی که تعریفی کامل از هر بیماری در اختیار نداریم، یا طبقه‌بندی هنگامی که موارد مستندی داریم که سامانه می‌تواند از آن‌ها بیاموزد. خروجی موردنظر: هشداری که حیوان، زمان، و دلیل نگرانی را مشخص کند، با رتبه‌بندی هشدارها بر حسب اولویت. چه چیزی را می‌سنجیم؟ شمار موارد مهمی که سامانه در تشخیصشان ناکام مانده است، شمار هشدارهای کاذب به ازای هر حیوان یا هر روز، و فاصله زمانی میان آغاز تغییر و صدور هشدار. پرسش ایمنی و راستی‌آزمایی: چه کسی پیش از درمان وضعیت را از نظر حرفه‌ای تأیید می‌کند؟ و تیم عملاً می‌تواند چند هشدار را بررسی کند؟ سامانه‌ای که صدها هشدار رتبه‌بندی‌نشده می‌فرستد ممکن است مورد خطرناک را در میان نوفه پنهان کند. 6. برآورد مساحت علائم و پیگیری گسترش آن‌ها وظیفه: اندازه‌گیری مساحت مبتلا در گیاه یا مزرعه، سپس تعیین اینکه آیا علائم در طول زمان گسترش می‌یابند یا عقب می‌نشینند. داده لازم: تصاویر یا نقشه‌های متوالی که در زمان‌های مختلف گرفته شده‌اند، همراه با اطلاعاتی درباره موقعیت، ارتفاع، زاویه و شرایط نوری تصویربرداری، تا مقایسه‌ای منصفانه ممکن شود. خانواده روش: ترسیم مرزهای بافت‌ها یا نواحی مبتلا درون تصویر، سپس تحلیل چگونگی تغییر آن‌ها در نقاط زمانی مختلف. خروجی موردنظر: مساحت یا درصد برآوردی آسیب، جهت و سرعت تغییر، همراه با نشانه‌ای از درجه اطمینان به آن مقایسه. چه چیزی را می‌سنجیم؟ خطا در برآورد مساحت، پایداری نتیجه هنگام تکرار تصویربرداری، و توان سامانه در ردیابی همان ناحیه از زمانی به زمان دیگر. پرسش ایمنی و راستی‌آزمایی: آیا آسیب واقعاً افزایش یافته، یا نور، زاویه تصویربرداری، یا ارتفاع دوربین تغییر کرده و مساحت را بزرگ‌تر یا کوچک‌تر جلوه داده است؟ و آیا تصاویر بر پایه یک استاندارد مرجع واحد مقایسه می‌شوند؟ 7. ارائه پاسخ مشاوره‌ای وظیفه: پاسخ‌دادن به پرسشی کشاورزی به زبانی روشن، با تکیه بر منابع معتبر متناسب با زمینه کاربر. داده لازم: پرسش کاربر، اطلاعاتی درباره محصول، مکان، مرحله رشد و وضعیت، همراه با منابع قابل اتکا و به‌روز که سامانه بتواند به آن‌ها رجوع کند. خانواده روش: جست‌وجو در منابع معتبر و بازیابی بندهای مرتبط، سپس استفاده از یک مدل زبانی برای صورت‌بندی پاسخ، با قواعدی که از ادعاها یا توصیه‌هایی که شواهد از آن‌ها پشتیبانی نمی‌کند جلوگیری کند. خروجی موردنظر: پاسخی که میان اطلاعات عمومی و توصیه‌ای مشروط تمایز بگذارد، منابع خود را ذکر کند، و هنگام ناکافی بودن شواهد اطلاعات بیشتری بخواهد یا از پاسخ‌دادن خودداری کند. چه چیزی را می‌سنجیم؟ آیا منابع از ادعاهای مطرح‌شده در پاسخ پشتیبانی می‌کنند؟ آیا ارجاعات دقیق و قابل راستی‌آزمایی‌اند؟ آیا پاسخ با محصول، مکان و زمان‌بندی تناسب دارد، و آیا کاربر می‌تواند گام بعدی را بفهمد بدون آنکه به سوی کنشی ناایمن رانده شود؟ پرسش ایمنی و راستی‌آزمایی: آیا سامانه از ساختن دز، ماده، ثبت رسمی، یا قیمتی مستندنشده خودداری می‌کند؟ آیا روشن می‌سازد که تأیید یک محصول یا شرایط استفاده از آن باید با برچسب معتبر و جاری محصول و مقررات محلی راستی‌آزمایی شود؟ 8. تخصیص یک منبع محدود وظیفه: توزیع مقدار محدودی آب، کود، نیروی کار، یا زمان ماشین میان چند مزرعه یا بخش. داده لازم: میزان تقاضا، منابع در دسترس، اولویت‌ها، محدودیت‌های فنی و زمانی، و پیش‌بینی‌های مربوط به عملکرد، هزینه، یا بازده. خانواده روش: برنامه‌ریزی ریاضی و موازنه میان گزینه‌ها، که در حوزه‌های تخصصی به بهینه‌سازی و تحقیق در عملیات شناخته می‌شود. این روش‌ها در پی برنامه‌ای‌اند که هدف را تا حد امکان محقق کند بدون آنکه محدودیت‌های تعیین‌شده را نقض کند. خروجی موردنظر: برنامه‌ای قابل اجرا، همراه با بیان اینکه هر طرف چه دریافت می‌کند و در صورت تغییر اولویت‌ها یا کمیاب‌تر شدن منبع چه چیزی تغییر می‌کند. چه چیزی را می‌سنجیم؟ آیا برنامه همه محدودیت‌ها را رعایت کرد؟ آیا واقعاً قابل اجراست؟ و اثر آن بر هزینه، عملکرد، زمان، و انصاف میان بخش‌ها یا ذی‌نفعان چیست؟ پرسش ایمنی و راستی‌آزمایی: چه کسی هدفی را که ابزار می‌کوشد بیشینه کند تعیین کرده است؟ و چه کسی اولویت‌ها و حداقل سطح پذیرفتنی برای هر بخش را تعیین کرده است؟ ممکن است برنامه‌ای از نظر ریاضی درست باشد اما اگر هدف به یک عدد یگانه فروکاسته شود، ناعادلانه یا از نظر کشاورزی ناپذیرفتنی باشد. 9. کنترل توالی‌ای از کنش‌ها وظیفه: انتخاب توالی‌ای از کنش‌ها که پس از آن وضعیت سامانه تغییر می‌کند، مانند تنظیم تهویه و گرمایش در یک سازه گلخانه‌ای، یا هدایت ماشینی متحرک میان ردیف‌های محصول. داده لازم: توصیفی از وضعیت کنونی، مجموعه کنش‌های ممکن، و داده‌هایی درباره آنچه پس از هر کنش رخ داده است، همراه با حدود عملیاتی و ایمنی. خانواده روش: سامانه ممکن است از کنترل متعارف مبتنی بر قواعد و معادلات شناخته‌شده، یادگیری تقویتی که راهبرد انتخاب کنش را از شبیه‌سازی یا تجربه می‌آموزد، یا ترکیبی از این دو استفاده کند. خروجی موردنظر: راهبردی که کنش مناسب برای هر وضعیت را تعیین کند، و پس از آن فرمان‌های عملیاتی روشن برای تجهیزات. در اصطلاح فنی، به این راهبرد «سیاست انتخاب کنش» گفته می‌شود. چه چیزی را می‌سنجیم؟ پایداری سامانه، سرعت پاسخ آن، شمار دفعاتی که محدودیت‌ها نقض می‌شوند، مصرف منابع، اثر کنش‌ها بر گیاه، حیوان یا تجهیزات، و توان آن در مواجهه با شرایط غیرمنتظره. پرسش ایمنی و راستی‌آزمایی: سامانه، هدف هرچه باشد، مجاز به فراتر رفتن از چه حدودی نیست؟ چه کسی اختیار توقف آن را دارد؟ و اگر ارتباط قطع شود، داده‌ها از کار بیفتند، یا وضعیت بیرون از دامنه آزمایش‌شده قرار گیرد، تجهیزات به چه وضعیت ایمنی منتقل می‌شوند؟ این نقشه نشان می‌دهد که یک وظیفه کشاورزی واحد ممکن است به بیش از یک روش نیاز داشته باشد، و اینکه موفقیت در هر مرحله موفقیت کل زنجیره را تضمین نمی‌کند. تعیین محل علف هرز کافی نیست اگر ماشین نتواند با ایمنی به آن برسد؛ پیش‌بینی تقاضای آب کافی نیست اگر برنامه آبیاری از ظرفیت پمپ فراتر رود؛ و بازیابی منبعی درست کافی نیست اگر مربوط به محصول، کشور یا تاریخی دیگر باشد. همچنین نشان می‌دهد که معیار فنی و پرسش ایمنی دو موضوع جدا از هم نیستند. معیار نشان می‌دهد که سامانه در آزمون چقدر خوب عمل می‌کند، حال آنکه پرسش ایمنی نشان می‌دهد وقتی سامانه در مزرعه خطا می‌کند چه ممکن است رخ دهد. ممکن است الگوریتمی به نتیجه میانگین بالایی دست یابد، در حالی که خطای نادر آن در پرمخاطره‌ترین مورد رخ دهد. برای خواننده‌ای که در پی ژرفاست: انتخاب روش با صورت‌بندی تصمیم و هزینه الگوهای مختلف خطا آغاز می‌شود، نه با مقایسه نام مدل‌ها. روش مناسب ممکن است با تغییر خروجی موردنظر تغییر کند، حتی وقتی داده‌ها همان باقی می‌مانند. سامانه را همچنین باید در سه سطح ارزیابی کرد: کیفیت برآورد، کیفیت تبدیل آن برآورد به تصمیم، و کیفیت اجرای تصمیم در واقعیت. بهبود در سطح نخست جبران‌کننده شکست در دو سطح دیگر نیست. و هنگام ارزیابی هر کاربرد جدید، می‌توان این ماتریس را در پرسش‌های زیر خلاصه کرد:

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

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

12. مدل‌ها و سامانه‌ها را چگونه مقایسه کنیم؟ از دقت آزمون تا ارزش در مزرعه

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

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

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

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

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

• میزان بهبود نسبت به روش کنونی.
• پایداری آن بهبود در مزارع و فصل‌های گوناگون.
• انواع خطاهایی که کاهش یا افزایش یافته‌اند.
• هزینه دستیابی به آن بهبود.
• میزانی که کاربر واقعاً می‌تواند از آن بهره ببرد.

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

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

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

• سامانه چند مورد خطرناک را از دست داد؟
• چند هشدار کاذب صادر کرد؟
• در کدام ارقام یا مراحل رشد خطاها بیشتر است؟
• آیا در موارد اولیه بیشتر از موارد آشکار اشتباه می‌کند؟
• هزینه هر نوع خطا چقدر است؟
• آیا تیم می‌تواند شمار هشدارهای حاصل را اداره کند؟

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

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

در پیش‌بینی عملکرد، گفتن اینکه عملکرد مورد انتظار میان 4.2 و 5.1 تن در هکتار است ممکن است صادقانه‌تر و سودمندتر از دادن رقمی واحد معادل 4.7 تن باشد، به‌ویژه اگر داده‌های آتی وضع هوا ناپایدار باشند. در تشخیص تصویر یک برگ، شاید مناسب‌تر باشد که سامانه بگوید تصویر برای تمایزگذاری میان دو علت کافی نیست، و سپس تصویری از پشت برگ درخواست کند. اما امتیاز اطمینانی که مدل نمایش می‌دهد حقیقتی تضمین‌شده نیست. ممکن است بگوید 80% اطمینان دارد در حالی که نتایج واقعی‌اش بسیار بدتر باشد. به همین سبب کالیبراسیون اطمینان بررسی می‌شود: آزمودن اینکه آیا اعداد اطمینان با واقعیت هم‌راستا هستند. اگر شمار زیادی از مواردی را گرد آوریم که سامانه به آنها اطمینان حدود 80% نسبت داده است، نتایج آن باید با نرخی نزدیک به همان درست باشد، نه اینکه تنها در نیمی از آنها درست باشد. موردی بیرون از دامنه آنچه سامانه آموخته است موردی است که آشکارا با نمونه‌های آموزشی آن تفاوت دارد: رقمی جدید، دوربینی متفاوت، بیماری‌ای که در داده‌ها نبوده، شرایط نوری‌ای که به‌شدت متفاوت است، یا پرسشی به زبانی که بر آن آزموده نشده است. مدل ممکن است حتی در چنین مواردی با اطمینان پاسخ دهد، و به همین سبب باید توان آن در تشخیص ناآشنابودن یک ورودی آزموده شود. خودداری به این معناست که سامانه هنگامی که شواهد کافی نیست، خود را به صدور تشخیص یا توصیه وادار نمی‌کند. این نه توقفی تصادفی است و نه نشانه شکست، بلکه رفتاری عامدانه است، مانند گفتن اینکه: «تصویر کنونی برای تعیین ایمن وضعیت کافی نیست. تصویری روشن‌تر از پشت برگ بگیرید و محصول و مرحله رشد را مشخص کنید، یا مورد را به متخصص ارجاع دهید.» خود خودداری نیز باید ارزیابی شود. اگر سامانه در بیشتر موارد خودداری کند، ممکن است ایمن به نظر برسد اما سود اندکی داشته باشد. اگر هرگز خودداری نکند، ممکن است در مواردی که نمی‌داند پاسخ‌هایی مطمئن بدهد. آنچه لازم است موازنه‌ای متناسب با حساسیت وظیفه و ظرفیت تیم برای بازبینی موارد ارجاع‌شده است. معنای عملی عدم قطعیت و خودداری: تنها نمی‌پرسیم که آیا سامانه پاسخ داد، بلکه می‌پرسیم که آیا مرزهای شواهد خود را بازشناخت، آیا در زمان درست درخواست کمک کرد، و آیا آن درخواست به کسی رسید که بتواند پیگیری کند. ه. عملکرد سامانه را در بهره‌برداری بسنجیم، نه فقط در نمایش ممکن است سامانه‌ای در نمایشی عمومی و کوتاه، یا روی رایانه‌ای قدرتمند متصل به شبکه‌ای پایدار، خوب کار کند و سپس هنگام استفاده روزبه‌روز در مزرعه با دشواری روبه‌رو شود. به همین سبب، مقایسه جنبه‌هایی را در بر می‌گیرد که در یک عدد دقت نمایان نمی‌شوند، مانند:

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

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

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

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

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

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

1. آیا برآورد مدل درست بود؟
2. آیا سامانه آن را به هشدار یا توصیه‌ای روشن بدل کرد؟
3. آیا نتیجه در زمان درست رسید؟
4. آیا کاربر آن را فهمید و به آن اعتماد کرد؟
5. آیا تصمیم را تغییر داد؟
6. آیا تصمیم چنان‌که برنامه‌ریزی شده بود اجرا شد؟
7. آیا اجرا به نتیجه کشاورزی بهتری انجامید؟

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

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

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

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

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

1. چه تصمیمی به سبب سامانه تغییر خواهد کرد؟

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

2. سامانه با چه شیوه کار کنونی مقایسه می‌شود؟

آیا از تجربه کشاورز، بازرسی متخصص، یک قاعده ساده، یا سامانه‌ای که هم‌اکنون در استفاده است بهتر عمل می‌کند؟ و چه اندازه ارزش افزوده فراهم می‌آورد؟

3. آیا در محیطی مستقل و مشابه جایی که به کار خواهد رفت آزمایش شده است؟

آیا آزمون شامل مزارع، فصل‌ها، دستگاه‌ها، ارقام و کاربرانی بوده که داده‌هایشان در آموزش گنجانده نشده بود؟

4. خطرناک‌ترین خطا کدام است، و چند بار رخ داده است؟

آیا بزرگ‌ترین مخاطره از دست دادن مورد، صدور هشدار کاذب، تأخیر، یا هدایت اقدام به جای نادرست است؟ و این خطا چه اثری بر مزرعه دارد؟

5. آیا مرزهای دانش خود را روشن می‌کند؟

آیا سطح اطمینان یا بازه‌ای مورد انتظار عرضه می‌کند؟ و آیا هنگامی که شواهد کافی نیست اطلاعات بیشتری می‌خواهد یا مورد را به انسان ارجاع می‌دهد؟

6. هزینه بهره‌برداری و نگهداری آن چقدر است؟

به چه دستگاه‌ها، اتصال، برق، آموزش، پشتیبانی و نگهداری نیاز دارد؟ و در صورت وقفه یا خرابی چه رخ می‌دهد؟

7. چگونه تشخیص می‌دهیم عملکرد آن افت کرده است؟

چه کسی نتایج را پس از استقرار پایش می‌کند؟ چه نشانه‌ای بر لزوم آزمون دوباره یا به‌روزرسانی دلالت می‌کند؟ و چه کسی نسخه جدید را تأیید می‌کند؟

8. تصمیم نهایی و اختیار توقف آن با کیست؟

آیا کاربر می‌داند چه زمانی نتیجه جنبه مشورتی دارد؟ چه کسی موارد پرمخاطره را بازبینی می‌کند؟ و آیا می‌توان اجرای خودکار را متوقف کرد و سامانه را به وضعیت ایمن بازگرداند؟

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

13. یک مورد آموزشی یکپارچه: تصویر یک برگ چگونه به تصمیمی مسئولانه در کشاورزی بدل می‌شود؟

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

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

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

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

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

• شناسایی نواحی تغییررنگ‌داده در تصویر.
• برآورد نسبتی از برگ که مبتلا شده است.
• توصیف شکل لکه‌ها و پراکندگی ظاهری آن‌ها.
• مقایسه الگو با دسته‌هایی که مدل از تصاویر پیشین آموخته است.
• تشخیص اینکه تصویر به‌قدر کافی به مواردی که مدل بر آن‌ها آزموده شده شباهت ندارد.

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

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

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

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

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

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

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

• چه شواهدی هر احتمال را بالا برد؟
• چه اطلاعاتی آن را پایین آورد؟
• چه داده‌هایی کم است؟
• کدام پرسش یا آزمون بعدی مؤثرترین تمایز را میان احتمالات پدید می‌آورد؟
• آیا نمرات اطمینانی که عرضه می‌کند در محصول و محیطی مشابه آزموده شده است؟

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

• اسناد راهنمای صادرشده از سوی مراجع کشاورزی مورد اعتماد.
• مراجع علمی یا تشخیصی مناسب برای آن محصول.
• بولتن‌های رسمی به‌روزشده.
• دستورالعمل‌های صادرشده از سوی مراجع نظارتی صلاحیت‌دار.
• دستورهای رسمی جاری برای استفاده از فرآورده‌های ثبت‌شده به‌صورت محلی.
• پروتکل‌های نمونه‌برداری یا ارجاع به آزمایشگاه.

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

• محصول و رقم.
• موقعیت مکانی، یا کشور و منطقه.
• تاریخ و نسخه سند.
• نهاد صادرکننده.
• نوع کشت و محیط.
• مرحله رشد محصول.
• وضعیت نظارتی ماده یا رویه.

سامانه باید منبع را به‌گونه‌ای عرضه کند که کاربر یا متخصص بتواند بررسی‌اش کند، با تعیین عنوان سند، نهاد صادرکننده، تاریخ، و بخشی که بر آن تکیه کرده است. همچنین باید میان این موارد تمایز بگذارد:

• آنچه به‌صراحت در منبع آمده است.
• آنچه سامانه با ترکیب چند پاره اطلاعات استنتاج کرده است.
• آنچه پشتیبانی کافی برایش نیافته است.

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

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

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

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

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

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

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

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

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

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

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

14. چه چیزی باید از این فصل نزد خواننده بماند؟

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

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

یک شرکت ممکن است بگوید سامانه‌اش «بیماری‌های گیاهی را تشخیص می‌دهد»، اما این توصیف ممکن است وظایفی بسیار متفاوت را پنهان کند. آیا فقط وجود تغییری در برگ را شناسایی می‌کند؟ آیا تصویر را با شماری محدود از موارد مقایسه می‌کند؟ آیا علت‌های ممکن را رتبه‌بندی می‌کند؟ آیا منبعی ارائه می‌دهد؟ آیا درمانی پیشنهاد می‌کند؟ هر یک از این سطوح داده، مخاطرات و مسئولیت‌های متفاوتی در بر دارد. همچنین باید پرسید که خود آن نتیجه چه معنایی دارد. اگر سامانه عدد 0.82 را نمایش دهد، معنایش چیست؟ آیا یک احتمال است؟ نمره شباهت؟ نسبت سطح آسیب‌دیده؟ و اگر عملکرد 4.7 را پیش‌بینی کند، واحدش چیست: تن در هکتار، در هر فدان، یا برای کل مزرعه؟ و به چه بازه زمانی اشاره دارد؟ خروجی‌ای که واحد، زمان‌بندی یا نسبتش با تصمیم نامعلوم است ممکن است دقیق به نظر برسد، اما از اقدامی مسئولانه پشتیبانی نمی‌کند. دوم — سامانه چه می‌داند، و چه چیزی را نمی‌تواند بداند؟ هر مدل به داده‌هایی که از آن‌ها آموخته، یا به قواعد و منابعی که به آن داده شده است، وابسته است. پس باید پرسید:

• بر چه نوع داده‌ای بنا شده است؟
• آن داده از کجا آمده است؟
• چه کسی کیفیتش را راستی‌آزمایی کرده است؟
• آیا نماینده محصولات، ارقام، فصل‌ها و محیط‌هایی است که در آن‌ها به کار خواهد رفت؟
• آیا موارد اولیه، آمیخته و دشوار را در بر می‌گیرد، یا فقط موارد آشکار را؟
• سامانه چه اطلاعاتی را نمی‌تواند ببیند یا به آن دسترسی یابد؟
• اگر تصویر بد باشد، قرائت ناقص باشد، یا حسگر معیوب باشد، چه رخ می‌دهد؟
• آیا میان آنچه واقعاً اندازه گرفته، آنچه کاربر وارد کرده، و آنچه خودش استنتاج کرده است تمایز می‌گذارد؟

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

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

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

1. شواهد عملکرد مدل:

نشان می‌دهد که مدل در آزمونی مشخص، تصاویر را به‌خوبی دسته‌بندی کرده یا مقادیر را به‌خوبی پیش‌بینی کرده است.

2. شواهد عملکرد سامانه:

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

3. شواهد اثر کشاورزی:

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

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

• آیا وقتی مورد مبهم است، روشن می‌کند که شواهد کافی نیست؟
• آیا به‌جای عددی قطعی، یک بازه یا درجه‌ای از اطمینان ارائه می‌دهد؟
• آیا می‌تواند اطلاعات بیشتری درخواست کند؟
• آیا می‌تواند وقتی مبنای کافی ندارد از تشخیص یا توصیه خودداری کند؟
• اگر حسگر، اتصال یا برق قطع شود چه می‌کند؟
• آیا به حالت ایمن می‌رود، یا بر پایه داده‌های قدیمی ادامه می‌دهد؟
• چه کسی موارد حل‌نشده را بازبینی می‌کند؟
• چه کسی اختیار توقف اجرا یا لغو آن را دارد؟
• تیم چگونه تشخیص می‌دهد که عملکرد پس از خرید یا استقرار افت کرده است؟
• چه کسی به‌روزرسانی‌ها و نسخه‌های تازه را تأیید می‌کند؟

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

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

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

خلاصهٔ فصل

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

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

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

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

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

• سامانه در عمل چه دید؟
• چه استنباط کرد؟
• از دانستن چه چیزی ناتوان بود؟
• چه شواهدی نتیجه را پشتیبانی می‌کند؟
• به چه اقدامی خواهد انجامید؟
• چه کسی مسئولیت آن اقدام را بر عهده دارد؟
• اگر نتیجه نادرست باشد چه رخ می‌دهد؟

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

یادداشت‌های شواهد و حدود اتکا

دو مرور [SRC001] و [SRC002] روایت کلی از گستره کاربردهای هوش مصنوعی و بینایی ماشین در حوزه‌های کشاورزی و غذایی را پشتیبانی می‌کنند، بی‌آنکه به این معنا باشد که هر کاربردی برای همه محصولات و محیط‌ها مناسب است. [SRC035] این نگاه را پشتیبانی می‌کند که سامانه کشاورزی دیجیتال زنجیره‌ای به‌هم‌پیوسته است که حسگری، داده، زمینه، تصمیم و اقدام را دربر می‌گیرد، و همین ارزیابی سامانه را به‌عنوان یک کل، به‌جای اتکا به خروجی مدل به‌تنهایی، موجه می‌سازد. [SRC006] به‌عنوان نمونه‌ای محدود از پیش‌بینی عملکرد و کاربرد ابزارهای تفسیرپذیری در یک چارچوب پژوهشی مشخص به کار رفته است. رتبه‌بندی عوامل یا یافته‌های آن چارچوب را نباید به روابط علّی عام یا حقایقی که در هر مزرعه‌ای صدق کند بدل کرد. [SRC009] برای تصحیح انتساب فناوری تشخیص علف هرز به کار رفته است: این منبع به تحلیل تصاویر مزارع سویا با روش‌های بینایی کانولوشنی می‌پردازد و وجود سامانه‌ای رباتیک برای حذف علف هرز بر پایه یادگیری تقویتی را اثبات نمی‌کند. این تصحیح به تمایز میان دیدن یک شیء در تصویر و کنترل ماشینی که با آن تعامل می‌کند کمک می‌کند. ارائه مخاطرات، نظارت و بازبینی پیوسته در سراسر چرخه عمر سامانه بر پایه چارچوب ارجاع‌شده در [SRC033] هدایت می‌شود. اما در مورد نمونه آموزشی یکپارچه، راهنمای پیوند دادن وظیفه به روش، پرسش‌های عملی و نمونه‌های میدانی ارائه‌شده در این فصل، اینها ترکیبی تحریری و آموزشی‌اند که برای روشن کردن تمایزهای میان اندازه‌گیری، تحلیل، تصمیم و اجرا در نظر گرفته شده‌اند. این نمونه‌ها نمایانگر نتایج یک آزمایش تازه، اثبات عملکرد هیچ سامانه‌ای خاص، یک تشخیص کشاورزی، یا نسخه‌ای برای درمان یک محصول نیستند.