اسٹارٹ اپس اور کاروبار

Gemini 3.5 Transcribe بولی سنوارتا ہے، لفظ بہ لفظ ریکارڈ نہیں

|مصنف: QUASA ادارتی ٹیم|6 منٹ مطالعہ
Gemini 3.5 Transcribe بولی سنوارتا ہے، لفظ بہ لفظ ریکارڈ نہیں

Google نے 26 اگست 2026 کو Gemini 3.5 Transcribe متعارف کرایا اور developers کو Gemini API کے ذریعے اس تک رسائی دی۔ Ars Technica کی رپورٹ کے مطابق ماڈل filler words اور بولتے ہوئے کی گئی اصلاحات ہٹا کر گفتگو کو صاف، مرتب متن میں بدل سکتا ہے۔

یہی صلاحیت اس خبر کی اہم حد بھی ہے: عنوان کا دعویٰ Smart mode کے نتیجے پر صادق آتا ہے، پورے ماڈل پر نہیں۔ اسی API میں default verbatim mode بھی ہے، جو اصل بولے گئے الفاظ محفوظ کرنے کے لیے بنایا گیا ہے؛ اس لیے صاف interview copy اور قابلِ حوالہ ریکارڈ کو ایک ہی چیز سمجھنا درست نہیں۔

Recorded اور live audio کے لیے الگ راستے ہیں

Gemini 3.5 Transcribe میں ریکارڈ شدہ انٹرویو اور براہِ راست آواز کے الگ transcription راستے

Gemini 3.5 Transcribe ایک واحد، ہر حالت میں یکساں API نہیں۔ پہلے سے ریکارڈ شدہ فائل کے لیے gemini-3.5-transcribe استعمال ہوتا ہے، جبکہ microphone یا جاری audio stream کے لیے gemini-3.5-transcribe-live Live API سے چلتا ہے۔ Recorded route speaker attribution اور word-level timestamps دے سکتا ہے؛ live route میں یہ دونوں خصوصیات دستیاب نہیں۔

Google کی سرکاری transcription دستاویزات کے مطابق recorded request عام حالت میں ایک گھنٹے تک ہو سکتی ہے، مگر speaker diarization یا word timestamps فعال ہوں تو حد 30 منٹ رہ جاتی ہے۔ Live session مسلسل 10 منٹ تک چلتا ہے، Smart mode کو timestamps یا diarization کے ساتھ نہیں ملایا جا سکتا، اور تین یا زیادہ speakers کی attribution تجرباتی ہے، اگرچہ recorded endpoint زیادہ سے زیادہ آٹھ speakers قبول کرتا ہے۔

زبان کے معاملے میں بھی پاکستانی خریدار کے لیے ایک اہم خلا ہے۔ Google کی موجودہ فہرست 85 سے زیادہ locales دکھاتی ہے، مگر اس میں اردو یا پاکستان کا کوئی locale درج نہیں؛ پنجابی اور عربی رسم الخط والی سندھی کے موجودہ codes بھارت سے منسوب ہیں۔ خودکار language detection اور code-switching کی عمومی حمایت موجود ہے، لیکن اسے پاکستانی اردو، مقامی لہجوں یا اردو-انگریزی ملی گفتگو کی ثابت شدہ accuracy نہیں سمجھا جا سکتا۔

Smart mode عبارت بناتا ہے، شہادتی نقل نہیں

ایک ہی گفتگو کا Smart متن صاف عبارت اور verbatim متن اصل تکرار و تصحیح کے ساتھ

Smart mode کا مقصد پڑھنے میں آسان متن ہے۔ یہ ”اُم“ جیسے filler words، ہکلاہٹ، تکرار اور false starts نکال سکتا ہے، punctuation اور paragraphs ترتیب دیتا ہے، اور بولتے ہوئے کی گئی تصحیح کو آخری مراد میں بدل دیتا ہے۔ مثال کے طور پر ”منگل—نہیں، بدھ“ کا نتیجہ صرف ”بدھ“ بن سکتا ہے۔

Verbatim mode اس کے برعکس filler words، تکرار، توقف اور نامکمل آغاز محفوظ رکھنے کے لیے default ہے۔ Speaker labels اور ہر لفظ کے start اور end offsets بھی اسی mode کے اندر مانگے جاتے ہیں۔ تاہم Google متنبہ کرتا ہے کہ word-level timestamps فعال کرنے سے transcription accuracy کم ہو سکتی ہے؛ timestamp کی موجودگی خود لفظ کی صحت کی ضمانت نہیں۔

یہ فرق پاکستانی صحافتی interview میں براہِ راست اثر ڈالتا ہے۔ اشاعت کے لیے صاف copy مفید ہو سکتی ہے، مگر کسی quote میں ہچکچاہٹ، ابتدائی عدد یا فوری self-correction معنی بدل سکتی ہے۔ اگر اصل الفاظ اہم ہوں تو verbatim نتیجہ اور source audio بنیادی ریکارڈ رہنے چاہییں، جبکہ Smart متن کو ان سے اخذ کردہ قابلِ مطالعہ نسخہ سمجھنا زیادہ واضح ہے۔

قانونی نقل میں mode سے زیادہ provenance اہم ہے

قانونی، تفتیشی یا disciplinary audio میں Smart output کو لفظ بہ لفظ نقل کہنا درست نہیں ہوگا۔ ماڈل جان بوجھ کر disfluencies ہٹا اور اعداد، تاریخوں یا فہرستوں کو نئی تحریری صورت دے سکتا ہے۔ ایسی تبدیلی readability بہتر کرتی ہے، مگر یہ نہیں بتاتی کہ مقرر نے عین کون سے الفاظ کس ترتیب سے کہے تھے۔

زیادہ قابلِ جانچ ترتیب میں اصل audio file الگ محفوظ ہوگی، verbatim transcript اس سے منسلک ہوگا اور نام، تاریخ، رقم، شناختی نمبر یا قانونی دفعہ جیسے حساس حصے انسان audio سے ملائے گا۔ Speaker attribution اور timestamps تلاش آسان بناتے ہیں، لیکن نہ وہ مقرر کی قانونی شناخت ثابت کرتے ہیں اور نہ AI transcript کو خود بخود certified record بناتے ہیں۔

Developers کے لیے اصل فیصلہ output کی مطلوبہ نوعیت سے شروع ہوتا ہے۔ صاف dictation یا readable notes کے لیے Smart mode موزوں امیدوار ہے؛ quote sheet، تحقیقی interview یا audit trail کے لیے verbatim mode، محفوظ audio اور انسانی توثیق درکار ہے۔ Live captions کو recorded، annotated transcript کا متبادل سمجھنے سے بھی گریز ضروری ہے، کیونکہ live endpoint speaker labels اور word-level timing نہیں دیتا۔

صاف متن hallucination کو زیادہ معتبر دکھا سکتا ہے

قانونی نقل میں Gemini 3.5 Transcribe کے نام، تاریخ اور رقم کی اصل آڈیو سے تصدیق

Google DeepMind کا model card Transcribe اور Transcribe Live میں foundation-model hallucinations کے علاوہ کبھی کبھار سست response اور timeout کو معروف حدود میں شمار کرتا ہے۔ اس کا مطلب ہے کہ روانی سے مرتب جملہ لازماً audio کا درست عکس نہیں؛ ماڈل ایسا لفظ یا فقرہ بھی پیدا کر سکتا ہے جو مقرر نے نہیں کہا۔

Smart formatting یہ مسئلہ نظروں سے چھپا سکتی ہے، کیونکہ درست punctuation، صاف paragraphs اور منظم اعداد output کو انسانی تدوین جیسا اعتماد بخش دیتے ہیں۔ اسی لیے کسی اہم نام، رقم، تاریخ، وعدے یا قانونی عبارت کی منظوری صرف متن دیکھ کر نہیں ہونی چاہیے۔ Timeout کے بعد دوبارہ حاصل شدہ output بھی پہلے transcript میں خاموشی سے شامل کرنے کے بجائے source audio کے مقابل الگ جانچا جانا چاہیے۔

  • Smart mode: صاف dictation، readable notes اور ایسی copy جہاں تدوین قابلِ قبول ہو۔
  • Verbatim mode: اصل الفاظ، filler، تکرار اور self-corrections محفوظ رکھنے کے لیے۔
  • Recorded route: speaker labels اور word-level timestamps درکار ہوں تو، مقررہ دورانیے کی حد کے ساتھ۔
  • Live route: فوری captions یا voice interface کے لیے، مگر مکمل annotated record کے طور پر نہیں۔
  • حساس استعمال: اصل audio، مقامی test set اور انسانی جانچ کے بغیر AI output کو حتمی ریکارڈ نہ سمجھا جائے۔

فی الحال Google نے عمومی multilingual صلاحیت، code-switching اور مختلف accents سنبھالنے کے دعوے کیے ہیں، مگر پاکستانی اردو، مقامی شور، صوبائی لہجوں یا عدالتی audio پر الگ آزاد benchmark دستیاب نہیں۔ اس لیے Gemini 3.5 Transcribe کی ثابت شدہ خبر API رسائی اور Smart و verbatim workflows کی واضح تقسیم ہے؛ پاکستان میں اس کی عملی صحت کا فیصلہ مقامی audio پر جانچ کے بعد ہی ہو سکے گا۔

یہ بھی پڑھیں:

شیئر کریں:

ہمارا نیوز لیٹر سبسکرائب کریں

ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔

0