گزارش فنی و امکان‌سنجی: ادغام قابلیت صوت به متن (STT) بله در سامانه تدارکات هوشمند

Note

مخاطب گزارش: تیم فنی، معماران سیستم و مدیران محصول
موضوع: بررسی، مقایسه دو رویکرد فنی و نقشه راه پیاده‌سازی اتصال به موتور تبدیل ویس به متن پیام‌رسان «بله»
هدف نهایی: افزودن بله به عنوان یکی از مدل‌های کاندید در خط لوله STT چندمدله (Multi-Provider STT) جهت افزایش دقت استخراج اقلام تدارکات

۱. خلاصه مدیریتی (Executive Summary)

سامانه هوشمند تدارکات در حال حاضر مجهز به موتور پردازش موازی صوت (Multi-Provider STT) است که قادر است فایل‌های صوتی دریافتی از کاربران را هم‌زمان به چندین ارائه‌دهنده (نظیر Whisper، Soniox یا سرویس‌های ابری) ارسال کرده و از طریق مدل تحلیلی DeepSeek یک خروجی یکپارچه و دقیق (Consensus Text) به همراه اقلام استعلام استخراج کند.

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

روش اول (اتوماسیون رابط کاربری وب / Headless Browser): شبیه‌سازی رفتار کاربر در مرورگر و کلیک روی دکمه تبدیل وویس.
روش دوم (مهندسی معکوس پروتکل کلاینت / Direct Client API): شبیه‌سازی درخواست‌های شبکه (WebSocket/HTTP) کلاینت بله بدون نیاز به مرورگر.

۲. پس‌زمینه فنی زیرساخت بله (Technical Context)

بخش	وضعیت دسترسی	توضیحات
Bale Bot API (رسمی)	فاقد متد STT	فقط امکان دانلود فایل صوتی خام (`voice` / `audio`) با `file_id` را فراهم می‌کند.
کلاینت‌های کاربری بله (Web / Android)	دارای موتور فعال STT	روی هر ویس یک دکمه تبدیل صوت به متن وجود دارد که با فشرده شدن آن، صوت روی سرورهای بله به متن تبدیل می‌شود.
دستیار هوش مصنوعی بله	پشتیبانی از ورودی صوتی	کاربر با ارسال ویس به چت هوش مصنوعی بله، متن پیاده‌شده به همراه پاسخ تحلیلی را دریافت می‌کند.

نتیجه: برای بهره‌برداری از این قابلیت، بات تدارکات باید در لایه ارتباطی خود، یک نشست کاربری (User Session) در بله داشته باشد تا بتواند خدمات تبدیل صوت کلاینت را فراخوانی کند.

۳. روش اول: اتوماسیون رابط کاربری وب (Headless Browser Scraping)

در این رویکرد، یک مرورگر کنترل‌شده بدون واسط گرافیکی (مانند Chromium تحت فریم‌ورک Playwright) در یک کانتینر اختصاصی داکر مستقر شده و در نسخه وب بله (web.bale.ai) فعال نگه داشته می‌شود.

معماری جریان داده (Architecture Flow)

sequenceDiagram
    autonumber
    participant Bot as Procurement Bot
    participant Worker as Browser Worker (Playwright)
    participant BaleWeb as web.bale.ai (Chromium)
    participant BaleServer as سرورهای پردازش صوت بله

    Bot->>Worker: ارسال فایل صوتی (voice.mp3)
    Worker->>BaleWeb: بارگذاری فایل در چت کلاینت
    BaleWeb->>BaleServer: ارسال صوت و درخواست تبدیل
    BaleServer-->>BaleWeb: بازگرداندن متن پیاده‌شده به صفحه
    Worker->>BaleWeb: استخراج متن از DOM (.transcription-text)
    Worker-->>Bot: بازگرداندن متن خروجی به خط لوله STT

مؤلفه‌های پیاده‌سازی:

مدیریت نشست پایدار (Persistent Profile):
- پوشه پروفایل مرورگر (userDataDir) بر روی یک داکر ولوم ماندگار (/data/bale_browser_session) قرار می‌گیرد.
- ورود اولیه فقط یک‌بار توسط تیم فنی با شماره تلفن اختصاصی و کد OTP پیامکی انجام می‌شود و کوکی‌ها و توکن‌های LocalStorage/IndexedDB برای همیشه حفظ می‌گردند.
انتظار هوشمند بر اساس رخدادهای DOM:
- استفاده از سلکتورهای مقاوم با waitForSelector یا MutationObserver روی باکس متن ترنسکرایب.
مزایا و معایب:
- 🟢 تضمین تطابق با سرور: چون مرورگر رسمی در حال اجرا است، هیچ‌گونه ریسک ناسازگاری پکت‌های شبکه وجود ندارد.
- 🟢 پایداری در برابر تغییرات داخلی API: حتی اگر بله فریم‌ورک پکت‌های وب‌سوکت خود را عوض کند، تا زمانی که دکمه در UI وجود دارد سیستم کار می‌کند.
- 🔴 مصرف بالای منابع: هر نمونه Chromium حدود ۳۰۰ تا ۵۰۰ مگابایت رم اشغال می‌کند.
- 🔴 تاخیر زمانی (Latency): فرآیند رندر صفحه، شبیه‌سازی آپلود و رویداد کلیک حدود ۳ تا ۶ ثانیه زمان می‌برد.

۴. روش دوم: مهندسی معکوس شبکه و پروتکل کلاینت (Direct Client Protocol / gRPC-Web)

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

یافته‌های واقعی حاصل از بازرسی و تحلیل سورس‌کد لایو وب بله (`web.bale.ai`):

تیم ما اسکریپت‌های باندل تولیدی بله (/static/js/index.4aefbadad3.js و بسته‌های وابسته) را مستقیماً تحلیل کرد که نتایج فنی مهم زیر حاصل شد:

پروتکل زیرساختی: بله از APIهای متنی ساده (مانند REST یا JSON) استفاده نمی‌کند؛ بلکه کل ارتباطات کلاینت وب بر پایه gRPC-Web همراه با Protocol Buffers دودویی (@bufbuild/protobuf) پیاده‌سازی شده است.
آدرس‌های Gateway سرورهای بله:
- سرور gRPC پروداکشن: https://maviz-ws.bale.ai
- اتصال وب‌سوکت پروداکشن: wss://maviz-ws.bale.ai/ws/?uid={user_id}
- محیط‌های آزمایشی: beta-ws.bale.ai و next-ws.bale.ai
شناسه‌ها و فیچرهای کشف‌شده در کد:
- شناسه ماژول پیاده‌سازی صوت: u.SpeechTranscript = "SpeechTranscript"
- ماژول چت هوش مصنوعی: u.AIChat = "AIChat" با روت صفحه /${L.AI_CHAT}
- دامنه‌های مربوطه: domain_chat_ai: "app.all.domain_chat_ai" و chat_ai_ttl

ارزیابی فنی و چالش‌های روش دوم:

پیچیدگی بالای پیاده‌سازی: به دلیل استفاده از پکت‌های فشرده دودویی Protobuf، برای فراخوانی مستقیم در پایتون باید فایل‌های تعاریف اینترفیس (.proto) بله به صورت کامل مهندسی معکوس و دیکود شوند و فریم‌های ۵ بایتی استاندارد gRPC-Web در کلاینت پایتون کدگذاری گردند.
ریسک شکنندگی در تغییر اسکیما: با کوچک‌ترین تغییر در شماره فیلدهای Protobuf یا متدهای سرور بله در نسخه‌های جدید، کلاینت مهندسی معکوس‌شده از کار می‌افتد.

۵. ماتریس مقایسه جامع فنی (Technical Decision Matrix)

معیار ارزیابی	روش اول: اتوماسیون وب (Playwright)	روش دوم: مهندسی معکوس پروتکل کلاینت	اهمیت برای سیستم
تاخیر پاسخ‌دهی (Latency)	۳ تا ۶ ثانیه	زیر ۱ ثانیه ⚡️	بسیار بالا (تاثیر مستقیم روی UX وویس)
مصرف حافظه RAM	۳۵۰ الی ۵۰۰ مگابایت	کمتر از ۱۵ مگابایت 🪶	متوسط به بالا
هزینه پردازشی CPU	متوسط تا بالا (رندرینگ)	بسیار پایین (درخواست شبکه)	متوسط
پیچیدگی پیاده‌سازی اولیه	کم (طی چند ساعت با سلکتور)	متوسط (نیازمند اسنیف و دیکود پکت)	موقت
پایداری نشست کاربری (Session)	ذخیره در پوشه کاربری مرورگر	ذخیره توکن در متغیر محیطی / دیتابیس	بالا
ریسک تغییرات توسط بله	کم (مقاوم در برابر تغییر پروتکل)	نیازمند پایش در تغییر نسخه‌های ماژور	متوسط
قابلیت مقیاس‌پذیری (Scalability)	محدود (محدودیت منابع مرورگر)	نامحدود (ایسنک و چندنخی)	بالا

۶. نحوه اتصال به پایپ‌لاین STT چندمدله فعلی

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

graph TD
    Voice[وویس دریافتی کاربر از بله] --> FFMPEG[تبدیل یک‌باره به MP3]
    FFMPEG --> S1[مدل ۱: Whisper-Large]
    FFMPEG --> S2[مدل ۲: Soniox / OpenRouter]
    FFMPEG --> S3[مدل ۳: موتور صوت هوش مصنوعی بله]
    
    S1 --> Aggregator[تجمیع نتایج کاندیداها]
    S2 --> Aggregator
    S3 --> Aggregator
    
    Aggregator --> DeepSeek[تحلیلگر هوشمند DeepSeek]
    DeepSeek --> Final[متن اصلاح‌شده Consensus Text + استخراج اقلام استعلام JSON]

۷. نقشه راه پیشنهادی دو مرحله‌ای برای تیم توسعه (Recommended Roadmap)

Tip

نتیجه تست و تحلیل تجربی ترافیک: بر اساس آنالیز دقیق سورس‌کد لایو web.bale.ai که انجام شد، ماهیت درخواست‌های بله مشخص گردید: ارتباطات به صورت فریم‌های دودویی Protobuf + gRPC-Web است. بنابراین مهندسی معکوس پکت‌ها نیازمند استخراج و بازسازی مستمر فایل‌های .proto اختصاصی بله است که نگهداری آن را بسیار شکننده می‌کند.

نتیجه‌گیری و پیشنهاد نهایی: مناسب‌ترین، مطمئن‌ترین و پایدارترین گزینه برای استقرار در محصول، روش اول (اتوماسیون مرورگر با Playwright Worker) است: ۱. مرورگر به صورت طبیعی از وب‌سوکت و پروتکل Protobuf بله پشتیبانی می‌کند و نیازی به رمزگشایی پکت‌ها نیست. ۲. با یک سشن پایدار در داکر، وویس در صفحه پیاده شده و متن خروجی به شکل مطمئن به خط لوله Multi-STT تحویل داده می‌شود. ۳. پیاده‌سازی آن در قالب یک کانتینر ایزوله (bale-stt-worker) با یک اندپوینت سبک POST /transcribe سریعاً انجام می‌پذیرد.

تهیه شده جهت ارائه به تیم فنی و مدیران سیستم تدارکات هوشمند.

13 KiB Raw Blame History Unescape Escape