مایکروسافت با Foundry IQ فایل‌های صوتی جلسات را به پایگاه دانش تبدیل کرد

تصور کنید به جای گشتن در ساعت‌ها فایل صوتی برای یافتن یک تصمیم قدیمی، کافی باشد از یک دستیار بپرسید «در جلسه ماه پیش درباره بودجه چه توافق شد؟» و او دقیقاً ثانیه‌ای را که پاسخ در آن است به شما نشان دهد. یک ساعت ضبط صوتی از جلسات معمولاً به عنوان یک «دارایی مرده» در سازمان‌ها ذخیره می‌شود؛ فایلی با فرمت MP4 که قابلیت جست‌وجو یا پرس‌وجو ندارد. مایکروسافت با معرفی Microsoft Foundry و قابلیت Foundry IQ، فاصله میان فایل‌های صوتی خام و عامل‌های پاسخ‌گو را از طریق یک خط لوله یکپارچه از تبدیل سریع گفتار به متن و بازیابی هوشمند از بین برده است.

این قابلیت در زمانی ارائه می‌شود که سازمان‌ها با انفجار داده‌های ویدئویی داخلی دست‌وپنجه نرم می‌کنند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی عامل‌های هوش مصنوعی اشاره کردیم، چالش اصلی این سیستم‌ها، دسترسی به داده‌های به‌روز و اختصاصی سازمان‌هاست. در حالی که پیش‌تر بر توانایی عامل‌های مایکروسافت (Microsoft Agents) در کارهای تخصصی مثل تکمیل تست‌های واحد (Unit-test completion) تمرکز داشتیم، اکنون تمرکز بر تبدیل گفتگوهای تاریخی سازمان به دانش عملی است. برای اکثر تیم‌ها، این به معنای تغییر وضعیت از «فکر می‌کنم در ماه می این تصمیم را گرفتیم» به یک ارجاع دقیق است که نشان می‌دهد چه کسی، در چه ثانیه‌ای، دقیقاً چه چیزی گفته است.

تغییرات نام‌گذاری و زیرساخت

پیش از بررسی پیاده‌سازی، توجه به یک تغییر اخیر در برندینگ مایکروسافت ضروری است. در کنفرانس Ignite ۲۰۲۵، مایکروسافت نام Azure AI Foundry را به Microsoft Foundry تغییر داد؛ تغییری که در مفاد محصول (Product Terms) ژانویه ۲۰۲۶ رسمیت یافت.

اگرچه پلتفرم زیربنایی ثابت مانده است، اما اکنون دو تجربه کاربری متفاوت در پورتال و دو نسل از SDKها وجود دارد. خط تولید ۱.x GA برای نسخه‌های «Foundry classic» هدف‌گذاری شده است، در حالی که نسخه پیش‌نمایش ۲.x از کتابخانه azure-ai-projects برای پورتال و APIهای جدید Foundry طراحی شده است. معماری مورد بحث در این مقاله از خط تولید ۲.x و رابط عامل‌های مبتنی بر Responses استفاده می‌کند.

معماری جذب داده‌ها

این خط لوله در دو بخش مجزا و مستقل عمل می‌کند: یک فاز جذب داده‌های دسته‌ای (Batch-driven ingestion) و یک فاز بازیابی هم‌زمان (Synchronous retrieval). این جداسازی استراتژیک باعث می‌شود که برای باز-اندکس کردن داده‌ها یا تغییر استراتژی‌های بازیابی، نیازی به پردازش مجدد و هزینه‌بر فایل‌های صوتی اصلی نباشد.

به نقل از راهنمای فنی منتشر شده در ۱۱ اوت ۲۰۲۶ در وب‌سایت dev.to، فرآیند با قرارگیری یک فایل ضبط شده در یک کانتینر Blob آغاز می‌شود. یک Trigger از نوع Event Grid پیامی را به یک صف (Queue) ارسال می‌کند که در نهایت یک Azure Function را فعال می‌سازد. وجود این صف در معماری بسیار حیاتی است؛ زیرا از اشباع شدن منابع Speech و بروز خطاهای ۴۲۹ (Too Many Requests) در هنگام آپلود انبوه فایل‌های آرشیوی جلوگیری می‌کند. این ساختار به توسعه‌دهندگان اجازه می‌دهد تا مقدار batchSize را در فایل host.json محدود کرده و بار ورودی را مدیریت کنند.

