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

ایده اصلی این مقاله فقط ساخت یک «چت‌بات برای جلسه» نیست. هدف، ساخت یک محصول واقعی Voice AI روی VPS است که بتواند بخشی از فرایند مستندسازی جلسات را خودکار کند.

در نمونه‌ای که در ادامه می‌سازیم، جریان پردازش به این شکل است:

AI Meeting Assistant چیست و دقیقاً چه مشکلی را حل می‌کند؟

یک AI Meeting Assistant دستیار هوشمندی است که اطلاعات یک جلسه را دریافت می‌کند و بخشی از کارهای زمان‌بر بعد از جلسه را انجام می‌دهد. این سیستم می‌تواند از فایل صوتی یا جریان صوتی جلسه استفاده کند و آن را به اطلاعات ساختاریافته تبدیل کند.

تفاوت مهم این سیستم با یک ابزار ساده تبدیل صدا به متن در مرحله بعد از Transcription مشخص می‌شود. Whisper فقط متن را استخراج می‌کند، اما یک LLM می‌تواند از همان متن، مواردی مثل تصمیمات، وظایف، افراد مسئول، مهلت‌ها و خلاصه مدیریتی تولید کند.

پروژه‌های متن‌باز مختلفی نیز همین معماری را دنبال می‌کنند؛ برای نمونه، پروژه‌های Local Meeting Assistant از ترکیب Whisper، تشخیص گوینده و LLM محلی برای تولید خلاصه جلسه استفاده می‌کنند. نمونه معماری Local Meeting Assistant در GitHub نیز همین تفکیک را نشان می‌دهد.

چرا اجرای Meeting Assistant روی VPS جذاب است؟

در سرویس‌های ابری معمولاً فایل صوتی جلسه ابتدا از زیرساخت شما خارج می‌شود و سپس در سرویس دیگری پردازش می‌شود. برای بعضی تیم‌ها این موضوع از نظر حریم خصوصی، سیاست سازمانی یا محل نگهداری داده اهمیت زیادی دارد.

در یک معماری Self-Hosted می‌توان اجزای اصلی را روی زیرساخت تحت کنترل خودتان قرار داد. در این حالت فایل صوتی، Transcript و خروجی جلسه می‌توانند روی سرور خودتان پردازش و ذخیره شوند.

معماری پیشنهادی برای ساخت سیستم AI Meeting Assistant

برای شروع، بهتر است پروژه را به چند لایه مستقل تقسیم کنیم. این کار باعث می‌شود بعدها بتوانید مدل Speech-to-Text یا LLM را بدون بازنویسی کل سیستم تغییر دهید.

برای AI Meeting Assistant چه سروری لازم است؟

انتخاب VPS در این پروژه مستقیماً به اندازه مدل، تعداد جلسات و مدت زمان پردازش بستگی دارد. نمی‌توان یک مشخصات ثابت را برای تمام سناریوها مناسب دانست.

نکته: این اعداد نقطه شروع معماری هستند، نه تضمین زمان پردازش. اندازه مدل Whisper، مدل LLM، طول فایل، تعداد هم‌زمانی و نوع CPU یا GPU نتیجه واقعی را تغییر می‌دهند.

مرحله اول؛ آماده‌سازی VPS لینوکس

برای این آموزش می‌توان از Ubuntu Server استفاده کرد. بهتر است سرور حداقل 4 هسته CPU و 8GB RAM داشته باشد. اگر قرار است مدل‌های بزرگ‌تر یا چند پردازش هم‌زمان اجرا شوند، منابع بیشتری در نظر بگیرید.

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

sudo apt update && sudo apt upgrade -y
sudo apt install -y ffmpeg python3 python3-pip python3-venv git curl

ساخت محیط Python

mkdir -p ~/meeting-assistant
cd ~/meeting-assistant

python3 -m venv venv
source venv/bin/activate

python -m pip install --upgrade pip

مرحله دوم؛ نصب موتور تبدیل صدا به متن

Whisper یکی از شناخته‌شده‌ترین مدل‌های OpenAI برای Automatic Speech Recognition است و مدل‌های مختلفی از نظر اندازه و توان پردازشی دارد. مخزن رسمی OpenAI Whisper اطلاعات مدل و روش اجرای آن را ارائه می‌کند.

