شهریور
آموزش هوش مصنوعی
پروژهٔ پایانی: گزارش ماهانهٔ خودکار از دادهٔ کسبوکار
در چهار مقالهٔ قبلی این مجموعه، خروجی ساختاریافته، پاکسازی داده، نوشتن SQL با هوش مصنوعی و معماری گزارشگیری خودکار را جداگانه بررسی کردیم. این مقاله همهٔ اینها را در یک پروژهٔ واحد و قابلاجرا کنار هم میگذارد: ساخت یک گزارش ماهانهٔ خودکار که هر اول ماه، بدون دخالت دستی، خلاصهای از عملکرد کسبوکار را آماده و ارسال میکند. هدف این نیست که یک کد آماده کپی-پیست شود، بلکه نقشهٔ راهی است که برای هر دیتابیس و هر کسبوکار قابل تطبیق است.
لیست مطالب
پیشنیازها
پیش از شروع، این موارد باید آماده باشند: دسترسی خواندن (فقط SELECT) به دیتابیس یا انبار داده؛ فهرست دقیق متریکهایی که باید در گزارش باشند (مثلاً درآمد، تعداد سفارش، مشتری جدید، نرخ بازگشت)؛ یک کانال توزیع مشخص (ایمیل، Telegram، Slack)؛ و یک محیط اجرای زمانبندیشده (cron، یک workflow engine، یا حتی یک تسک زمانبندیشدهٔ ساده).
مراحل ساخت
- متریکها را دقیق تعریف کنید. برای هر متریک، منبع دقیق (کدام جدول، کدام فیلد)، بازهٔ زمانی (اول تا آخر ماه میلادی یا شمسی) و نحوهٔ محاسبه را مکتوب کنید. ابهام در این مرحله، بعداً به گزارش نادرست منجر میشود.
- کوئریهای ثابت بنویسید، نه پویا. برای هر متریک یک کوئری SQL از پیش نوشته و تستشده بسازید. این کوئریها را طبق روال مقالهٔ سوم — با
SELECT COUNT(*)تستی پیش از هرگونه تغییر — بررسی کنید. مدل زبانی در این پروژه هرگز کوئری نمیسازد یا اجرا نمیکند؛ فقط نتیجهٔ آماده را میخواند. - خروجی استخراج را در قالب JSON ساختاریافته بسازید. طبق الگوی مقالهٔ اول، یک schema ثابت برای دادهٔ خروجی هر ماه تعریف کنید (متریک فعلی، متریک ماه قبل، نام دوره) تا لایهٔ بعدی همیشه ورودی قابلپیشبینی دریافت کند.
- دادهٔ ورودی را پیش از تفسیر پاکسازی کنید. اگر متریکها از منابع مختلف جمع میشوند (مثلاً یک بخش از CRM و یک بخش از فروشگاه)، طبق اصول مقالهٔ دوم، فرمت تاریخ و اعداد را یکدست کنید تا مقایسهٔ ماه به ماه معنادار باشد.
- promptِ تفسیر را با محدودیت صریح بنویسید. از مدل بخواهید فقط از اعداد ورودی استفاده کند، هیچ رقمی نسازد، و در صورت وجود ناهماهنگی بین متریکها آن را صریح اعلام کند — دقیقاً همان الگوی مقالهٔ چهارم.
- زمانبندی را تنظیم کنید. اجرای خودکار در یک تاریخ ثابت (مثلاً روز اول هر ماه، ساعت ۸ صبح) با یک مکانیزم قابلاتکا (cron، workflow scheduler) راهاندازی کنید. اطمینان حاصل کنید که در صورت شکست اجرا (مثلاً دیتابیس در دسترس نبود)، یک هشدار جداگانه — نه خودِ گزارش خالی — ارسال شود.
- یک مرحلهٔ بازبینی انسانی قبل از ارسال نهایی بگذارید. در حداقل دو تا سه دورهٔ اول، گزارش تولیدشده باید پیش از رفتن به مخاطب نهایی، توسط یک نفر خوانده و تأیید شود.
- کانال توزیع و آرشیو را وصل کنید. گزارش نهایی همراه با دادهٔ خام (نه فقط خلاصهٔ متنی) در یک مکان قابلجستوجو (مثلاً یک پوشه یا دیتابیس آرشیو) ذخیره شود تا قابل مقایسه و verify باشد.
- یک چرخهٔ بازبینی دورهای تعریف کنید. هر سه تا شش ماه، متریکها، کوئریها و promptِ تفسیر را دوباره مرور کنید تا با تغییرات کسبوکار (مثلاً متریک جدید، تغییر ساختار جدول) هماهنگ بمانند.
چکلیست پیش از راهاندازی نهایی
| مورد | وضعیت مطلوب |
|---|---|
| دسترسی دیتابیس | فقط خواندن (SELECT)، بدون دسترسی نوشتن |
| کوئریهای متریک | ثابت، از پیش تستشده، بدون ساخت پویا توسط مدل |
| schema ورودی به مدل تفسیر | JSON ساختاریافته با فیلدهای مشخص و اجباری |
| محدودیت صریح در prompt | عدم ساخت یا حدس عدد؛ اعلام صریح ناهماهنگی داده |
| مدیریت خطای اجرا | هشدار جداگانه در صورت شکست، نه ارسال گزارش ناقص |
| بازبینی انسانی | فعال برای حداقل دو تا سه دورهٔ اول |
| آرشیو داده خام | ذخیرهشده و قابل جستوجو، جدا از خلاصهٔ متنی |
| زمانبندی چرخهٔ بازبینی | مشخص (مثلاً هر سه ماه) |
این پروژه نقطهٔ تلاقی چهار مفهومی است که در این مجموعه دیدیم: خروجیِ ماشینخوان، دادهٔ تمیز، کوئری قابلاعتماد، و تفسیر مسئولانه. برای مرور دوبارهٔ هرکدام، به نقشهٔ راه هوش مصنوعی و داده و برای تقویت مهارت نوشتن دستورهای دقیقتر، به نقشهٔ راه مهندسی پرامپت مراجعه کنید.
نکاتی که فراتر از مراحل اصلی باید در نظر گرفت
دو نکتهٔ تکمیلی، در کنار نُه گام اصلی، تفاوت بین یک پروژهٔ کاری و یک پروژهٔ شکننده را میسازد. اول، نسخهبندی prompt تفسیر: هر بار که متن دستور مدل تغییر میکند (حتی یک جمله)، خروجی ماههای بعدی میتواند لحن یا ساختار متفاوتی نسبت به ماههای قبل داشته باشد. نگهداشتن تاریخچهٔ نسخههای prompt، همراه با تاریخ اعمال هر تغییر، تفسیر مقایسهای بین ماههای مختلف را قابلاتکا نگه میدارد. دوم، تعریف رفتار سیستم در صورت نبود دادهٔ کافی برای مقایسه (مثلاً اولین ماه اجرای سیستم که دادهٔ «ماه قبل» وجود ندارد) — این حالت باید از قبل در طراحی schema و prompt پیشبینی شود، نه اینکه مدل با نبود داده مواجه و خروجی غیرمنتظره تولید کند.
نمونهای از خروجی نهایی
یک خروجی خوب برای این پروژه، معمولاً یک پیام کوتاه با سه بخش است: یک پاراگراف روند کلی ماه (رشد یا افت نسبت به ماه قبل)، یک فهرست از نکات قابلتوجه (مثلاً یک متریک با تغییر غیرمعمول)، و در صورت وجود، یک هشدار صریح دربارهٔ ناهماهنگی یا نقص داده. طول این خروجی باید عمداً کوتاه نگه داشته شود — هدف گزارش ماهانه این نیست که همهٔ جزئیات را بازگو کند، بلکه باید مخاطب را در چند ثانیه به تصویر کلی برساند و در صورت نیاز به جزئیات بیشتر، او را به دادهٔ خام آرشیوشده ارجاع دهد.
جمعبندی
- استخراج داده (کوئری ثابت) و تفسیر داده (مدل زبانی) را همیشه در دو مرحلهٔ کاملاً جدا نگه دارید.
- هر متریک باید تعریف، منبع و بازهٔ زمانی مکتوب داشته باشد تا ابهام از بین برود.
- از مدل تفسیر بخواهید هرگز عدد نسازد و ناهماهنگی داده را صریح اعلام کند.
- در چند دورهٔ نخست، بازبینی انسانی پیش از ارسال نهایی را حذف نکنید.
- دادهٔ خام هر گزارش را آرشیو و قابل verify نگه دارید، نه فقط خروجی متنی نهایی.