احراز هویت و تنظیمات

برای راه‌اندازی این پروژه، کاربران باید اطمینان حاصل کنند که گزینه «New Foundry» در پورتال فعال شده است. پیش‌نیاز اصلی، داشتن نقطه اتصال پروژه (Project Endpoint) است که از فرمت https://<resource-name>.services.ai.azure.com/api/projects/<project-name> پیروی می‌کند.

احراز هویت به طور سخت‌گیرانه از طریق Entra ID مدیریت می‌شود و هیچ راه جایگزینی مبتنی بر کلید (Key-based) وجود ندارد. برای محیط توسعه، داشتن نقش Azure AI User الزامی است. اما برای خط لوله تولید (Production)، باید به یک Managed Identity کاربر-تعیین‌شده، هر دو نقش Azure AI User و Storage Blob Data Contributor اختصاص یابد. محیط سیستم معمولاً با متغیرهای FOUNDRY_PROJECT_ENDPOINT و SPEECH_RESOURCE_NAME پیکربندی می‌شود.

تبدیل سریع گفتار به متن و تفکیک گوینده

سیستم از نقطه اتصال /speechtotext/transcriptions:transcribe (نسخه API ۲۰۲۵-۱۰-۱۵) استفاده می‌کند. برخلاف تبدیل دسته‌ای (Batch transcription)، قابلیت «تبدیل سریع» (Fast transcription) نتایج را به جای حالت Real-time، در عرض چند ثانیه به صورت هم‌زمان برمی‌گرداند که برای فایل‌های موجود ایده‌آل است. اگرچه تبدیل دسته‌ای برای آرشیوهای بسیار طولانی یا سفارشی‌سازی‌های پیشرفته برتری دارد، اما تبدیل سریع تأخیر (Latency) پیش‌بینی‌پذیری را برای ضبط‌های استاندارد یک‌ساعته فراهم می‌کند.

مشخصات فنی کلیدی این بخش عبارتند از:

• تفکیک گوینده (Diarization): این سرویس می‌تواند تا ۳۵ گوینده مجزا را در یک کانال صوتی تشخیص دهد و پس از آن با خطا مواجه می‌شود.
• فیلتر کلمات نامناسب (Profanity Filtering): این گزینه روی «None» تنظیم می‌شود تا از ماسک شدن توکن‌ها جلوگیری شود. تنظیم پیش‌فرض «Masked» کلمات را با ستاره جایگزین می‌کند که به شدت به کیفیت بازیابی آسیب می‌زند، زیرا این توکن‌ها با هیچ موردی در ایندکس مطابقت ندارند.
• منطق تلاش مجدد (Retry Logic): پیاده‌سازی سیستم به هدر Retry-After احترام می‌گذارد تا از مشکل «گله تندرهای» (Thundering Herd) در هنگام محدود شدن درخواست‌ها جلوگیری کند. همچنین از یک مدل Exponential Backoff محدود با مهلت سخاوتمندانه ۶۰۰ ثانیه استفاده می‌کند تا آپلود فایل‌های حجیم در مسیرهای خروجی با پهنای باند محدود را مدیریت کند.

تبدیل جملات به تکه‌های متنی زمینه‌ای

جملات خام حاصل از تبدیل گفتار برای سیستم‌های تولید بازیابی‌افزا (RAG) بیش از حد کوتاه هستند. برای مثال، جمله‌ای مانند «من موافقم» هیچ اسمی ندارد و تقریباً غیرقابل بازیابی است. برای حل این مشکل، خط لوله جملات را با استفاده از یک گارد سکوت ۴۰۰۰ میلی‌ثانیه‌ای (۴ ثانیه) به «نوبت‌های گوینده» (Speaker turns) دسته‌بندی می‌کند. این گارد مانع از آن می‌شود که صحبت‌های یک فرد در دقیقه سوم و دوباره در دقیقه چهلم، در صورتی که کسی بین آن‌ها صحبت نکرده باشد، در یک تکه بی‌معنی ادغام شوند.

