Digisky
در حال بهره‌برداریdatacopilot.ir →

دیتاکوپایلوت

چرخهٔ «پرسش تا پاسخ» را از پنج تا هفت روز به چند دقیقه می‌رساند — و مسیر استدلالش را نشان می‌دهد.

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

۲۸۷عملیات HTTP ثبت‌شده
۳۰آداپتور پایگاه‌داده
۱۷,۱۳۷تابع آزمون بک‌اند
۳۳۸,۲۶۸خط کد آزمون
۶۹جدول پایگاه‌داده
۱۱۷مهاجرت اسکیما

هر عدد اندازه‌گیری شده و روش اندازه‌گیری‌اش ثبت است. عددی که اندازه نگرفته باشیم اینجا نمی‌آید.

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

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

هزینهٔ اصلی تأخیر نیست. هزینهٔ اصلی این است که پرسش‌های ارزشمند اصلاً پرسیده نمی‌شوند.

پرسش چهارم

ببینید بر سر یک خط بررسی واقعی چه می‌آید، وقتی هر گام چند روز طول بکشد:

۱. روز ۱ — «سود عملیاتی این منطقه چه روندی داشته؟» یک عدد. هنوز هیچ توضیحی نیست. ۲. روز ۸ — «کاهش از سمت درآمد بوده یا هزینه؟» ۳. روز ۱۵ — «کدام واحدها بیشترین سهم را داشته‌اند؟» ۴. هرگز پرسیده نمی‌شود — «آیا این واحدها ویژگی مشترکی دارند؟»

پاسخ واقعی در گام چهارم است. با هزینهٔ امروزِ پرسیدن، تقریباً هیچ‌کس به آن نمی‌رسد.

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

داشبورد یک واقعیت را نشان می‌دهد: فروش شعبهٔ فلان پایین آمده. تفسیر، ریشه‌یابی و اثبات بر عهدهٔ انسان می‌ماند — و صف دقیقاً همان‌جا تشکیل می‌شود.

دیتاکوپایلوت خودِ بررسی را انجام می‌دهد:

۱. درک مسئله — پرسش مبهم به دامنه‌ای روشن تبدیل می‌شود. ۲. انتخاب منابع — منابع مرتبط از میان سامانه‌های متصل انتخاب می‌شوند. ۳. ساخت فرضیه — چند توضیح رقیب هم‌زمان مطرح می‌شود. ۴. تحلیل — هر فرضیه روی دادهٔ واقعی آزموده می‌شود. ۵. سنجش شواهد — آنچه تأیید نشود کنار گذاشته می‌شود. ۶. یافتن علت — علت یا الگوی تکرارشونده شناسایی می‌شود. ۷. پاسخ مستند — نتیجه همراه با ارقام پشتیبان ارائه می‌شود. ۸. ادامه — پرسش بعدی ارزان است، پس زنجیره متوقف نمی‌شود.

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

شواهد، نه ادعا

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

  1. نتیجه — یافته، به‌روشنی بیان‌شده
  2. منابع — کدام جدول‌ها، از کدام اتصال‌ها
  3. کوئری — همان SQL که واقعاً اجرا شد
  4. روش — تعریف تأییدشدهٔ سازمان، نه تعریف عمومی
  5. شواهد — سطرهای پشتیبان، قابل برون‌بری

این زنجیره برای تیم داده است، برای حسابرسی، و برای هر کسی که باید تصمیم را امضا کند.

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

مدل استقرار، مهم‌ترین تصمیم محصول است:

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

آنچه نیست

  • ERP نیست.
  • انبار داده نیست.
  • گزارش‌ساز نیست — هرچند داشبورد می‌سازد.
  • چت‌بات عمومی نیست. به پرسش‌های شما دربارهٔ دادهٔ شما، از دل همان داده پاسخ می‌دهد.

تصمیم‌های فنی

و آنچه انتخاب نکردیم، همراه با دلیلش.

حلقهٔ عامل روی ۱۲۸ گام محدود شد، به‌جای اجرای نامحدود.

گزینه‌های دیگر: حلقهٔ ReAct نامحدود، خط لولهٔ کوتاه و ثابت

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

پیش‌فرض ۱۲۸، قابل تنظیم بین ۱ تا ۵۱۲.

مسیر مدل محلی از طریق Ollama یک مسیر درجه‌یک است، نه راه‌حل جایگزین.

گزینه‌های دیگر: فقط API ابری، ابری با حالت آفلاینِ محدود

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

مدل فعال در جدول تنظیمات نگهداری می‌شود، نه در پیکربندی.

گزینه‌های دیگر: متغیر محیطی، ثابت‌های مدل به تفکیک ارائه‌دهنده

انتخاب مدل سریع‌تر از چرخهٔ استقرار تغییر می‌کند. وقتی داده باشد نه کد، اپراتور بدون انتشار نسخه مدل را عوض می‌کند.

محدودیت‌ها

  • به پرسش‌هایی دربارهٔ داده‌ای که وصل کرده‌اید پاسخ می‌دهد. جایگزین ERP یا انبار داده نیست.
  • روی پایگاه‌دادهٔ شما نمی‌نویسد. هر پرس‌وجو در تراکنش فقط‌خواندنی و زمان‌دار اجرا می‌شود؛ بنابراین هر گردش‌کاری که نیاز به نوشتن دارد، از ابتدا خارج از دامنهٔ محصول است.
  • کیفیت پاسخ به کیفیت اسکیما وابسته است. پایگاه‌داده‌ای با نام ستون‌های مستندنشده و بدون یکپارچگی ارجاعی، پاسخ ضعیف‌تری می‌دهد و هیچ مدل زبانی این را جبران نمی‌کند.
  • امروز در دو سازمان مستقر است. این محصولی است نوپا با مهندسی عمیق پشت آن — نه محصولی با استقرار گسترده — و ترجیح می‌دهیم پیش از اولین جلسه بدانید.
  • پرسش به زبان طبیعی روی اسکیماهای بسیار عریض همچنان دشوار است. جدول‌های عمومی text-to-SQL به‌شدت بهتر شده‌اند، اما با خودشان هم‌خوان نیستند: همان خانوادهٔ سنجه امروز روی یک بخش حدود ۹۶٪ و روی سخت‌ترین بخشش حدود ۶۶٪ می‌دهد، و آن نتایج متعلق به سامانه‌هایی است که مخصوص یک سنجهٔ ثابت و عمومی ساخته شده‌اند. هیچ عدد جدول رتبه‌بندی، دقت روی اسکیمایی را که کسی ندیده پیش‌بینی نمی‌کند. لایهٔ معنایی برای کم‌کردن این فاصله ساخته شده، نه برای وانمودکردن به بسته‌شدنش — و تنها عدد قابل اعتماد، عددی است که روی اسکیمای خودتان اندازه گرفته شود.