دستیار هوشمند فارم؛ گفت‌وگوی مستقیم با داده‌های گاوداری و ساخت گزارش با زبان طبیعی

مقدمه؛ اگر مدیر می‌توانست مستقیماً با دیتابیس گاوداری صحبت کند

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

تولید شیر ثبت شده است.

تلقیح‌ها ثبت شده‌اند.

وضعیت آبستنی مشخص است.

بیماری‌ها و درمان‌ها در پرونده دام هستند.

اطلاعات خوراک و TMR موجود است.

روزهای باز محاسبه شده‌اند.

دام‌های خشک مشخص هستند.

SCC، CMT، BCS، نشخوار و فعالیت نیز ممکن است ثبت شده باشند.

اما داشتن اطلاعات با دسترسی ساده به اطلاعات یکسان نیست.

مدیر ممکن است فقط بخواهد بداند:

«کدام گاوهای پرتولید بیشتر از ۱۲۰ روز باز هستند؟»

یا:

«در یک ماه گذشته کدام بهاربند بیشترین افت شیر را داشته؟»

یا:

«لیست واکسن‌های عقب‌افتاده را اکسل بده.»

در سیستم سنتی برای پاسخ به چنین سؤالی ممکن است لازم باشد:

گزارش مناسب پیدا شود،

چند Filter تنظیم شود،

چند صفحه باز شود،

اطلاعات Excel شود،

و سپس تحلیل دستی انجام گیرد.

AI Farm Copilot تلاش می‌کند این فرایند را به یک مکالمه تبدیل کند.

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

---

AI Farm Copilot چیست؟

AI Farm Copilot را نباید فقط یک Chatbot در نظر گرفت.

Chatbot معمولی ممکن است درباره موضوعی عمومی توضیح بدهد.

مثلاً:

«روزهای باز در گاوداری چیست؟»

اما Farm Copilot باید بتواند پاسخ بدهد:

«در فارم خود من چند گاو بیشتر از ۱۲۰ روز باز هستند؟»

این تفاوت اساسی است.

Chatbot عمومی
↓
دانش عمومی

AI Farm Copilot
↓
داده واقعی فارم
+
دانش مدیریتی

بنابراین ارزش اصلی Copilot از اتصال امن به داده واقعی فارم ایجاد می‌شود.

---

یک مثال ساده

مدیر می‌نویسد:

«گاوهای بالای ۱۲۰ روز باز را نشان بده.»

سیستم باید مفهوم سؤال را بفهمد.

سپس Query مناسب را اجرا کند.

مثلاً در پشت صحنه ممکن است چیزی شبیه این شکل بگیرد:

SELECT animal_id,
       days_open,
       parity,
       milk_today,
       pen
FROM cows
WHERE days_open > 120
ORDER BY days_open DESC;

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

87 رأس دام با روزهای باز بیشتر از 120 روز شناسایی شدند.

بیشترین مقدار:
IR-1482 → 196 روز

بهاربند دارای بیشترین موارد:
بهاربند 3 → 24 رأس

و مدیر بتواند بگوید:

«اکسلش را بده.»

---

فناوری Text-to-SQL

تبدیل پرسش زبان طبیعی به Query پایگاه داده حوزه شناخته‌شده‌ای در هوش مصنوعی است که معمولاً Text-to-SQL نامیده می‌شود.

یکی از مهم‌ترین Benchmarkهای این حوزه، Spider است که توسط پژوهشگران Yale University توسعه یافت و شامل بیش از ۱۰ هزار سؤال، ۵۶۹۳ Query و ۲۰۰ دیتابیس در ۱۳۸ حوزه بود. هدف این Benchmark بررسی توانایی مدل در تبدیل سؤال طبیعی به SQL روی ساختارهای دیتابیسی جدید بود.

این فناوری دقیقاً پایه مفهومی چیزی است که برای Farm Copilot نیاز داریم:

Natural Language
↓
Database Understanding
↓
Query
↓
Result

---

اما Text-to-SQL هنوز مسئله حل‌شده‌ای نیست

این نکته برای معماری رایکا بسیار مهم است.

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

Spider 2.0 برای شبیه‌سازی Queryهای Enterprise واقعی توسعه داده شد؛ دیتابیس‌هایی با ساختارهای بسیار بزرگ، چند سیستم مختلف و Workflowهای پیچیده. در ارزیابی اولیه این Benchmark، حتی یک Agent مبتنی بر مدل پیشرفته فقط بخشی از Taskها را حل کرد.

بنابراین معماری اشتباه این است:

User
↓
LLM
↓
SQL آزاد
↓
Production Database