برای تبدیل این نوبت‌ها به محتوای قابل جست‌وجو، سیستم از یک فراخوان مدل کوچک (مانند gpt-4.1-mini) استفاده می‌کند تا برای هر نوبت، یک خلاصه موقعیتی تک‌جمله‌ای تولید کند. این خلاصه، موضوع و هرگونه تصمیم اتخاذ شده را نام می‌برد و تضمین می‌کند که حتی کوتاه‌ترین گفته‌ها نیز پیش از ایندکس شدن به صورت فایل‌های JSONL، دارای زمینه (Context) باشند.

هر رکورد با موارد زیر غنی‌سازی می‌شود:

• شناسه تکه (Chunk ID): یک شناسه منحصر‌به‌فرد که ترکیبی از شناسه جلسه و برچسب زمانی شروع است (مثلاً meetingid-000000001).
• کد زمانی (Timecode): با فرمت MM:SS که اجازه می‌دهد ارجاعات به عنوان لینک‌های عمیق (Deep links) به پخش‌کننده ویدیو عمل کنند.
• محتوا: ترکیبی از زمینه تولید شده توسط مدل و متن خام گوینده.

لایه بازیابی Foundry IQ

Foundry IQ به عنوان لایه دانش و بازیابی عمل می‌کند که بر روی Azure AI Search بنا شده است. این لایه از یک ساختار تودرتو استفاده می‌کند که در آن یک «منبع دانش» (Knowledge source) به محتوا اشاره می‌کند و یک «پایگاه دانش» (Knowledge base) این منابع را برای دسترسی عامل‌ها بسته‌بندی می‌کند. قابلیت‌های بازیابی عامل‌محور (Agentic retrieval) در API نسخه ۲۰۲۶-۰۴-۰۱ به صورت GA در دسترس هستند، در حالی که نسخه پیش‌نمایش ۲۰۲۶-۰۵-۰۱ قابلیت اتصال LLMها به منابع غیروب را اضافه کرده است.

کیفیت بازیابی از طریق یک اهرم به نام «تلاش استدلالی» (Reasoning effort) مدیریت می‌شود که متغیر اصلی برای کنترل تأخیر و هزینه است:

• Minimal: تک‌مرحله‌ای و نتایج استخراجی. بهترین گزینه برای سوالات جست‌وجوی ساده که کاربر نام یک جلسه خاص را ذکر می‌کند.
• Low: تجزیه پرس‌وجو (Query decomposition) در میان منابع مختلف. مناسب برای اکثر ترافیک‌های چت تعاملی.
• Medium: جست‌وجوی تکرارشونده و برنامه‌ریزی غنی‌تر. ایده‌آل برای سوالات تحلیلی که چندین جلسه مختلف را در بر می‌گیرد.

استقرار عامل تحلیل‌گر جلسات

عامل نهایی با استفاده از پروتکل Responses در SDK نسخه ۲.x ساخته می‌شود. این عامل تحت دستورات سخت‌گیرانه‌ای است تا از ایجاد هویت‌های «توهمی» جلوگیری شود. از آنجا که تفکیک گوینده برچسب‌هایی مانند «Speaker 2» ارائه می‌دهد و نه نام واقعی، عامل صراحتاً منع شده است که نام‌های واقعی را حدس بزند، مگر اینکه این نام‌ها از متادیتای تقویم استخراج و نگاشت شده باشند.

قوانین کلیدی عامل عبارتند از:

• هر ادعای واقعی باید دارای ارجاعی باشد که عنوان جلسه، تاریخ و کد زمانی را ذکر کند.
• عامل باید اختلافات را برجسته کند، به جای اینکه آن‌ها را در یک اجماع کاذب ساده کند.
• باید تفاوت بین یک «تصمیم» و یک «پیشنهاد» را با نقل‌قول مستقیم از زبان مورد استفاده مشخص کند.
• در صورتی که هیچ پشتیبانی در متن‌ها یافت نشد، عامل باید صراحتاً این موضوع را اعلام کرده و متوقف شود.

حلقه ارزیابی و معیارهای تولید

برای اطمینان از آمادگی برای محیط تولید، سیستم از یک استراتژی اندازه‌گیری دوگانه استفاده می‌کند. دقت تبدیل گفتار از طریق نرخ خطای کلمه (WER) اندازه‌گیری می‌شود، در حالی که کیفیت بازیابی توسط یک مدل داور (Judge model) برای سنجش میزان «مبنی‌سازی» (Groundedness) ارزیابی می‌گردد.

