تصور کنید صاحب یک فروشگاه کوچک صنایع دستی هستید، مثلاً در پلتفرم Etsy، که سرامیک و شمع می‌فروشید. ناگهان متوجه می‌شوید فروش روز سه‌شنبه شما خوب بوده اما فروش روز پنجشنبه به‌شدت سقوط کرده است؛ در این لحظه شما دو گزینه دارید: یا باید ساعت‌ها روی جداول پیچیده اکسل خیره شوید و سعی کنید الگوها را پیدا کنید، یا اینکه صرفاً بر اساس حدس و گمان تصمیم بگیرید. ابزار SalesWhy دقیقاً برای حل این مشکل ساخته شده تا علت دقیق افت درآمد را به زبان ساده (انگلیسی یا تلوگو) برای کارآفرینان خرد توضیح دهد.
این ابزار در حالی معرفی شده که بسیاری از کسب‌وکارهای خرد با تفسیر صفحات گسترده (Spreadsheets) دست‌وپنجه نرم می‌کنند و توان مالی استخدام تحلیل‌گران داده گران‌قیمت را ندارند. همان‌طور که پیش‌تر پوشش دادیم که چگونه محتوای تولید شده توسط هوش مصنوعی منجر به ممنوعیت نوشتن با LLMها در ویکی‌پدیا در سال ۲۰۲۶ شد، این مورد نیز تنش متفاوتی را برجسته می‌کند: تقابل میان «قابلیت اطمینان صلب و سخت‌گیرانه کدهای سنتی» و «قدرت تشخیص الگوی شهودی مدل‌های زبانی بزرگ».
SalesWhy برای چالش متن‌باز AI در Hacktoberfest (هفته دوم با موضوع "Side Hustle") طراحی شده و بر یک اصل سخت‌گیرانه استوار است: مدل زبانی هرگز نباید اجازه داشته باشد علت افت فروش را «تصمیم» بگیرد. در عوض، مدل فقط باید نتیجه‌ای را که پیش از آن توسط محاسبات ریاضی و قطعی به دست آمده است، به زبان انسانی ترجمه و بیان کند.
طبق مستندات این پروژه، خط لوله (Pipeline) سیستم یک توالی مشخص را دنبال می‌کند:
- TabPFN — یک مدل محلی با وزن‌های باز (Open Weights) که درآمد روزانه مورد انتظار را بر اساس داده‌های تاریخی فروشنده پیش‌بینی می‌کند. این مدل به تنظیم هایپرپارامترها (Hyperparameter tuning) نیاز ندارد و همین ویژگی اجازه می‌دهد تا در عرض چند ثانیه روی فایل CSV یک کاربر ناشناس بازآموزی شود.
- یک تابع قطعی (Deterministic)، افت‌های درآمدی (یا جهش‌ها) را که برای دو روز یا بیشتر به‌طور متوالی تداوم داشته‌اند، شناسایی و علامت‌گذاری می‌کند.
- سیستم سپس متغیرهایی مثل قیمت، هزینه ارسال و تعداد محصولات فعال را در بازه زمانی علامت‌گذاری شده، با یک خط مبنای (Baseline) ۱۴ روزه مقایسه کرده و محتمل‌ترین علت را رتبه‌بندی می‌کند.
- اگر هیچ‌یک از این معیارها تغییر قابل‌توجهی نکرده باشند، سیستم به‌جای حدس زدن، صراحتاً اعلام می‌کند که «مطمئن نیست».
- در نهایت، مدل Gemma 3 (4B) که از طریق Ollama به‌صورت محلی اجرا می‌شود، داده‌های فنی (مثلاً
{"cause": "stockout", "change_pct": 43.5}) را به سه جمله خوانا به زبان انگلیسی یا تلوگو تبدیل می‌کند.
به گزارش توسعه‌دهنده این ابزار، SalesWhy از زبان پایتون و یک نقطه اتصال (Endpoint) در FastAPI استفاده می‌کند. برای حفظ سرعت و قابلیت اطمینان، این ابزار از چارچوب‌های پیچیدهٔ عامل‌محور (Agentic Frameworks) دوری کرده است. قابلیت‌های کلیدی این ابزار عبارتند از:
- CSV Auto-Mapper: این قابلیت به‌طور خودکار ستون‌های مربوط به تاریخ، مبلغ، تعداد و محصول را شناسایی و نگاشت می‌کند. این امر باعث می‌شود ابزار بدون نیاز به تغییر فرمت فایل توسط کاربر، با خروجی‌های Shopify، Etsy یا فایل‌های تراکنش خام سازگار باشد.
- What-If Estimator: یک ابزار تحلیل متقابل (Counterfactual) که درآمد را مجدداً پیش‌بینی می‌کند تا به فروشنده بگوید: «اگر قیمت را بالا نمی‌بردید، فروش شما تقریباً X می‌شد».
- خروجی‌های بصری: اپلیکیشن نموداری تولید می‌کند که فروش واقعی را در مقابل فروش پیش‌بینی‌شده نشان می‌دهد و هفته‌های بحرانی را با سایه‌زنی و برچسب مشخص می‌کند.
- Ledger-Slip Export: تولید یک اسکرین‌شات PNG قابل اشتراک است که کاربر می‌تواند آن را از طریق واتس‌اپ برای شریک تجاری یا تأمین‌کننده خود ارسال کند تا علت افت عملکرد را توضیح دهد.
برای سنجش کارایی و اعتبارسنجی ابزار، توسعه‌دهنده ۳۰ مورد افت فروش مصنوعی با علت‌های مشخص (مانند افزایش قیمت، اتمام موجودی کالا و جهش هزینه‌های حمل‌ونقل) را در داده‌های واقعی فروشندگان از مجموعه داده‌های تجارت الکترونیک Olist تزریق کرد. نتایج به‌دست‌آمده یک شکاف ضدشهودی در دقت را آشکار کرد.
بر اساس گزارش منتشر شده در dev.to، خط لوله قطعی و مهندسی‌شده تنها ۳۶.۷٪ صحت (Accuracy) داشت. در مقابل، یک مدل زبانی عمومی (Gemini از طریق API) که دقیقاً همان داده‌های خام و یک سؤال ساده («چرا فروش افت کرد؟») را دریافت کرده بود، به صحت ۵۳.۳٪ رسید. این اختلاف ۱۶.۶ درصدی برای توسعه‌دهنده غافلگیرکننده بود، زیرا انتظار داشت سیستم مهندسی‌شده به‌راحتی پیروز شود.
با این حال، توسعه‌دهنده اشاره می‌کند که رویکرد SalesWhy علی‌رغم امتیاز پایین‌تر، یک مزیت ساختاری حیاتی دارد: خط لوله قطعی نمی‌تواند پاسخ‌های غیرواقعی اما متقاعدکننده ابداع کند. این سیستم فقط می‌تواند قیمت، حمل‌ونقل، موجودی را نام ببرد یا اعتراف کند که «مطمئن نیست». این رویکرد یادآور اهمیت پیاده‌سازی لایه‌های کنترلی است، مشابه آنچه در کاهش نرخ خطای تست‌های تولیدشده با AI از طریق حفاظ‌های مهندسی مشاهده شد تا از توهمات مدل جلوگیری شود.
در مقابل، مدل زبانی عمومی گاهی اوقات با اطمینان کامل پاسخ‌های غلط می‌داد. در برخی موارد، مدل به‌جای شناسایی علت واقعی (مانند افزایش قیمت که منجر به افت شد)، روی «نشانه» یا symptom تمرکز می‌کرد و می‌گفت «تعداد سفارشات کاهش یافته است». توسعه‌دهنده حتی متوجه یک باگ در سیستم امتیازدهی شد؛ جایی که طبقه‌بندی‌کننده کلمات کلیدی، پاسخ LLM را غلط تشخیص داده بود چون مدل از عبارت «صفر محصول فعال» به‌جای کلمه مورد انتظار یعنی «موجودی» (Stock) استفاده کرده بود. این نوع چالش‌ها نشان‌دهنده شکاف درک فنی در عصر عامل‌هاست، جایی که خروجی‌های AI ممکن است از نظر معنایی درست اما از نظر ساختاری با انتظارات سیستم‌های سنتی ناسازگار باشند.
استفاده از مدل‌های با وزن‌های باز مثل TabPFN و Gemma 3 دو مزیت عملیاتی ایجاد می‌کند:
۱. هزینه: برای صاحب فروشگاهی که هفته‌ای چند بار اعدادش را چک می‌کند، هزینه هر پرس‌وجو (Per-query cost) باید نزدیک به صفر باشد. اجرای محلی Gemma هیچ هزینه‌ای جز سخت‌افزاری که روی آن اجرا می‌شود ندارد و این موضوع باعث می‌شود مدل اشتراک ماهانه ۵ تا ۱۰ دلاری به عنوان یک مدل تجاری viable باشد.
۲. حریم خصوصی: چون TabPFN و Gemma روی همان دستگاهی اجرا می‌شوند که فایل CSV در آن آپلود شده است، حریم خصوصی یک واقعیت فنی است و نه یک ادعای بازاریابی. برای اثبات این موضوع، در پایین صفحه اپلیکیشن، پیکربندی زنده (Live Config) نمایش داده می‌شود تا کاربر ببیند داده‌ها دقیقاً کجا پردازش می‌شوند.
این شفافیت به توسعه‌دهنده اجازه داد تا شکاف عملکرد را در طول ارزیابی شناسایی کند. چون کل پشته (Stack) نرم‌افزاری قابل بازرسی بود، شکست خط لوله قطعی به‌جای اینکه یک باگ پنهان پشت یک API اختصاصی باشد، به یک نقطه یادگیری تبدیل شد.
در مراحل نهایی، توسعه‌دهنده برای بهبود تجربه کاربری، یک «تست غریبه» انجام داد؛ به این صورت که از اپلیکیشن بدون توضیح قبلی درباره رابط کاربری (UI) استفاده کرد. بازخورد اولیه این بود که ظاهر برنامه «بیش از حد خسته‌کننده» است. این منجر به پیاده‌سازی هدرهای مهر-مانند (Stamp-mark)، ردیف‌های رنگی در دفتر کل و نمودارهای سفارشی شد تا جایگزین جعبه‌های ساده با حاشیه قدیمی شوند.
این آزمایش نشان می‌دهد که اگرچه LLMها در تشخیص خام الگوهای داده‌های جدولی برتری دارند، اما هنوز فاقد دقت علّی (Causal Rigor) لازم برای حسابرسی‌های مالی حساس در کسب‌وکار هستند. چالش اصلی همچنان در ادغام دقت بالای LLMها با حفاظ‌های (Guardrails) مطلق منطق قطعی است.
کاربران علاقه‌مند می‌توانند دمو را در saleswhy.onrender.com تست کنند (با استفاده از دکمه "Try sample shop" برای دموی سریع) یا مخزن گیت‌هاب را کلون کنند. نصب محلی تنها به سه دستور نیاز دارد: کلون کردن مخزن، نصب نیازمندی‌ها (Requirements) و دریافت مدل gemma3:4b از طریق Ollama.
گام بعدی شما
- اگر داده‌های فروش دارید، دمو را در saleswhy.onrender.com تست کنید.
- برای اجرای محلی، مخزن گیت‌هاب را کلون کرده و مدل
gemma3:4bرا از طریق Ollama دریافت کنید. - بررسی کنید آیا در کسب‌وکار شما هم مدل‌های زبانی در تحلیل‌های سریع بهتر از فرمول‌های ثابت عمل می‌کنند یا خیر.
اما داستان سخت‌افزاری اجرای محلی این مدل‌ها حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های NPU در لپ‌تاپ‌های جدید مراجعه کنید.
گفتگو