این معماری برای یک سیستم واقعی گاوداری مناسب نیست.

---

معماری امن‌تر AI Farm Copilot

ساختار پیشنهادی:

                 سؤال مدیر
                     ↓
              AI Farm Copilot
                     ↓
             Intent Detection
                     ↓
             Query Orchestrator
                     ↓
          Semantic / Data Layer
                     ↓
               Read-Only Query
                     ↓
                 Database
                     ↓
               Query Result
                     ↓
          Validation + Formatting
                     ↓
       متن / جدول / Excel / PDF

در این معماری مدل زبانی کنترل کامل دیتابیس را ندارد.

---

Semantic Layer چیست؟

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

lactation_days
reproduction_status
last_ai_date
pregnancy_confirmed
daily_milk
pen_id

اما مدیر می‌گوید:

«گاوهای باز بالای ۱۲۰ روز»

مدیر نام Columnهای دیتابیس را نمی‌داند.

نباید هم بداند.

Semantic Layer بین زبان مدیر و ساختار فنی دیتابیس قرار می‌گیرد.

مثلاً:

«روزهای باز»
→ days_open

«شیر امروز»
→ daily_milk

«بهاربند»
→ pen_id

«گاو آبستن»
→ pregnancy_status

این لایه دقت سیستم را بالا می‌برد و وابستگی کاربر به ساختار فنی دیتابیس را حذف می‌کند.

---

مثال یک مکالمه واقعی

مدیر:

«وضعیت تولیدمثل فارم چطوره؟»

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

Pregnancy Rate
Conception Rate
Days Open
Services per Conception
Pregnant Cows
Repeat Breeders

و پاسخ بدهد:

خلاصه تولیدمثل امروز

دام‌های واجد شرایط: 412 رأس
آبستن: 286 رأس
بیشتر از 120 روز باز: 74 رأس
تلقیح 3 بار یا بیشتر: 29 رأس
میانگین روزهای باز: 118 روز

بعد مدیر می‌گوید:

«فقط بهاربندهای ۲ و ۳ را مقایسه کن.»

Copilot باید Context مکالمه را حفظ کند.

---

Multi-turn Conversation

این قابلیت بسیار مهم است.

کاربر لازم نیست در هر سؤال همه‌چیز را از اول بگوید.

مثلاً:

سؤال اول

«گاوهای با افت شیر بالای ۱۰ درصد را بده.»

سؤال دوم

«فقط تازه‌زاها.»

سؤال سوم

«اون‌هایی که نشخوارشون هم پایین آمده.»

سؤال چهارم

«اکسلش کن.»

سیستم باید بفهمد هر سؤال ادامه سؤال قبلی است.

پژوهش‌های جدید Agricultural AI نیز به اهمیت گفت‌وگوهای Multi-turn و جمع‌آوری تدریجی Context توجه کرده‌اند؛ برای نمونه سیستم Krishi Sathi در هند برای فهم بهتر درخواست کشاورز، Context مکالمات قبلی را در فرایند Retrieval و پاسخ‌دهی نگه می‌دارد.

---

سؤال صوتی

مدیر یا دامپزشک الزاماً نباید تایپ کند.

ساختار می‌تواند باشد:

Voice
↓
Speech-to-Text
↓
Farm Copilot
↓
Database
↓
Answer
↓
Text-to-Speech

مثلاً مدیر هنگام قدم‌زدن در فارم بپرسد:

«چند گاو امروز نیاز به ویزیت دارند؟»

و سیستم پاسخ صوتی بدهد.

این معماری در Agricultural AI واقعی نیز در حال استفاده است.

Farmer.Chat و پروژه‌های مشابه از رابط‌های متنی و صوتی چندزبانه استفاده کرده‌اند.

---

تفاوت Voice-to-Form با Farm Copilot

مقاله قبلی درباره Voice-to-Form بود.

تفاوت:

Voice-to-Form
↓
داده وارد سیستم می‌کند

در حالی که:

Farm Copilot
↓
از داده سؤال می‌کند

مثلاً:

Voice-to-Form

«گاو ۱۰۰۱ دمای ۳۹.۴ دارد.»

→ ثبت در پرونده.

Farm Copilot

«امروز چند گاو تب بالای ۳۹.۳ داشته‌اند؟»

→ Query از دیتابیس.

این دو در کنار یکدیگر چرخه بسیار قدرتمندی ایجاد می‌کنند.

---

سؤال از داده واقعی، نه حافظه مدل

یکی از مهم‌ترین اصول طراحی این ماژول:

پاسخ عددی نباید از حافظه LLM ساخته شود.

اگر مدیر بپرسد:

«چند گاو بیشتر از ۱۲۰ روز باز داریم؟»

مدل نباید تخمین بزند.

باید Query اجرا شود.

Question
↓
Database Query
↓
Result = 74
↓
Answer = 74

نه:

Question
↓
LLM Guess
↓
74

این تفاوت بنیادی است.

---

ادعای «بدون توهم» باید دقیق‌تر بیان شود

در صفحه فعلی رایکا عبارت «پاسخ‌های داده‌محور دقیق متصل به دیتابیس بدون توهم مدل» برای Farm Copilot آمده است.

هدف معماری کاملاً درست است، اما از نظر علمی عبارت «بدون توهم» مطلق است.

حتی اگر داده اصلی صحیح باشد، مدل می‌تواند:

• سؤال را اشتباه تفسیر کند؛
• Column اشتباه انتخاب کند؛
• Join اشتباه ایجاد کند؛
• Aggregate نامناسب استفاده کند؛
• نتیجه Query را نادرست توضیح دهد.

مطالعات Text-to-SQL انواع همین خطاها را ثبت کرده‌اند، از انتخاب Column اشتباه تا JOIN و Aggregate نادرست.

بنابراین عبارت علمی‌تر:

«پاسخ‌های Grounded بر داده واقعی فارم با اجرای Query کنترل‌شده و حداقل‌سازی ریسک توهم مدل»

است.

---

چگونه ریسک Hallucination را کم کنیم؟

بهترین معماری چند لایه دفاعی دارد.

۱. Query فقط Read-Only

Copilot نباید مستقیم بتواند:

DELETE
UPDATE
DROP
INSERT

اجرا کند.

برای گزارش‌گیری:

SELECT

کافی است.

---

۲. استفاده از Viewهای کنترل‌شده

به‌جای دسترسی به تمام دیتابیس:

Database
├── internal tables
├── security tables
├── audit
├── users
├── ...

Copilot فقط Viewهای مشخصی ببیند:

copilot_cows
copilot_milk
copilot_reproduction
copilot_health
copilot_feed

---

۳. محدودیت Row

هر Query باید Limit داشته باشد.

مثلاً:

LIMIT 1000

مگر اینکه Export کنترل‌شده درخواست شده باشد.

---

۴. Query Timeout

هیچ سؤال کاربر نباید بتواند Query چنددقیقه‌ای روی Production اجرا کند.

مثلاً:

Maximum query time = 5 sec

یا مقدار متناسب با زیرساخت.

---

۵. Query Validation

قبل از اجرا:

Generated SQL
↓
Parser
↓
Security Check
↓
Schema Check
↓
Execution

انجام شود.

---

۶. ثبت Audit Log

برای هر سؤال:

User
Time
Question
Generated Query
Execution Time
Row Count
Result

ذخیره شود.

اگر گزارشی اشتباه بود، دقیقاً می‌توان فهمید چرا.

---

کنترل سطح دسترسی

همه کاربران نباید به همه اطلاعات دسترسی داشته باشند.

مثلاً کارگر شاید بتواند بپرسد:

«امروز کدام دام‌ها باید جابه‌جا شوند؟»

ولی نباید بتواند بپرسد:

«سود خالص ماه گذشته چقدر بود؟»

بنابراین:

Worker
Vet
Nutritionist
Farm Manager
Owner

باید Permission متفاوت داشته باشند.

---

Role-Based AI

Copilot می‌تواند حتی بر اساس Role متفاوت پاسخ بدهد.

دامپزشک

اولویت:

Health
Treatment
Withdrawal
CMT
BHBA
Follow-up

متخصص تغذیه

TMR
DMI
Feed Efficiency
Milk Components
BCS

مدیر

Profit
Milk
Reproduction
Feed Cost
Health KPI

در نتیجه یک Copilot واحد می‌تواند برای چند نقش رفتار متفاوت داشته باشد.

---

تولید گزارش Excel

یکی از قابلیت‌های مهم ماژول رایکا تولید فایل Excel است.

مثلاً مدیر بگوید:

«لیست گاوهایی که بیشتر از ۱۲۰ روز باز هستند و بیش از دو تلقیح داشته‌اند را Excel بده.»

معماری مناسب:

Question
↓
Validated Query
↓
Structured Result
↓
Excel Generator
↓
.xlsx

نکته مهم:

LLM نباید خودش فایل Excel را به‌صورت حدسی تولید کند.

داده باید مستقیماً از Result Set وارد فایل شود.

---

تولید PDF

مثلاً:

«گزارش سلامت بهاربندهای ۱ تا ۵ را برای جلسه مدیریت PDF کن.»

سیستم می‌تواند:

Query Results
+
Charts
+
KPI
+
AI Narrative
↓
PDF

بسازد.

قسمت عددی گزارش Deterministic است.

قسمت توضیحی می‌تواند توسط AI نوشته شود.

---

تفاوت Data با Narrative

مثلاً:

داده واقعی

Clinical mastitis cases = 18
Previous month = 11

این اطلاعات باید مستقیماً از دیتابیس بیاید.

AI می‌تواند توضیح دهد:

«تعداد موارد ثبت‌شده ماستیت نسبت به دوره قبل افزایش یافته است.»

ولی نباید عدد جدیدی اختراع کند.

---

Report Provenance

برای گزارش‌های حرفه‌ای بهتر است پایین گزارش نوشته شود:

Data through:
2026-08-19 17:00

Farm:
...

Filters:
Pen 1–5

Generated by:
Raika AI Farm Copilot

این کار گزارش را قابل حسابرسی می‌کند.

---

«این عدد از کجا آمده؟»

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

«این عدد از کجا آمده؟»

مثلاً Copilot می‌گوید:

Repeat breeders: 29

مدیر روی عدد کلیک می‌کند.

سیستم لیست همان ۲۹ دام را نشان می‌دهد.

این مفهوم Drill-Down است.

---

Natural Language BI

در سیستم‌های BI سنتی کاربر باید:

• Dashboard پیدا کند؛
• Filter بزند؛
• Chart انتخاب کند.

Natural Language BI مسیر را تغییر می‌دهد.

«شیر سه ماه گذشته را با هزینه خوراک مقایسه کن.»

→ سیستم Chart تولید می‌کند.

«کدام ماه بدترین حاشیه را داشت؟»

→ سیستم همان Dataset را تحلیل می‌کند.

این همان جهتی است که Natural Language Interfaces برای دیتابیس دنبال می‌کنند؛ پژوهش Text-to-SQL از سال‌ها قبل دقیقاً با هدف کاهش نیاز کاربران غیرمتخصص به نوشتن SQL توسعه یافته است.

---

مثال مدیریتی: افت شیر

مدیر:

«افت شیر این هفته از کجا آمده؟»

Copilot می‌تواند Queryهای متعددی اجرا کند.

مثلاً:

Milk by Pen
Milk by DIM group
Fresh cows
Sick cows
Heat stress period
TMR changes

و پاسخ بدهد:

افت شیر هفتگی: 3.8%

بیشترین سهم افت:
Pen 3 → -7.1%

در Pen 3:
Rumination -9%
DMI -6%
TMR changed 4 days ago

اینجا Copilot از «گزارش» وارد تحلیل علت می‌شود.

---

اما Correlation با Causation فرق دارد

اگر سیستم ببیند:

TMR changed
Milk decreased

نباید فوراً بگوید:

«تغییر TMR علت افت شیر بود.»

باید بگوید:

«افت شیر از نظر زمانی با تغییر TMR هم‌زمان بوده و نیاز به بررسی دارد.»

این تفاوت علمی بسیار مهم است.

---

پرسش‌های سریع

در صفحه رایکا نمونه‌هایی مانند:

• افت شیر
• واکسن‌های معوقه
• راندمان خوراک

به‌عنوان Quick Question پیشنهاد شده‌اند.

این طراحی برای کاربران غیرتخصصی AI مفید است.

مثلاً صفحه اصلی Copilot:

[دام‌های نیازمند اقدام امروز]

[افت شیر]

[واکسن‌های عقب‌افتاده]

[روزهای باز بالا]

[راندمان خوراک]

[شیر دورریز]

[گزارش جلسه مدیریت]

---

Copilot نباید فقط منتظر سؤال باشد

نسل پیشرفته‌تر می‌تواند Proactive باشد.

مثلاً صبح بگوید:

سه موضوع نیازمند توجه:

1. افت 6.2% شیر در Pen 4
2. افزایش 11 موردی گاوهای >120 Days Open
3. افزایش Feed Cost/Liter طی 7 روز گذشته

در این مدل Copilot تبدیل به Daily Briefing System می‌شود.

---

Morning Brief

مثلاً مدیر ساعت ۷ صبح وارد سیستم می‌شود.

Copilot:

صبح بخیر.

خلاصه فارم:

Milk:
+1.2% vs yesterday

Health:
12 cows require review

Reproduction:
7 pregnancy checks due

Feed:
Pen 3 FE below target

Economics:
Feed cost/liter +3.4%

این یکی از کاربردهای بسیار ارزشمند AI در مدیریت فارم است.

---

ارتباط با پایش روزانه

ماژول اول این مجموعه:

Daily Monitoring

دام‌های غیرعادی را پیدا می‌کند.

Farm Copilot می‌تواند نتیجه را به زبان طبیعی ارائه دهد.

Monitoring Engine
↓
12 alerts
↓
Copilot
↓
«امروز 12 دام نیازمند بررسی هستند.»

---

ارتباط با Hidden Waste Tracker

مدیر می‌پرسد:

«این ماه بیشترین اتلاف پول از کجا بوده؟»

Hidden Waste Tracker محاسبات را انجام داده است.

Copilot فقط رابط پرسش است.

Copilot
↓
Hidden Waste Engine
↓
Result

مثلاً:

1. Days Open: 84m
2. Feed Efficiency: 62m
3. Discarded Milk: 31m

---

ارتباط با Digital Twin

مدیر می‌پرسد:

«چرا گاو ۱۲۴۰ هشدار گرفته؟»

Copilot اطلاعات Digital Twin را می‌خواند:

Milk -8%
Rumination -10.5%
Activity -7%

و توضیح می‌دهد.

---

ارتباط با CBR

دامپزشک می‌پرسد:

«برای این گاو موارد مشابه داریم؟»

Copilot:

CBR Engine
↓
Top similar cases

را نمایش می‌دهد.

---

ارتباط با تحلیل ۳۶۰ درجه

مدیر:

«وضعیت کامل گاو ۱۷۲۵ را خلاصه کن.»

Copilot اطلاعات ماژول ۳۶۰ درجه را می‌گیرد.

یعنی Copilot نباید خودش دوباره همه Riskها را از صفر محاسبه کند.

بهترین معماری:

Specialized Engines
↓
Copilot
↓
Natural Language Interface

است.

---

Copilot باید Orchestrator باشد، نه همه‌کاره

این اصل معماری بسیار مهم است.

نباید یک LLM مسئول:

• محاسبه Feed Efficiency
• تشخیص بیماری
• محاسبه Days Open
• CBR
• SQL
• گزارش مالی

باشد.

هر کدام باید Engine مشخص داشته باشند.

Copilot فقط تشخیص دهد سؤال مربوط به کدام Engine است.

User Question
       ↓
     Router
       ↓
 ┌─────┼─────┐
 DB   CBR   Twin
 │     │      │
 BI  Waste  Health
 └─────┼─────┘
       ↓
    Copilot

این معماری قابل اعتمادتر و قابل تست‌تر است.

---

Agricultural Copilot در دنیا فقط یک ایده نیست

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

یکی از نمونه‌های مهم Farmer.Chat است که توسط Digital Green و Microsoft Research توسعه یافته است.

Microsoft Research گزارش کرده که این سیستم در چند کشور استقرار یافته و هزاران کشاورز از آن استفاده کرده‌اند.

تحقیقات منتشرشده در ۲۰۲۶ نیز استفاده Farmer.Chat را در هند، کنیا، اتیوپی و نیجریه گزارش می‌کند.

---

هند

هند یکی از مهم‌ترین محیط‌های آزمایش Agricultural Conversational AI است.

Farmer.Chat، Krishi Sathi و چند پروژه دیگر در این کشور روی:

• زبان طبیعی
• Voice
• RAG
• توصیه کشاورزی
• Context محلی

کار کرده‌اند.

یکی از درس‌های مهم مطالعه ۲۰۲۶ Farmer.Chat این بود که LLM عمومی می‌تواند پاسخ‌های بدون پشتوانه یا بیش‌ازحد عمومی تولید کند؛ معماری پیشنهادی پژوهشگران، جداسازی بازیابی Factهای تأییدشده از لایه گفت‌وگویی بود.

این دقیقاً با معماری مناسب رایکا هم‌راستا است.

---

کنیا

Microsoft Research و KALRO در کنیا AgriAdvisor را آزمایش کرده‌اند.

این Copilot از Generative AI برای ارائه اطلاعات کشاورزی و آب‌وهوا به زبان انگلیسی و Swahili استفاده می‌کند.

همچنین پروژه AIEP چند MVP مبتنی بر AI را در کنیا و Bihar هند آزمایش کرده است. معماری آنها شامل رابط Voice/WhatsApp/App و لایه Reasoning متصل به داده‌های خارجی و RAG بوده است.

---

اتیوپی و نیجریه

Farmer.Chat در تحقیقات جدید به‌عنوان سامانه‌ای با استفاده عملی در:

• India
• Kenya
• Ethiopia
• Nigeria

گزارش شده است.

بنابراین استفاده از Conversational AI در کشاورزی از مرحله Demo صرف عبور کرده است.

---

CGIAR و CIMMYT

