تصور کنید یک دستور صوتی هوش مصنوعی با موفقیت تغییری را در رابط کاربری (UI) ایجاد میکند، اما در ابزارهای نظارتی شما هیچ ردی از آن نیست. این دقیقاً همان شکافی بود که تیم Sidechalk — یک دفترچه یادداشت مشترک برای یادگیرندگان STEM — در ۲۷ ژوئیه ۲۰۲۶ هنگام ادغام SigNoZ برای ایجاد قابلیت مشاهده (Observability) سراسری با آن مواجه شد، همانطور که در یک تحلیل فنی در وبسایت dev.to منتشر شده است.
در برنامههای مدرن هوش مصنوعی، فاصله میان یک تجربه کاربری موفق و یک ردپای نظارتی (Telemetry Trace) دقیق بسیار زیاد است. اکثر توسعهدهندگان تنها درخواستهای HTTP — یعنی نقاط اتصالی (Endpoint) که پاسخ را تحریک میکنند — را رصد میکنند. اما برای عاملهای چندوجهی (Multimodal) که از WebRTC و باندهای جانبی غیرهمزمان (Asynchronous Sidebands) استفاده میکنند، درخواست مدتها پیش از پایان استدلال و اجرای مدل بسته میشود. این وضعیت یک «نقطه کور» ایجاد میکند که در آن کاربر نتیجه را میبیند، اما توسعهدهنده با یک داشبورد خالی روبهرو است.
معماری یک بوم هوش مصنوعی امن
Sidechalk به عنوان محیطی مشارکتی طراحی شده است که در آن دانشجویان روی بوم Excalidraw نقاشی میکنند، در یک سند متن مینویسند، رسانهها را وارد میکنند و از طریق صوت یا متن با یک دستیار تعامل دارند. برای جلوگیری از اینکه هوش مصنوعی به صورت بیصدا کارهای کاربر را تخریب کند، سیستم یک اصل تغییرناپذیر به نام «ابتدا پیشنویس» (Draft First) را اجرا میکند. این رویکرد برای مدیریت تعاملات صوتی حیاتی است، چرا که طراحی رابطهای کاربری برای کنترل وقفهها در مدلهای زنده یکی از بزرگترین چالشهای تجربه کاربری در سیستمهای صوتی است. خروجی مدل نمیتواند مستقیماً سند Yjs را تغییر دهد؛ در عوض، مدل تغییراتی را پیشنهاد میدهد که یادگیرنده باید صریحاً آنها را بپذیرد، رد کند یا لغو (Undo) نماید. علامتهای هوش مصنوعی تا زمان پذیرش صریح، از نظر بصری متمایز میمانند و کارهای پذیرفته شده دارای یک معکوس قطعی برای عملیات Undo هستند.
به طور مشخص، دستیار میتواند چندین نوع عملیات سطحی را پیشنهاد دهد:
- اضافات بصری مانند فلشها، دستخط یا دایرهها.
- جابجایی عناصر موجود.
- تفاسیر سطح بالا و ارجاعات.
- جایگزینی اجزا یا حذفهای قابل بازیابی.
پشته فنی (Tech Stack) این پروژه یک monorepo تایپاسکریپتی است که از موارد زیر بهره میبرد:
- Next.js و Excalidraw برای تجربه وب در فرانتاند.
- Fastify برای APIهای معتبر.
- Supabase برای احراز هویت و وضعیت پایدار.
- Yjs/Hocuspocus برای همکاری در لحظه (Real-time).
- Redis و BullMQ برای کارهای توزیع شده در پسزمینه.
- یک تاییدکننده STEM محدود به زبان Python برای بررسیهای قطعی.
- OpenAI برای صوت زنده و پیشنهادهای چندوجهی، همراه با آداپتورهایی برای Google و Anthropic.
سناریوی دمو: فیزیک روی سطح شیبدار
برای آزمایش این سیستمها، سناریوی خاصی شامل یک نمودار جسم آزاد ناقص استفاده شد: بلوکی روی یک سطح شیبدار با نیروی گرانش (mg)، نیروی عمودی (N) و یک فلش سرعت رو به پایین شیب، اما بدون نیروی اصطکاک. این دمو تعامل را به سه نوبت متمایز تقسیم میکند تا قابلیتهای مختلف را بسنجد:
۱. «چه چیزی روی تخته میبینی؟ فعلاً چیزی را تغییر نده.» — این مرحله، زمینه بصری تازه و توانایی سیستم در دیدن بوم مجاز بدون اقدام را آزمایش میکند.
۲. «فلش سرعت نشان میدهد بلوک در حال حرکت به پایین شیب است. نیروی اصطکاک باید در کدام جهت عمل کند؟ هنوز چیزی نکش.» — این مرحله، حافظه گفتگو و استدلال فیزیکی را بدون اجازه برای عملیات سطحی تست میکند.
۳. «یک فلش زرد رنگ رو به بالای شیب اضافه کن و کلمه friction را کنار آن بنویس. چیز دیگری را تغییر نده و آن را به عنوان پیشنویس نگه دار.» — این مرحله در نهایت اجازه ارائه یک پیشنهاد پیشنویس را میدهد.
این تکلیف افزودنی خاص به دلیل یک محدودیت فنی انتخاب شد: تصاویر PNG وارد شده به عنوان یک عنصر تخت (Flattened) در بوم تلقی میشوند. درخواست از یک عامل برای حذف یک فلش که در یک تصویر استاتیک ادغام شده، با حذف یک عنصر برداری (Vector) در Excalidraw متفاوت است. با تمرکز بر افزودن یک عنصر برداری، تکلیف به یک عملیات صادقانه تبدیل میشود که قرارداد سطحی سیستم قادر به اجرای آن است.
حل نقطه کور تلهمتری صوتی
در آزمایشهای اولیه، مسیرهای متنی Sidechalk معیارهای سفارشی را به طور کامل ثبت میکردند، اما مسیر صوت زنده خالی میماند. توسعهدهنده دریافت کرد که چون مرورگر صدا را از طریق WebRTC ارسال میکند و سرور رویدادهای ارائهدهنده را از طریق یک باند جانبی مدیریت میکند، بازه (Span) استاندارد درخواست-پاسخ ناکافی است. در اجراهای اولیه، تلهمتری Workerها ظاهر میشد که ثابت میکرد SigNoZ در دسترس است، اما پنلهای هوش مصنوعی خالی بودند زیرا باند جانبی WebRTC چرخه حیات متفاوتی نسبت به مسیر متنی داشت. این تجربه مشابه رویکرد تیم Zooid در حذف نقاط کور پایش Voice AI بود که با استفاده از ردیابی دستی ژنراتورها موفق به ثبت دقیقتر مسیرها شد.
برای رفع این مشکل، Sidechalk از رصد نقاط اتصال به سمت رصد کل «چرخه حیات عامل» (Agent Lifecycle) تغییر مسیر داد. این کار شامل زنده نگه داشتن یک «بازه نوبت» (Turn Span) در چندین رویداد غیرهمزمان بود. هنگامی که یک جلسه صوتی آغاز میشود، یک بازه sidechalk.ai.turn باز میشود. این پیادهسازی شامل ویژگیهای (Attributes) خاصی است:
sidechalk.channel: مقدار "voice"sidechalk.ai.mode: حالت فعلی جلسهsidechalk.surface.type: نوع صفحهsidechalk.visual.available: آیا زمینه بصری در دسترس است یا خیر
در این چرخه حیات، برای هر پاسخ Realtime، یک بازه فرزند به نام sidechalk.gen_ai.invoke ایجاد میشود. این بازه فرزند نام عملیات ("realtime")، ارائهدهنده ("openai") و مدل خاص مورد استفاده را ردیابی میکند. هنگامی که response.done برسد، سیستم متادادای عددی مصرف (توکنهای ورودی و خروجی) را استخراج کرده، بازه ارائهدهنده را میبندد و یا از طریق یک فراخوانی ابزار (Tool Call) ادامه میدهد یا نوبت یادگیرنده را با فراخوانی recordAiTurn() به همراه مدتزمان کل و نتیجه میبندد. موارد لغو شده سخنرانی، خطاهای ارائهدهنده و شکستهای سوکت با بستن صریح بازهها مدیریت میشوند تا از نشت Tracههای ناتمام جلوگیری شود.
چارچوب نظارتی جدید
با افزودن بازههای دستی در هر مرز اعتماد، Sidechalk اکنون میتواند به سوالات عملیاتی دقیقی پاسخ دهد. با پیروی از راهنمای SigNoZ برای ردیابی عملیات تجاری که ابزارهای خودکار نمیتوانند توضیح دهند، سیستم از بازههای مرزی زیر استفاده میکند:
بازههای مرزی و منطق
- نوبت یادگیرنده (
sidechalk.ai.turn): آیا نوبت کامل متنی یا صوتی/پیشنهادی پایان یافت؟ - زمینه مجاز (
sidechalk.ai.context.build): آیا مدل سطح مجاز فعلی را دریافت کرد؟ - عملکرد ارائهدهنده (
sidechalk.gen_ai.invoke): کدام فراخوانی مدل کند بود، لغو شد یا شکست خورد؟ - تأییدیه (
sidechalk.verifier.check,sidechalk.citation.verify): آیا بررسیهای قطعی یا بررسی منابع اجرا شدند؟ - ایمنی پیشنویس (
sidechalk.proposal.validate,sidechalk.proposal.persist): آیا خروجی مدل معتبر بود و فقط به عنوان پیشنویس ذخیره شد؟ - کنترل انسانی (
sidechalk.proposal.decide,sidechalk.proposal.undo): پس از تصمیم صریح یادگیرنده چه اتفاقی افتاد؟ - همکاری (
sidechalk.realtime.authoritative_update): آیا بهروزرسانی باینری پذیرفته شده منتشر شد؟ - کارهای پسزمینه (
sidechalk.worker.job): آیا پردازش غیرهمزمان خارج از درخواست ادامه یافت؟
این رویکرد دانهبندی شده به تیم اجازه میدهد مدلهای خاصی مانند gpt-realtime-2.1 و gpt-5.6-terra را ردیابی کنند. مرکز فرماندهی SigNoZ اکنون سریهای توکن برای هر دو مدل، مدتزمان ارائهدهنده ساختاریافته، مدتزمان کامل نوبت عامل، هزینه تخمینی مدل بر اساس یک جدول قیمت ثبت شده و یک رویداد جایگزین (Fallback) را ثبت میکند.
داشبوردها و اعتماد
Sidechalk دو داشبورد را که به صورت Idempotent (تکرارپذیر) مستقر شدهاند و هر کدام دارای ۸ پنل هستند، برای نظارت بر این سیگنالها به کار گرفت. SDK نود (Node) ترایسها، معیارها و لاگهای مرتبط انتخاب شده را از طریق OTLP/HTTP و با استفاده از یک خواننده دورهای ۱۵ ثانیهای صادر میکند.
مرکز فرماندهی AI Sidechalk
- حجم: تعداد نوبتهای کامل AI از ابتدا تا انتها.
- تأخیر P95: تأخیر در پاسخدهی به یادگیرنده.
- مدتزمان ارائهدهنده: زمانی که صرف انتظار برای مدل شده است.
- جایگزینها (Fallbacks): دفعاتی که رویدادهای جایگزینی مدل رخ داده است.
- توکنها: تعداد کل توکنهای ورودی و خروجی.
- هزینه تخمینی: تأثیر مالی به ازای هر نوبت.
- فعالیت Worker: زمان انتظار در صف و سلامت کارهای پسزمینه.
- مدتزمان نوبت عامل: مدتزمان کامل مسیر عامل از ابتدا تا پایان.
اعتماد Sidechalk و ایمنی پیشنهادها
- عملیات پیشنهاد: نتایج اضافات، جایگزینیها یا حذفها.
- فعالیت تاییدکننده: موفقیت یا شکست بررسیهای تاییدکننده STEM پایتونی.
- فعالیت ارجاعات: عملکرد تأیید منابع.
- مسدودکنندههای تغییرناپذیر: دفعاتی که سیستم مانع از تغییر غیرپیشنویس شد (تخلفات ایمنی کانونیک).
- تحویل معتبر: موفقیت بهروزرسانیهای Yjs در سند.
- خطاها: شکستهای کلی در سطح سیستم.
فراتر از معیارهای استاندارد، سیستم از یک «آزمایشگاه خطا» (Fault Lab) برای تزریق عمدی تأخیرهای محدود ارائهدهنده، شکستها، تضادهای تاییدکننده یا تأخیرهای Worker استفاده میکند. این خطاها با برچسب sidechalk.demo.fault.* مشخص میشوند، در حافظه میمانند، به طور خودکار منقضی میشوند و استفاده از آنها در محیط عملیاتی (Production) اکیداً ممنوع است. تمام شواهد مصنوعی باید به وضوح به عنوان «مصنوعی» اعلام شوند.
معنای «عدم وجود داده» (No Data)
در طول توسعه، عبارت «No Data» در سه زمینه مختلف ظاهر شد که هر کدام نیاز به تشخیص متفاوتی داشتند:
۱. غیبت مورد انتظار: پنل مربوط به تخلفات تغییرناپذیر خالی بود زیرا هیچ تخلفی رخ نداده بود. این یک شواهد سالم است.
۲. کمبود ابزار رصد: در اجرای پیش از اصلاح، دادههای Worker میرسید اما مسیر صوتی AI خالی بود. این مسیر تا زمانی که چرخه حیات باند جانبی ابزارگذاری نشد، نامرئی بود.
۳. زیرساخت خراب: یک پرسوجوی P95 شکست خورد زیرا پیکربندی ClickHouse تابع histogramQuantile را به درستی بارگذاری نکرده بود. تابع اجرایی تولید شده به الگوی نام فایل اشتباهی اشاره میکرد و پارامتر کوانتیل UDF از نوع اشتباهی استفاده کرده بود.
این مورد سوم با اجرای دستور docker exec signoz-telemetrystore-clickhouse-0-0 clickhouse-client --query "select name from system.functions where name = 'histogramQuantile'" تأیید شد تا اطمینان حاصل شود که تابع پس از اصلاح به درستی بارگذاری شده است.
ابزارگذاری با اولویت حریم خصوصی
برای حفظ حریم خصوصی کاربران، Sidechalk یک لایه فیلترینگ سختگیرانه را قبل از صادر کردن تلهمتری پیاده میکند. سیستم از یک forbiddenKey مبتنی بر Regex استفاده میکند که رشتههایی مانند prompt, response, content, body, text, audio, transcript, document, authorization, cookie, secret, api_key, access_token, email و user_name را هدف قرار میدهد.
این تابع safeAttributes تضمین میکند که:
- کلیدهای ممنوعه کاملاً نادیده گرفته شوند.
- مقادیر رشتهای تا حداکثر ۲۴۰ کاراکتر برش بخورند.
- شناسههای حساس قبل از خروج، با استفاده از HMAC هش شوند.
بازههای خطای ثبت شده به صورت دستی، تنها یک کلاس خطا و یک پیام ثابت و بدون محتوا را نگه میدارند. این امر تضمین میکند که قابلیت مشاهده به قیمت نشت دادههای دانشجویان یا محتویات خصوصی دفترچههای یادداشت در ذخیرهگاه تلهمتری تمام نشود. دستخط واقعی کاربر، تصاویر صفحه و صدا هرگز به بازههای خاص هوش مصنوعی ضمیمه نمیشوند.
پشته محلی و تکرارپذیری
این محیط با استفاده از ویندوز ۱۱، Docker Desktop، WSL2، Node 24 و Foundry v0.2.14 ساخته شده است. پشته SigNoZ از casting.yaml با استفاده از foundryctl gauge و foundryctl cast تولید شد. به دلیل تداخل پورتها، رابط کاربری به ۱۸۰۸۰ و MCP به ۱۸۰۰۰ تغییر یافت، در حالی که OTLP/HTTP در ۴۳۱۸ باقی ماند. تاییدکننده Sidechalk از پورت ۸۰۰۲ استفاده میکند.
این تنظیمات از طریق اسکریپت pnpm signoz:verify تأیید میشود که نامهای داشبورد، نسخه Query Builder، شناسههای پنل، مسیریابی هشدارها و پرسوجوهای تلهمتری نماینده را بررسی میکند. یک شکست خاص زمانی رخ داد که sidechalk.ai.turn.duration.bucket برای چهار ساعت دیده نشده بود، که ثابت کرد اگرچه توزیع (Provisioning) وجود داشت، اما برای اثبات مسیر، ترافیک تازه مورد نیاز بود.
بررسی حوادث بدون دسترسی نوشتنی
Sidechalk شامل یک Incident Copilot است که توسط سرور رسمی MCP در SigNoZ پشتیبانی میشود. برای تضمین ایمنی، سرور با یک لیست مجاز (Allowlist) سختگیرانه پیکربندی شده است:
- فقط خواندنی: تنها عملیات خواندنی مجاز است؛ ابزارهای ایجاد، بهروزرسانی و حذف حذف شدهاند.
- محدودیت نرخ: بررسیها به چهار فراخوانی، ۱۵ ثانیه برای هر فراخوانی و در مجموع ۴۵ ثانیه محدود شده است.
- پنجره زمانی: دسترسی به حداکثر پنجره زمانی شش ساعته محدود است.
- شواهد: هر بررسی کارتهایی تولید میکند که ابزار SigNoZ، بازه زمانی، سرویس و لینکهای مستقیم را حفظ میکنند.
تحلیل تحریریه: تغییر به سمت قابلیت مشاهده چرخه حیات
برای جامعه گستردهتر مهندسی هوش مصنوعی، تجربه Sidechalk یک تغییر حیاتی در نحوه نظارت بر جریانهای کاری «عاملمحور» (Agentic) را برجسته میکند. مدل سنتی Request-Response وب در مواجهه با هوش مصنوعی Realtime از بین رفته است. اگر شما محرک (Trigger) را به جای چرخه حیات (Lifecycle) رصد کنید، در واقع در حال پرواز در تاریکی هستید.
علاوه بر این، تأکید بر داشبوردهای «اعتماد و ایمنی» نشان میدهد که برای کاربرد هوش مصنوعی در آموزش، حضور انسان در حلقه (Human-in-the-loop) تنها یک انتخاب در تجربه کاربری نیست، بلکه یک تغییرناپذیر سیستمی است که باید به اندازه تأخیر یا هزینه، با دقت رصد شود. توانایی اثبات این موضوع که یک مدل سند را بدون تایید تغییر نداده است، به اندازه اثبات این موضوع که مدل به درستی به سوال پاسخ داده است، اهمیت دارد.
اکنون که مسیر صوت زنده قابل مشاهده است، Sidechalk میتواند از موفقیتهای پراکنده به سمت قابلیت اطمینان دادهمحور حرکت کند و تضمین نماید که دستیار هوش مصنوعی همواره یک کمککننده باقی بماند و نه یک ویرایشگر غیرقابل کنترل.
گفتگو