توسعه‌دهندگان تشویق می‌شوند تا یک «مجموعه طلایی» (Golden set) شامل حدود ۱۰۰ پرسش تأییدشده توسط انسان بسازند. این مجموعه باید شامل موارد «رد درخواست» (Refusal) باشد؛ یعنی سوالاتی که پاسخ آن‌ها واقعاً در داده‌ها موجود نیست، تا اطمینان حاصل شود که عامل به جای اختراع یک پاسخ متقاعدکننده اما غلط، نادانی خود را می‌پذیرد.

معیارهای دقیق برای استقرار

برای تایید نهایی استقرار در محیط تولید، چهار معیار خاص باید ردیابی شوند:

• WER روی اصطلاحات تخصصی: برای شناسایی لغزش‌های واژگانی و کیفیت بد صدا. این مورد از طریق «لیست‌های عبارت» (Phrase lists) برای کمک به شناسایی اصطلاحات داخلی سازمان اصلاح می‌شود.
• مبنی‌سازی (Groundedness): استفاده از ارزیاب داور داخلی برای شناسایی پاسخ‌هایی که توسط تکه‌های بازیابی‌شده پشتیبانی نمی‌شوند.
• اعتبار ارجاعات: یک بررسی قطعی (Deterministic) برای اطمینان از اینکه عناوین جلسات وجود دارند و کدهای زمانی در محدوده مدت زمان ضبط قرار دارند.
• نرخ رد درخواست: اندازه‌گیری توانایی عامل در گفتن «نمی‌دانم» زمانی که هیچ محتوای پشتیبانی‌کننده‌ای بازیابی نشده است.

تحلیل: گذار به RAG مدیریت‌شده

این معماری نشان‌دهنده یک چرخش قابل توجه از «پشته‌های دست‌ساز» (ترکیب Whisper + pyannote + Vector DB) به سمت راهکارهای مدیریت‌شده است. اگرچه میزبانی شخصی (Self-hosting) هزینه‌های کمتری در حجم‌های بسیار بالا و کنترل شدیدتری بر محل ذخیره داده‌ها (Data residency) ارائه می‌دهد، اما مسیر مدیریت‌شده زمان رسیدن به یک پاسخ کاربردی را از هفته‌ها به ساعت‌ها کاهش می‌دهد.

مقایسه مسیرهای پیاده‌سازی

ملاحظات محیط تولید

برای سازمان‌های بزرگ، حیاتی‌ترین جزئیات مربوط به مدل دسترسی است. از آنجا که منابع مبتنی بر Blob به‌طور خودکار دسترسی‌ها را به ارث نمی‌برند، سازمان‌ها باید یا از فیلترهای امنیتی در زمان پرس‌وجو استفاده کنند یا ضبط‌ها را به SharePoint منتقل کنند، جایی که برچسب‌های حساسیت Purview به طور بومی رعایت می‌شوند. این کار مانع از آن می‌شود که هوش مصنوعی به طور تصادفی محتوای یک جلسه محرمانه مدیران ارشد را برای یک کارمند جونیور لو دهد.

سایر تدابیر حفاظتی تولید عبارتند از:

• فراخوانی‌های مقاوم: پیاده‌سازی Full Jitter در زمان Backoff برای جلوگیری از فشار ناگهانی به سرویس در هنگام خطاهای گذرا (مانند ۴۰۸، ۴۰۹، ۴۲۹، ۵۰۰، ۵۰۲، ۵۰۳، ۵۰۴).
• ردیابی (Tracing): استفاده از ابزارهای ردیابی GenAI برای ثبت شناسه‌های تکه‌های بازیابی شده و برنامه‌های پرس‌وجو جهت عیب‌یابی پاسخ‌های نادرست.
• نسخه‌بندی: نسخه‌بندی منطق تکه‌بندی (Chunking logic) در رکوردها برای مدیریت محتواهای نسل‌های مختلف در طول مهاجرت داده‌ها.

گام بعدی شما

کاربرانی که در حال حاضر از جریان منسوخ شده «Azure OpenAI On Your Data» استفاده می‌کنند، باید برای مهاجرت خود پیش از تاریخ بازنشستگی ۱۴ اکتبر ۲۰۲۶ برنامه‌ریزی کنند. برای شروع انتقال به Agent Service و پشته Foundry IQ، SDK جدید Microsoft Foundry را بررسی کنید.

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