شبکه CGIAR نیز در چند پروژه از Generative AI برای Agricultural Advisory استفاده می‌کند.

گزارش‌های CGIAR به استفاده از Interfaceهایی مانند:

• Voice
• SMS
• Chatbot

برای ارائه توصیه‌های محلی و مقیاس‌پذیر اشاره کرده‌اند.

این پروژه‌ها بیشتر روی Crop Agriculture متمرکز هستند، اما اصول معماری برای Dairy Farm Copilot بسیار مرتبط‌اند.

---

تفاوت Farm Advisory Bot با Raika Farm Copilot

بسیاری از سیستم‌های جهانی به این سؤال پاسخ می‌دهند:

«برای این آفت چه کنم؟»

یا:

«هوا فردا چگونه است؟»

Farm Copilot رایکا هدف دیگری نیز دارد:

Query کردن داده اختصاصی خود فارم.

مثلاً:

«در ۳۰ روز گذشته چند مورد متریت داشتیم؟»

این نیازمند:

LLM
+
Live Farm Database
+
Analytics

است.

---

پژوهش Yale چرا برای رایکا مهم است؟

Yale University روی Agricultural AI کار نکرده است؛ اهمیت تحقیقات Spider برای رایکا از جنبه دیگری است:

Natural Language Database Access

یعنی همان فناوری لازم برای اینکه مدیر بدون دانستن SQL بتواند از دیتابیس سؤال کند.

این تفکیک باید در منابع مقاله واضح باشد.

---

تحقیقات کره جنوبی

در Yonsei University کره جنوبی نیز چارچوب‌های جدید Text-to-SQL با تمرکز بر مدل‌های سبک‌تر، Schema Linking و Self-Correction توسعه یافته‌اند. هدف این تحقیقات امکان Query دقیق‌تر دیتابیس با زبان طبیعی و کاهش وابستگی به مدل‌های بسیار بزرگ است.

این حوزه می‌تواند برای سامانه‌های Enterprise کوچک‌تر و حساس به Privacy مانند سیستم مدیریت فارم اهمیت داشته باشد.

---

چرا Privacy مهم است؟

اطلاعات فارم فقط اطلاعات چند گاو نیست.

می‌تواند شامل:

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

باشد.

بنابراین سؤال کاربر نباید لزوماً باعث ارسال کل دیتابیس به LLM شود.

معماری مناسب:

Schema + Required Context
↓
AI

Full Farm Database
✗

مدل فقط اطلاعات مورد نیاز همان Query را دریافت می‌کند.

---

حداقل‌سازی داده ارسالی

اگر سؤال:

«چند گاو بیشتر از ۱۲۰ روز باز داریم؟»

است، مدل نیازی به:

• شماره تلفن کارکنان
• هزینه دارو
• موجودی انبار
• اطلاعات فروشنده

ندارد.

اصل:

Minimum Necessary Data

باید رعایت شود.

---

فارسی و زبان محاوره‌ای

مدیر ممکن است نگوید:

«دام‌های دارای Days Open greater than 120 را Query کن.»

می‌گوید:

«کدوم گاوا خیلی وقته آبستن نشدن؟»

یا:

«بازای بالای صد و بیست روز رو بده.»

Copilot خوب باید Alias و عبارت‌های محاوره‌ای را بفهمد.

برای این کار می‌توان Dictionary تخصصی رایکا ساخت.

---

اصطلاحات تخصصی

مثلاً همه اینها ممکن است به Concept مشابه اشاره کنند:

روز باز
Days Open
Open Days
باز
گاو باز

یا:

سلول
SCC
Somatic Cell Count

Semantic Dictionary اهمیت زیادی دارد.

---

سؤال مبهم

اگر مدیر بپرسد:

«وضعیت شیر چطوره؟»

سیستم نباید بدون Context یک جواب تصادفی بسازد.

می‌تواند ابتدا یک Summary استاندارد ارائه کند:

Production today
vs yesterday
vs 7-day average
vs target

یا در صورت نیاز Clarification بگیرد.

سیستم‌های Agricultural Conversational AI جدید نیز اهمیت Intent detection و جمع‌آوری Context کافی قبل از تولید پاسخ را نشان داده‌اند.

---

زمان پاسخ

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

این هدف از نظر فنی برای برخی Queryهای ساده و Reportهای Cache‌شده امکان‌پذیر است.

اما نباید به‌صورت عدد تضمینی برای هر نوع گزارش اعلام شود مگر Benchmark واقعی وجود داشته باشد.

تحقیقات AIEP روی سیستم‌های AI کشاورزی نشان داده‌اند که Latency، خصوصاً در Voice و Pipelineهای چندمرحله‌ای، همچنان چالش عملی است و دستیابی پایدار حتی به پاسخ‌های زیر پنج ثانیه در بعضی معماری‌ها دشوار بوده است.

---

Benchmark واقعی رایکا

برای اثبات سرعت باید مثلاً ۱۰۰ سؤال استاندارد تعریف شود.

گروه‌ها:

Simple count
Aggregation
Multi-table
Trend
Export
AI analysis
Voice query

سپس:

P50
P95
P99

Latency اندازه‌گیری شود.

مثلاً:

Simple Query P95 = 1.2 sec
Complex Report P95 = 4.8 sec
Excel Export P95 = 6.1 sec

این بسیار معتبرتر از یک عدد کلی است.

---

Accuracy باید حتی مهم‌تر از Speed باشد

اگر گزارشی:

1 second

تولید شود ولی عدد اشتباه باشد، ارزشی ندارد.

بنابراین KPI اصلی باید شامل:

• Query Accuracy
• Result Accuracy
• Semantic Accuracy
• Response Latency
• Export Accuracy
• Permission Violations
• Hallucination Rate

باشد.

---

Golden Questions

یک روش خوب برای تست سیستم ساخت مجموعه‌ای از سؤالات مرجع است.

مثلاً ۵۰۰ سؤال:

چند گاو آبستن داریم؟
میانگین روزهای باز چقدر است؟
کدام بهاربند بیشترین افت شیر را دارد؟
چند دام دوره پرهیز فعال دارند؟
Feed Cost/Liter ماه گذشته چقدر بود؟

جواب صحیح همه آنها از قبل مشخص باشد.

هر نسخه جدید Copilot باید این آزمون را پاس کند.

پروژه‌های جدید Agricultural AI نیز از Golden Question/Answer Set برای ارزیابی کیفیت پاسخ استفاده می‌کنند.

---

Copilot باید جواب «نمی‌دانم» هم داشته باشد

اگر داده وجود ندارد:

«BHBA امروز ثبت نشده است.»

بهتر از این است که مدل عدد بسازد.

مثلاً:

سؤال:
BHBA این گاو چنده؟

جواب صحیح:
برای این دام BHBA ثبت نشده است.

این یکی از نشانه‌های سیستم قابل اعتماد است.

---

Source-of-Truth

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

مثلاً:

تولید شیر
→ milk_records

باروری
→ reproduction

درمان
→ health_records

خوراک
→ feed_management

Risk Score
→ 360 Engine

Similar Cases
→ CBR

Copilot نباید خودش Source of Truth شود.

---

Copilot به‌عنوان رابط تمام ماژول‌های رایکا

در نهایت می‌توان معماری را چنین دید:

               AI Farm Copilot
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
 Daily Monitor    Digital Twin      CBR
       │              │              │
       ↓              ↓              ↓
 Hidden Waste     360 Analysis      BI
       │              │              │
       └──────────────┼──────────────┘
                      ↓
                  Database

Copilot لایه مکالمه روی کل سامانه می‌شود.

---

یک سناریوی کامل مدیریتی

مدیر:

«امروز مهم‌ترین مشکلات فارم چیه؟»

Copilot:

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

1. 14 دام نیازمند ویزیت
2. افت 6.8% شیر در بهاربند 4
3. افزایش Feed Cost/Liter به میزان 4.1%

مدیر:

«اولی رو باز کن.»

Copilot:

14 دام

6 مورد metabolic risk
4 مورد udder health
3 مورد lameness
1 مورد fever

مدیر:

«فقط متابولیک‌ها رو بده.»

Copilot لیست را نمایش می‌دهد.

مدیر:

«PDF برای دامپزشک بساز.»

گزارش ساخته می‌شود.

این همان تجربه واقعی Copilot است.

---

یک سناریوی دامپزشکی

دامپزشک:

«گاو ۱۴۸۲ چرا توی لیست منه؟»

Copilot:

Milk -12%
Rumination -17%
DIM 8
BHBA yesterday 1.4

دامپزشک:

«موارد مشابه قبلی؟»

Copilot از CBR استفاده می‌کند.

سپس:

«سه پرونده مشابه با Outcome کامل وجود دارد.»

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

---

یک سناریوی تغذیه

متخصص تغذیه:

«کدام بهاربند FE بدتر از هدف دارد؟»

Copilot:

Pen 3
Actual FE = 1.31
Target = 1.55

کاربر:

«روند سی روزه را رسم کن.»

سپس:

«با DMI و شیر مقایسه کن.»

در چند جمله، تحلیلی که قبلاً شاید چند گزارش نیاز داشت آماده می‌شود.

---

یک سناریوی مالک فارم

مالک ممکن است علاقه‌ای به جزئیات BHBA نداشته باشد.

می‌پرسد:

«این ماه وضعیت سود نسبت به ماه قبل چطوره؟»

Copilot باید پاسخ را در سطح مدیریتی ارائه کند:

Milk revenue
Feed cost
Treatment cost
Hidden waste
Net margin

یعنی خروجی باید با Role کاربر تطبیق پیدا کند.

---

قابلیت گزارش دوره‌ای

Copilot می‌تواند برای:

• گزارش روزانه
• گزارش هفتگی دامپزشک
• گزارش تغذیه
• گزارش تولیدمثل
• گزارش ماهانه مدیریت

Template داشته باشد.

در نتیجه یک سؤال:

«گزارش هفتگی مدیریت رو بساز.»

می‌تواند یک گزارش استاندارد و قابل مقایسه تولید کند.

---

چرا Template مهم است؟

اگر AI هر هفته ساختار کاملاً متفاوتی بسازد، مقایسه سخت می‌شود.

بنابراین بهتر است:

Data
↓
Fixed Report Template
↓
AI Commentary

استفاده شود.

---

گزارش خودکار نباید جای Dashboard را بگیرد

Copilot و BI مکمل هم هستند.

Dashboard برای مشاهده سریع دائمی.

Copilot برای سؤال آزاد.

مثلاً Dashboard می‌گوید:

Pregnancy Rate = 31%

Copilot می‌تواند جواب دهد:

«چرا این ماه Pregnancy Rate کاهش پیدا کرده؟»

---

آینده: Agentic Farm Copilot

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

مثلاً پس از تأیید مدیر:

Create vet checklist
Create follow-up task
Schedule pregnancy check
Export report
Notify nutritionist

اما تفاوت مهم وجود دارد:

Read Action

با:

Write Action

یکسان نیست.

هر اقدام تغییردهنده باید کنترل و Permission جداگانه داشته باشد.

---

Human Approval برای Action

مثلاً AI می‌گوید:

29 repeat breeders detected.

Create ultrasound checklist?

کاربر:

Confirm

سپس سیستم Action انجام می‌دهد.

نه اینکه AI مستقل تغییر عملیاتی ایجاد کند.

---

آینده واقعی Farm Copilot

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

او فقط باید مسئله را بداند.

مثلاً:

«چرا هزینه خوراک بالا رفته؟»

یا:

«کدوم گاوها سودده نیستن؟»

یا:

«چه چیزهایی امروز عقب افتاده؟»

Copilot مسئول پیدا کردن مسیر مناسب در سیستم است.

---

مهم‌ترین تحول

در نرم‌افزار سنتی:

کاربر باید بداند
اطلاعات کجاست.

در سیستم Copilot:

سیستم باید بداند
اطلاعات کجاست.

این تغییر ظاهراً ساده می‌تواند نحوه استفاده از نرم‌افزارهای مدیریت فارم را اساساً تغییر دهد.

---

جمع‌بندی

AI Farm Copilot نباید یک ChatGPT تزئینی در گوشه سامانه گاوداری باشد.

یک Copilot واقعی باید به‌صورت امن به:

• داده دام
• تولید شیر
• سلامت
• درمان
• تولیدمثل
• خوراک
• Digital Twin
• CBR
• Hidden Waste
• BI

متصل باشد.

وقتی مدیر سؤال می‌کند:

«چند گاو بیشتر از ۱۲۰ روز باز داریم؟»

عدد باید از دیتابیس بیاید.

وقتی می‌پرسد:

«چرا گاو ۱۲۴۰ هشدار گرفته؟»

دلیل باید از موتور تحلیل بیاید.

وقتی می‌گوید:

«اکسل بده.»

فایل باید از همان داده واقعی ساخته شود.

و وقتی داده کافی وجود ندارد، سیستم باید صریحاً بگوید:

«اطلاعات کافی ندارم.»

ارزش واقعی Copilot در تولید متن زیبا نیست.

ارزش آن در حذف فاصله بین:

سؤال مدیریتی

و:

داده واقعی

است.

در یک سامانه کامل، مدیر دیگر مجبور نیست برای دریافت پاسخ، زبان دیتابیس، SQL، مسیر منوها یا نام گزارش‌ها را بداند.

او به زبان خودش سؤال می‌کند.

سامانه داده را پیدا می‌کند.

Query را کنترل می‌کند.

نتیجه را اعتبارسنجی می‌کند.

و پاسخ را در قالب مناسب برمی‌گرداند.

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

---