برای یک سرور واقعی، استفاده از faster-whisper می‌تواند گزینه مناسبی باشد. این پروژه Whisper را با CTranslate2 اجرا می‌کند و برای کاهش مصرف منابع و افزایش سرعت طراحی شده است. مخزن رسمی faster-whisper

در این آموزش، برای سادگی نسخه Python را نصب می‌کنیم:

pip install faster-whisper

چرا faster-whisper برای VPS جالب است؟

در یک Meeting Assistant، فایل‌های صوتی ممکن است طولانی باشند. بنابراین سرعت پردازش STT اهمیت زیادی دارد. faster-whisper از CTranslate2 استفاده می‌کند و طبق مستندات پروژه، امکان استفاده از محاسبات 8-bit را نیز فراهم می‌کند. این ویژگی می‌تواند در سناریوهای محدود از نظر منابع مفید باشد.

مرحله سوم؛ ساخت اولین Speech-to-Text

یک فایل صوتی را در پوشه پروژه قرار دهید. برای مثال می‌توانیم فایل را meeting.mp3 نام‌گذاری کنیم.

سپس فایل Python زیر را بسازید:

nano transcribe.py

محتوای فایل:

from faster_whisper import WhisperModel

model = WhisperModel(
    "small",
    device="cpu",
    compute_type="int8"
)

segments, info = model.transcribe(
    "meeting.mp3",
    beam_size=5
)

with open("transcript.txt", "w", encoding="utf-8") as f:
    for segment in segments:
        line = f"[{segment.start:.2f} - {segment.end:.2f}] {segment.text.strip()}\n"
        print(line, end="")
        f.write(line)

اجرای برنامه:

python transcribe.py

پس از پردازش، فایل transcript.txt شامل متن جلسه خواهد بود.

مرحله چهارم؛ چرا فقط Transcript کافی نیست؟

اگر یک جلسه 90 دقیقه‌ای داشته باشید، خروجی Whisper ممکن است هزاران کلمه باشد. کاربر معمولاً نمی‌خواهد دوباره هزاران خط متن را بخواند.

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

باکس پیشنهادی برای زیرساخت AI روی VPS

مرحله پنجم؛ نصب Ollama برای اجرای LLM محلی

برای تحلیل Transcript به یک مدل زبانی نیاز داریم. یکی از ساده‌ترین روش‌ها برای اجرای مدل‌های محلی، استفاده از Ollama است.

وب‌سایت رسمی Ollama و مستندات آن، روش اجرای مدل‌های زبانی روی سیستم شخصی و سرور را ارائه می‌کنند.

در لینوکس می‌توانید نصب Ollama را با روش رسمی پروژه انجام دهید:

curl -fsSL https://ollama.com/install.sh | sh

بعد از نصب، یک مدل زبانی مناسب را دریافت کنید. نام مدل را می‌توانید بر اساس منابع سرور تغییر دهید:

ollama pull qwen3:8b

برای آزمایش:

ollama run qwen3:8b

مرحله ششم؛ تبدیل Transcript به خلاصه جلسه

اکنون می‌توانیم Transcript را به LLM ارسال کنیم. برای کنترل کیفیت، بهتر است از یک Prompt ساختاریافته استفاده کنیم.

نمونه Prompt مناسب برای Meeting Assistant:

You are an AI meeting assistant.

Analyze the meeting transcript below.

Return the result in this structure:

1. Executive Summary
2. Key Discussion Points
3. Decisions
4. Action Items
5. Open Questions
6. Important Dates
7. Risks or Blockers

For every action item, include:
- Task
- Responsible person, if explicitly mentioned
- Deadline, if explicitly mentioned

Do not invent names, deadlines, decisions, or facts.

Meeting transcript:
{{TRANSCRIPT}}

آخرین جمله بسیار مهم است. یک Meeting Assistant نباید اطلاعاتی را که در جلسه وجود نداشته به‌عنوان واقعیت تولید کند. بنابراین باید در Prompt تأکید شود که نام، مسئول، تاریخ و تصمیم جدید ساخته نشود.

ساخت اسکریپت کامل برای اتصال Whisper به Ollama

