ابزار Palimpsest با دقت ۹۴٪ متن ویدیوهای اسکرول‌شونده را استخراج می‌کند

تصور کنید ساعت‌ها ویدیو از یک سخنرانی یا جزوه‌ی PDF دارید که فایل اصلی‌اش گم شده و حالا باید تمام متن آن را برای مطالعه استخراج کنید. اگر از ابزارهای معمولی نویسه‌خوانی نوری استفاده کنید، با کوهی از متن‌های تکراری و کلمات تار مواجه می‌شوید که عملاً غیرقابل استفاده‌اند.

دقیقاً در همین نقطه است که Palimpsest وارد می‌شود؛ یک ابزار خط فرمان (CLI) با کارایی بالا که طبق اعلام توسعه‌دهنده‌اش، به دقت ۹۴.۵۶٪ در استخراج متن از ویدیوهای اسکرول‌شونده دست یافته است. این پروژه با ترکیب طراحی معماری انسانی و کدنویسی توسط هوش مصنوعی، یکی از سخت‌ترین نقاط درد در استخراج داده را هدف قرار داده است. نام این ابزار از اصطلاحی تاریخی برای نسخه‌های خطی گرفته شده که متن قدیمی‌شان پاک شده تا متن جدیدی روی آن نوشته شود؛ استعاره‌ای از نحوه پردازش ویدیوهای اسکرول توسط این نرم‌افزار.

بسیاری از دانشجویان و متخصصان با مشکل «اسناد قفل‌شده» روبرو هستند؛ یعنی ویدیوهایی از یک PDF یا یک سخنرانی که فایل منبع آن‌ها در دسترس نیست. این وضعیت در سناریوهایی رایج است که شخصی به جای ارسال فایل PDF، ویدیویی از آن را به اشتراک می‌گذارد، یا در ضبط‌های ویدئویی از یادداشت‌های تحصیلی و ویدیوهای آموزشی که کدها و مستندات را نمایش می‌دهند. این ابزار به‌ویژه برای کسانی که با ضبط‌های قدیمی سر و کار دارند و فایل منبع آن‌ها برای همیشه گم شده است، یا برای بررسی‌های گام‌به‌گام اسناد قفل‌شده، بسیار مفید است. ابزارهای استاندارد OCR در اینجا شکست می‌خورند زیرا هر فریم را پردازش می‌کنند که منجر به تکرار عظیم محتوا و خطاهای ناشی از تاری حرکت (Motion-blur) می‌شود. سرویس‌های ابری OCR ویدیو، مانند ScreenApp، اغلب با الزام به آپلود داده‌ها در سرورهای خارجی، ریسک‌های حریم خصوصی ایجاد کرده و هزینه‌های اشتراک ماهانه یا محدودیت‌های طول ویدیو را تحمیل می‌کنند. این موضوع باعث ایجاد یک خلاء برای یک راهکار محلی و آفلاین شد که بتواند به‌طور خاص مشکل اسناد اسکرول‌شونده را از طریق حذف تکرارهای محتوایی در فریم‌های هم‌پوشان و اتصال آن‌ها به یک سند خطی تمیز حل کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، پردازش محلی داده‌ها همواره اولویت متخصصان است. این رویکرد پردازش در سمت کاربر، مشابه راهکاری است که TextDigest AI برای انتقال پردازش متون به داخل مرورگر به کار گرفت تا حریم خصوصی کاربران را ارتقا دهد.

Palimpsest بر پایه یک خط لوله (Pipeline) هشت‌مرحله‌ای و بدون قفل (Lock-free) ساخته شده است. این ابزار از بافرهای حلقوی SPSC (تولیدکننده واحد، مصرف‌کننده واحد) بین هر مرحله استفاده می‌کند تا اطمینان حاصل شود که مصرف حافظه، فارغ از طول ویدیو، محدود باقی می‌ماند. به این معنا که یک ویدیوی سه ساعته همان مقدار رم را اشغال می‌کند که یک کلیپ پنج دقیقه‌ای؛ زیرا فشار معکوس (Backpressure) به‌طور خودکار به مراحل بالادستی منتقل می‌شود. اگر کارگران OCR کند شوند، صف کاری پر شده و متعاقباً پیش‌پردازشگر، فیلتر فریم و در نهایت رمزگشا (Decoder) متوقف می‌شوند.

جریان پردازش در این ابزار به شرح زیر است:

• رشته رمزگشا (Decoder Thread) $ \rightarrow $ بافر حلقوی SPSC<RawFrame, 128>
• فیلتر فریم و دروازه‌بان توقف (Frame Filter & Dwell Gatekeeper) $ \rightarrow $ بافر حلقوی SPSC<FilteredFrame, 64>
• رشته پیش‌پردازش (Preprocessor Thread) $ \rightarrow $ صف کاری
• مجموعه کارگران OCR (N رشته) $ \rightarrow $ صف نتایج (بدون ترتیب)
• بافر بازچیدمان (Reorder Buffer) $ \rightarrow $ جریان مرتب‌شده
• رشته حذف تکرار و اتصال (Dedup & Stitch Thread) $ \rightarrow $ بازیابی ساختار
• نویسنده خروجی (Output Writer) $ \rightarrow $ فایل TXT یا DOCX

نوآوری اصلی این ابزار در مکانیزمی به نام «دروازه توقف» (Dwell Gating) نهفته است. ابزارهای ساده معمولاً فریم‌ها را هنگام اسکرول فعال ضبط می‌کنند که بدترین کیفیت را دارند؛ زیرا در این لحظات، فریم‌ها دچار تاری حرکت شده و توسط کدک‌های H.264/H.265 به‌شدت فشرده می‌شوند، چرا که این کدک‌ها بیت‌های کمتری را به محتوای متحرک اختصاص می‌دهند. این فریم‌های انتقالی اغلب نیمی از محتوای قدیمی و نیمی از محتوای جدید را به‌طور همزمان نشان می‌دهند که بدترین ورودی ممکن برای Tesseract LSTM است.

Palimpsest دقیقاً برعکس عمل می‌کند: یک فریم تنها زمانی به موتور OCR فرستاده می‌شود که برای مدتی مشخص ثابت مانده باشد. این مدت توسط فلگ --stable-dwell-ms تعریف می‌شود (که مقدار پیش‌فرض آن ۵۰۰۰ میلی‌ثانیه است). در زمان اسکرول، شمارنده پایداری صفر می‌شود و تنها در زمان توقف، مقدار آن افزایش می‌یابد. این امر تضمین می‌کند که تنها تیزترین و ایستا‌ترین فریم‌ها — که دارای کیفیت کامل H.264 هستند و دقیقاً همان چیزی را نشان می‌دهند که ارائه‌دهنده قصد داشت مخاطب بخواند — به مرحله OCR برسند. بر اساس مستندات پروژه، در یک تست روی ویدیویی با مدت ۵ دقیقه و ۵۰ ثانیه حاوی ۲۱,۰۰۰ فریم، این دروازه حجم کار را به تنها ۵ فریم بی‌نقص کاهش داد و منجر به دقت ۹۴.۵۶٪ در متون پیچیده و متراکم مقررات بانکی شد.

حتی با وجود فریم‌های ثابت، تداخل محتوا اجتناب‌ناپذیر است. برای مثال، ممکن است ارائه‌دهنده روی نیمه پایین بخش A و نیمه بالای بخش B توقف کند، سپس اسکرول کرده و دوباره روی کل بخش B توقف نماید. برای حل این مشکل، ابزار از کتابخانه rapidfuzz-cpp برای اتصال متون با استفاده از تطبیق تقریبی (Fuzzy Matching) استفاده می‌کند.

مکانیزم‌های اتصال (Stitching):

• پنجره هم‌پوشانی (Overlap Window): ابزار انتهای سند فعلی و ابتدای متن فریم جدید را بررسی می‌کند (مقدار پیش‌فرض --overlap-window برابر با ۳۰۰ کاراکتر است).
• نسبت جزئی (Partial Ratio): از تابع rapidfuzz::fuzz::partial_ratio برای یافتن مرز هم‌پوشانی استفاده می‌کند.
• آستانه‌گذاری (Thresholding): اگر امتیاز هم‌پوشانی از --overlap-threshold (پیش‌فرض ۷۵) بیشتر شود، مرز دقیق را یافته و تنها محتوای جدید را اضافه می‌کند.
• مدیریت شکاف‌ها (Gap Handling): اگر امتیاز خیلی پایین باشد (که نشان‌دهنده اسکرول سریع یا شکاف در محتوا است)، یک نشانگر [GAP IN CONTENT] درج کرده و کل فریم را اضافه می‌کند.
• حذف تکرار متقاطع (Cross-GAP Deduplication): یک تاریخچه غلتان از خطوط دیده‌شده، محتوا را شناسایی کرده و در صورتی که ارائه‌دهنده به بخش‌های قبلی بازگردد، از تکرار آن‌ها جلوگیری می‌کند.

در بررسی‌های سخت‌افزاری روی پردازنده AMD Ryzen AI 7 350 (۸ هسته، ۱۶ رشته) با پردازنده گرافیکی Radeon 860M iGPU (۸ واحد محاسباتی، ۸ گیگابایت حافظه مشترک) و ۱۶ گیگابایت رم DDR5 با سرعت ۵۶۰۰ MT/s روی توزیع Arch Linux، نتایج به شرح زیر بود. ویدیوی تست دارای رزولوشن ۱۹۲۰×۱۲۰۰، کدک H.264 با نرخ ۶ مگابیت بر ثانیه، ۶۰ فریم بر ثانیه و در مجموع ۲۱,۰۰۰ فریم بود.

عملکرد در حالت عادی (Dwell Mode):

• بک‌اند CPU: سرعت ۳۱۸ فریم بر ثانیه (تقریباً ۵.۳ برابر سریع‌تر از زمان واقعی)، پردازش ۵ فریم در ۱ دقیقه و ۶ ثانیه.
• بک‌اند OpenCL: سرعت ۳۲۳ فریم بر ثانیه (تقریباً ۵.۴ برابر سریع‌تر از زمان واقعی)، پردازش ۵ فریم در ۱ دقیقه و ۵ ثانیه.

در حالت Dwell، گلوگاه صرفاً رمزگشای ویدیو است. با این حال، در یک تست فشار (Stress Test) که در آن ۲۰,۰۰۰ فریم به‌اجبار از کل خط لوله عبور داده شدند، بک‌اند CPU (با ۱۲۰ فریم بر ثانیه و حدود ۸.۳ میلی‌ثانیه برای هر فریم) عملکرد بهتری نسبت به OpenCL (با ۱۰۷ فریم بر ثانیه و حدود ۹.۴ میلی‌ثانیه برای هر فریم) داشت. دلیل این امر آن است که گلوگاه اصلی Tesseract است (که روی CPU اجرا می‌شود) و سربار اعزام دستورات OpenCL در این مقیاس، بیشتر از صرفه‌جویی‌های حاصل از پیش‌پردازش است.

این ابزار با استفاده از متون واقعی مقررات بانکی، از جمله بخشنامه‌های RBI، نام کمیته‌ها و زبان‌های پیچیده حقوقی بنچ‌مارک شد و به دقت ۹۴.۵۶٪ دست یافت. خطاهای باقی‌مانده بسیار اندک و از نوع خطاهای رایج OCR بودند: یک خط به دلیل اسکرول سریع از دست رفت (که با تنظیم --min-interval-ms قابل اصلاح است)، یک کاراکتر شبح‌وار به دلیل آرتیفکت‌های فشرده‌سازی ایجاد شد (مثلاً تبدیل "discipline" به "disciplinec") و برخی خطاهای جزئی در تشخیص پیشوندهای لیست‌ها رخ داد. توسعه‌دهنده اشاره می‌کند که این موارد در یک بازبینی پنج دقیقه‌ای به‌راحتی قابل اصلاح هستند.

توسعه این پروژه یک مطالعه موردی جذاب در مهندسی به کمک هوش مصنوعی است. در حالی که معماری کلی، منطق دروازه توقف و متدولوژی بنچ‌مارک توسط انسان طراحی شده، تقریباً تمام پیاده‌سازی C++ توسط مدل Claude در یک مرحله و بر اساس یک پرامپت دقیق نوشته شده است. این بهره‌وری در یادگیری و پیاده‌سازی، یادآور قابلیت جدید کلود برای اتوماسیون آموزش مهارت‌هاست که زمان تحقیق و یادگیری را به‌شدت کاهش می‌دهد.

موارد تولید شده توسط هوش مصنوعی:

• قالب بافر حلقوی SPSC بدون قفل و پیاده‌سازی هر ۸ مرحله خط لوله.
• فایل CMakeLists.txt با استفاده از FetchContent برای تمامی وابستگی‌ها.
• پارسر HOCR برای استخراج جعبه‌های محصورکننده (Bounding Boxes) از خروجی Tesseract.
• منطق اتصال هم‌پوشانی rapidfuzz و نویسنده Office Open XML برای خروجی .docx.
• بک‌اند OpenCL با استفاده از cv::UMat و رابط خط فرمان (CLI).

این ابزار با C++17 نوشته شده و به چندین کتابخانه کلیدی از طریق CMake FetchContent متکی است، به این معنی که می‌توان آن را با یک دستور ساده ./compile.sh بدون نیاز به vcpkg یا مدیریت بسته‌های سیستم کامپایل کرد.

پشته وابستگی‌ها (Dependency Stack):

• OpenCV 4.11.0: مدیریت هسته، imgproc، imgcodecs و videoio. بک‌اند OpenCL از cv::UMat برای اعزام به iGPU استفاده می‌کند و در صورت عدم یافتن دستگاه، به CPU باز می‌گردد.
• Tesseract 5.3.4 و Leptonica 1.84.1: موتور اصلی OCR.
• rapidfuzz-cpp v3.0.4: کتابخانه Header-only برای تطبیق تقریبی.
• miniz 3.0.2: برای نوشتن فایل‌های زیپ DOCX.
• {fmt} 10.2.1 و CLI11 v2.4.1: برای فرمت‌بندی و تجزیه آرگومان‌های خط فرمان.

کاربران می‌توانند ابزار را به‌سادگی با دستور ./build/bin/palimpsest recording.mkv اجرا کنند. فلگ‌های پیشرفته امکان کنترل دقیق را فراهم می‌کنند:

• --crop x,y,w,h: حذف بخش‌های رابط کاربری، نوار وظیفه و ریبون‌های پنجره.
• --ignore: حذف واترمارک‌ها و متون تکراری ثابت از طریق یک فایل متنی.
• --dump-images: خروجی گرفتن از فریم‌های دقیق ارسالی به OCR برای عیب‌یابی.
• --bench-preprocess N: حالت تست فشار برای عبور اجباری N فریم از خط لوله.
• -b opencl: انتخاب صریح بک‌اند OpenCL.
• -f docx: تنظیم فرمت خروجی روی سند Word.

برای خواننده، این به معنای ابزاری است که کاملاً به‌صورت محلی اجرا می‌شود، حریم خصوصی را حفظ می‌کند و ساعت‌ها ویدیو را در حدود یک دقیقه به متن قابل ویرایش تبدیل می‌کند. محدودیت‌های فعلی شامل نبود باینری‌های پیش‌ساخته و تمرکز اصلی بر لینوکس (Arch/Ubuntu 22.04+) است، هرچند پشتیبانی از ویندوز از طریق MSVC در برنامه است. این ابزار برای دانشجویان آزمون‌های بانکی، متقاضیان CA، دانشجویان حقوق، پزشکی یا مهندسی و همچنین پژوهشگران و متخصصان تطبیق (Compliance) ایده‌آل است.

این تغییر رویکرد به سمت توسعه «اول معماری، بعد کدنویسی با AI» نشان می‌دهد که گلوگاه در مهندسی نرم‌افزار از نحو (Syntax) و پیاده‌سازی به سمت تعریف دقیق مسئله و طراحی سیستم در حال حرکت است. وقتی معماری درست باشد، هوش مصنوعی می‌تواند C++ با کارایی بالا و آماده تولید را در یک مرحله تولید کند.

گام بعدی شما

• اگر روی لینوکس (Arch یا Ubuntu) هستید، مخزن این ابزار را کلون کرده و روی ویدیوهای آموزشی قدیمی خود تست کنید.
• برای افزایش دقت، از فلگ --crop استفاده کنید تا محیط رابط کاربری (UI) ویدیو باعث گمراه شدن OCR نشود.
• در صورت وجود پرش‌های زیاد در متن خروجی، مقدار --stable-dwell-ms را کاهش دهید تا فریم‌های بیشتری پردازش شوند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه تراشه‌های جدید AI در لبه (Edge) این سرعت‌ها را ممکن می‌کنند، به تحلیل ما درباره‌ی NPUها مراجعه کنید.