گوگل Gemini 3.5 Transcribe را به یک speech stack توسعه‌دهنده تبدیل می‌کند

گوگل مدل Gemini 3.5 Transcribe را عرضه کرده است؛ مدلی برای تبدیل گفتار به متن که به‌طور مشخص برای transcription زنده و فایل‌های صوتی طراحی شده، نه برای reasoning عمومی روی صدا. توسعه‌دهندگان آن را از طریق Gemini API در اختیار دارند و برای فایل‌های معمولی و streaming کم‌تأخیر endpointهای جداگانه وجود دارد. تغییر عملی این است که گوگل قابلیت‌هایی را که معمولاً به چند جزء مجزا در pipeline گفتار نیاز دارند، در یک سطح مدل جمع کرده است: تشخیص خودکار زبان، جابه‌جایی میان زبان‌ها، speaker diarization، timestamp در سطح کلمه، vocabulary biasing سفارشی و حالت «smart» که می‌تواند گفتار نامنظم را به متن تمیز و قالب‌بندی‌شده تبدیل کند.

این ترکیب برای تیم‌هایی که voice agent، سامانه جلسه، تحلیل تماس، ابزارهای accessibility، workflowهای رسانه‌ای یا هر محصولی می‌سازند که در آن گفتار یک جریان داده production است اهمیت دارد. این عرضه ثابت نمی‌کند Gemini 3.5 Transcribe در همه شرایط از سیستم‌های رقیب دقیق‌تر است و ادعاهای performance گوگل همچنان ادعاهای vendor هستند. اما رفتار مستند API واقعاً دامنه کاری را تغییر می‌دهد و می‌تواند نیاز به pipeline جداگانه برای transcription، diarization، normalization و formatting را کاهش دهد.

یک خانواده مدل برای فایل و stream زنده

گوگل دو شناسه مدل ارائه می‌کند. gemini-3.5-transcribe برای فایل صوتی آپلودشده است و gemini-3.5-transcribe-live برای transcription زنده از طریق Gemini Live API طراحی شده است. endpoint فایل می‌تواند تا یک ساعت صوت را در هر درخواست بگیرد، هرچند فعال‌کردن diarization یا timestamp کلمه‌ای سقف را به ۳۰ دقیقه کاهش می‌دهد. endpoint زنده sessionهایی تا ۱۰ دقیقه را پشتیبانی می‌کند.

این تفکیک مهم است چون transcription batch و real-time محدودیت‌های مهندسی متفاوتی دارند. پردازش فایل می‌تواند post-processing کامل‌تری انجام دهد و speaker label و timestamp هر کلمه را برگرداند. transcription زنده اولویت را به خروجی incremental و کم‌تأخیر می‌دهد. مستندات گوگل می‌گوید endpoint زنده تشخیص خودکار زبان، vocabulary سفارشی و smart transcription را دارد، اما diarization و timestamp در سطح کلمه را ارائه نمی‌کند.

برای توسعه‌دهنده، نتیجه این است که یک خانواده مدل می‌تواند هم مصاحبه آپلودشده، هم مکالمه زنده پشتیبانی و هم رابط صوتی را پوشش دهد، بدون اینکه همه کاربردها مجبور باشند از یک مجموعه feature یکسان استفاده کنند. محدودیت‌ها نیز در سطح API روشن هستند.

چندزبانه بودن و vocabulary تخصصی وارد لایه اصلی API می‌شوند

Gemini 3.5 Transcribe بیش از ۸۵ زبان را به‌طور خودکار تشخیص می‌دهد و می‌تواند در طول یک session میان زبان‌ها جابه‌جا شود. برای محصولاتی که کاربران چندزبانه دارند، این یک تغییر workflow واقعی است چون لازم نیست توسعه‌دهنده پیش از شروع transcription یک زبان واحد انتخاب کند.

مدل همچنین custom vocabulary biasing با حداکثر ۱۰۰۰ اصطلاح را پشتیبانی می‌کند. گوگل برای بهترین نتیجه فهرست‌های کوچک‌تر را توصیه می‌کند، اما خود قابلیت برای حوزه‌هایی مهم است که نام‌ها، acronymها، کد محصول، اصطلاحات پزشکی، حقوقی یا jargon داخلی معمولاً به خطای transcription منجر می‌شوند. به‌جای اصلاح بعدی، برنامه می‌تواند واژه‌های موردنظر را در request وارد کند.

گوگل برای فایل‌های صوتی diarization تا هشت speaker را مستند کرده است، ولی attribution برای سه speaker یا بیشتر experimental است. timestamp کلمه‌ای نیز وجود دارد، اما گوگل هشدار می‌دهد فعال‌کردن آن ممکن است accuracy کلی transcription را کاهش دهد. بنابراین این مدل یک configuration نیست که همه featureها همیشه هم‌زمان روشن باشند؛ تیم باید trade-off مناسب workflow خود را انتخاب کند.

Smart transcription خروجی را از گفتار خام به متن قابل‌استفاده تبدیل می‌کند

نظرآمیزترین feature حالت «smart transcription» است. در حالت verbatim، مدل filler wordها، false startها، repetition و شکل گفتاری مکالمه را نگه می‌دارد. در حالت smart، disfluencyها حذف می‌شوند، self-correctionهای درون جمله حل می‌شوند، punctuation و capitalization اعمال می‌شود و فهرست‌ها، تاریخ‌ها، پول و عددهای گفته‌شده می‌توانند به شکل خواناتر قالب‌بندی شوند.

این قابلیت مفید است، اما contract معنایی خروجی را تغییر می‌دهد. transcript خام سندی از چیزی است که گفته شده است. transcript هوشمند بازنمایی تفسیرشده‌ای از چیزی است که مدل فکر می‌کند گوینده قصد بیانش را داشته. برای note-taking، meeting summary، dictation و voice interface این دقیقاً می‌تواند مطلوب باشد. اما برای legal discovery، compliance recording، روزنامه‌نگاری، آرشیو تماس regulated یا هر workflow که wording دقیق مهم است، لازم است نسخه verbatim جداگانه حفظ شود.

گوگل محدودیت مهم دیگری را نیز صریح بیان می‌کند: smart mode را نمی‌توان هم‌زمان با diarization یا timestamp کلمه‌ای استفاده کرد. بنابراین میان متن polished و metadata غنی‌تر provenance یک انتخاب معماری وجود دارد. سیستمی که هر دو را نیاز دارد ممکن است به دو pass نیاز داشته باشد.

اتصال مستقیم به stack توسعه و محصولات گوگل

گوگل می‌گوید این مدل هم‌اکنون پشت برخی قابلیت‌های voice مانند Rambler در Android و transcription در Gemini app روی macOS قرار دارد. توسعه‌دهندگان می‌توانند از Google AI Studio و Gemini API به آن دسترسی داشته باشند و گوگل آن را برای voice agent، caption زنده و post-call analytics نیز هدف گرفته است.

سطح integration از مثال‌های consumer مهم‌تر است. مدل live از WebSocket استفاده می‌کند و به همین دلیل برای stackهای ارتباط real-time و رابط‌های agent که هنگام صحبت کاربر به stream متنی پیوسته نیاز دارند مناسب است. مستندات توسعه‌دهنده گوگل همچنین به platformهایی مانند Agora، LiveKit، Pipecat و Vercel اشاره می‌کند.

Ars Technica به‌طور مستقل عرضه را گزارش کرده و همین حرکت از speech recognition معمولی به متن تمیز و ساختاریافته را برجسته کرده است. این رسانه همچنین به ادعای گوگل درباره کاهش latency و error rate نسبت به Chirp 3 اشاره می‌کند. این اعداد باید تا زمان replication مستقل به‌عنوان ادعاهای گوگل تلقی شوند، اما وجود API و featureهای عرضه‌شده به پذیرش آن benchmarkها وابسته نیست.

تیم‌های مهندسی پیش از مهاجرت چه چیزی را باید بسنجند

سؤال اول این نیست که Gemini 3.5 Transcribe در benchmark برنده است یا نه. سؤال این است که feature set یکپارچه آن آیا پیچیدگی یک application واقعی را کم می‌کند. تیم‌هایی که امروز speech recognition، diarization، vocabulary adaptation، formatting و cleanup جداگانه دارند ممکن است بخش‌هایی از pipeline را حذف کنند. تیم‌هایی که ASR تخصصی و بسیار tune‌شده دارند ممکن است سود کمتری ببرند.

ارزیابی باید code-switching، accent، محیط noisy، proper noun، vocabulary تخصصی، speakerهای هم‌پوشان، sessionهای طولانی و رفتار failure در smart transcription وقتی معنا ambiguous است را پوشش دهد. در workflowهای regulated یا auditable، توسعه‌دهندگان باید خروجی verbatim و smart را با هم مقایسه کنند و مشخص کنند کدام نسخه record رسمی است.

Latency نیز باید end-to-end سنجیده شود. low-latency بودن مدل تضمین نمی‌کند کل برنامه سریع باشد اگر microphone capture، network transport، WebSocket، buffering، callهای بعدی agent یا rendering UI زمان غالب را مصرف کنند. درباره cost هم همین‌طور است: قیمت مدل مهم است، اما مقایسه اقتصادی باید componentهایی را هم حساب کند که API یکپارچه جایگزین می‌کند.

اهمیت بزرگ‌تر Gemini 3.5 Transcribe بنابراین معماری است. گوگل transcription را از یک primitive محدود speech recognition به API مدل غنی‌تری تبدیل می‌کند که می‌تواند هم متن و هم structure آماده workflow تولید کند. برای تیم‌های voice agent و محصولات صوتی، این یک starting point ساده‌تر است، اما هم‌زمان تصمیم‌های جدید درباره provenance، interpretation و trade-off featureها را وارد طراحی application می‌کند.

Sources
- Intelligent transcription with Gemini 3.5 Transcribe
- Gemini 3.5 Transcribe model documentation
- Google announces Gemini 3.5 Transcribe for AI-powered speech-to-text