اکنون می‌توانیم یک نمونه ساده بسازیم که Transcript را بخواند و آن را برای LLM ارسال کند.

import requests

with open("transcript.txt", "r", encoding="utf-8") as f:
    transcript = f.read()

prompt = f"""
You are an AI meeting assistant.

Create a structured meeting report.

Return:
1. Executive Summary
2. Key Discussion Points
3. Decisions
4. Action Items
5. Open Questions
6. Important Dates
7. Risks or Blockers

Do not invent information.

Transcript:
{transcript}
"""

response = requests.post(
    "http://127.0.0.1:11434/api/generate",
    json={
        "model": "qwen3:8b",
        "prompt": prompt,
        "stream": False
    },
    timeout=1800
)

response.raise_for_status()

result = response.json()["response"]

with open("meeting-report.md", "w", encoding="utf-8") as f:
    f.write(result)

print(result)

کتابخانه Requests را نیز نصب کنید:

pip install requests

اکنون معماری اولیه شما عملاً ساخته شده است:

مرحله هفتم؛ اضافه کردن تشخیص گوینده به جلسه

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

برای جلسه‌های چندنفره، Speaker Diarization اهمیت زیادی دارد. WhisperX برای این کار امکاناتی مانند Word-level Timestamp و Speaker Diarization ارائه می‌کند. صفحه رسمی WhisperX در GitHub جزئیات این معماری را توضیح می‌دهد.

نصب اولیه WhisperX در محیط Python:

pip install whisperx

در این حالت خروجی می‌تواند اطلاعاتی مانند زمان شروع و پایان صحبت و برچسب گوینده داشته باشد. این اطلاعات بعداً به LLM داده می‌شود تا مثلاً بتواند Action Itemها را بهتر به افراد نسبت دهد.

ساخت خروجی استاندارد برای Action Itemها

اگر هدف شما ساخت یک محصول واقعی باشد، بهتر است LLM را مجبور کنید خروجی مشخصی تولید کند. برای مثال می‌توان ساختار JSON را درخواست کرد.

{
  "summary": "...",
  "decisions": [
    "..."
  ],
  "action_items": [
    {
      "task": "...",
      "owner": "...",
      "deadline": "..."
    }
  ],
  "open_questions": [
    "..."
  ]
}

این روش نسبت به دریافت یک متن آزاد مزیت مهمی دارد. Backend می‌تواند JSON را دریافت کند و هر قسمت را در دیتابیس ذخیره یا در داشبورد نمایش دهد.

اگر بخواهیم Meeting Assistant را به یک وب‌اپلیکیشن تبدیل کنیم چه می‌شود؟

در مرحله بعد می‌توان یک پنل وب روی VPS ساخت. کاربر فایل جلسه را Upload می‌کند، Backend یک Job ایجاد می‌کند و Worker پردازش را انجام می‌دهد.

معماری حرفه‌ای‌تر برای تعداد جلسه بالا

اگر تعداد کاربران افزایش پیدا کند، اجرای مستقیم پردازش در درخواست HTTP مناسب نیست. بهتر است API فقط Job را ثبت کند و پردازش واقعی به Worker سپرده شود.

در این معماری، اگر سه کاربر هم‌زمان فایل ارسال کنند، Backend مجبور نیست سه پردازش سنگین را داخل درخواست‌های HTTP اجرا کند. Jobها در صف قرار می‌گیرند و Workerها آنها را طبق منابع موجود پردازش می‌کنند.

مهم‌ترین گلوگاه‌های منابع در Meeting Assistant

چرا NVMe در این پروژه اهمیت دارد؟

در پروژه‌های Voice AI فقط قدرت پردازنده مهم نیست. فایل‌های صوتی، مدل‌های هوش مصنوعی، Transcriptها و فایل‌های موقت دائماً خوانده و نوشته می‌شوند. اگر تعداد پردازش‌ها زیاد شود، سرعت دیسک نیز می‌تواند روی تجربه کاربر اثر بگذارد.

به همین دلیل، برای یک Meeting Assistant واقعی، ترکیب CPU مناسب + RAM کافی + NVMe + در صورت نیاز GPU معمولاً اهمیت بیشتری از انتخاب یک CPU قدرتمند بدون توجه به سایر منابع دارد.

مشکل مهم: VPS خودش وارد جلسه Zoom یا Meet نمی‌شود

این نکته یکی از مهم‌ترین تفاوت‌های آموزش‌های تئوری با پیاده‌سازی واقعی است.

اگر فقط یک فایل MP3 یا MP4 در اختیار دارید، معماری بالا کاملاً قابل اجراست. اما اگر می‌خواهید سیستم به‌صورت خودکار وارد Google Meet، Zoom یا Microsoft Teams شود، یک لایه دیگر به نام Meeting Capture Bot نیاز دارید.

در این معماری، Bot جلسه را از طریق مرورگر یا API پلتفرم دریافت می‌کند، صوت را استخراج می‌کند و سپس فایل یا Stream را به Pipeline پردازش می‌فرستد.

برای همین است که پروژه‌های Self-Hosted جدیدتر، معماری‌هایی شامل Bot، Audio Capture، Whisper، Speaker Diarization و LLM را در کنار هم قرار می‌دهند.

رفع مشکل‌های رایج در اجرای AI Meeting Assistant

۱. تبدیل صوت خیلی کند است

مدل Whisper را کوچک‌تر کنید، از faster-whisper استفاده کنید، تعداد پردازش‌های هم‌زمان را کاهش دهید یا سراغ GPU بروید. همچنین ابتدا مشخص کنید CPU واقعاً 100 درصد درگیر است یا گلوگاه جای دیگری قرار دارد.

۲. RAM سرور تمام می‌شود

ممکن است چند مدل یا چند Worker هم‌زمان در حافظه قرار گرفته باشند. تعداد Jobهای هم‌زمان را کاهش دهید و مدل‌های سبک‌تر را امتحان کنید.

۳. مدل LLM پاسخ نمی‌دهد

ابتدا بررسی کنید سرویس Ollama در حال اجراست:

systemctl status ollama

سپس وضعیت API محلی را بررسی کنید:

curl http://127.0.0.1:11434/api/tags

۴. خروجی LLM وظایف جعلی تولید می‌کند

Prompt را محدود کنید و صریحاً بنویسید که مدل اجازه ساختن نام، تاریخ، مسئول یا تصمیمی که در Transcript وجود ندارد را ندارد. در محصول نهایی نیز بهتر است خروجی را Validate کنید.

۵. فایل‌های جلسه فضای دیسک را پر می‌کنند

برای فایل‌های قدیمی سیاست نگهداری تعریف کنید. مثلاً فایل خام صوتی پس از مدت مشخص حذف شود اما Transcript و گزارش ساختاریافته نگهداری شوند؛ البته این سیاست باید با نیاز سازمان هماهنگ باشد.

امن‌سازی Meeting Assistant قبل از استفاده واقعی

قرار است فایل صوتی جلسات روی سرور قرار بگیرد؛ بنابراین این پروژه را نباید مثل یک اسکریپت آزمایشی ساده روی اینترنت رها کرد.

آیا برای AI Meeting Assistant به GPU نیاز داریم؟

خیر، برای شروع الزاماً GPU لازم نیست. می‌توان Whisper و یک LLM کوچک‌تر را روی CPU اجرا کرد. اما با افزایش طول جلسات، اندازه مدل و تعداد کاربران، GPU می‌تواند زمان پردازش را کاهش دهد.

به‌خصوص اگر هدف شما پردازش سریع فایل‌های طولانی یا چند Job هم‌زمان باشد، سرور GPU می‌تواند معماری را از یک پروژه آزمایشی به یک سرویس قابل استفاده برای تیم تبدیل کند.

پیشنهاد داخلی مرتبط برای ادامه مسیر

چطور این پروژه را به یک محصول واقعی تبدیل کنیم؟

نسخه ساده‌ای که در این مقاله ساختیم فقط نقطه شروع است. برای تبدیل آن به یک سرویس واقعی می‌توان چند قابلیت مهم اضافه کرد.

جمع‌بندی؛ ساخت AI Meeting Assistant روی VPS چه مسیری دارد؟

سوالات متداول درباره ساخت AI Meeting Assistant روی VPS

📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور