لایهٔ ورود داده؛ گلوگاه پنهانی که باعث شکست سیستم‌های RAG می‌شود

اگر هفته‌ها وقت خود را صرف تنظیم اندازه تکه‌ها (Chunk Size)، مدل‌های بردار معنایی (Embedding Models) و پارامترهای top-k کرده‌اید اما باز هم خروجی هوش مصنوعی شما به یک سقف کیفی سخت برخورد می‌کند، احتمالاً مشکل جای دیگری است. شکست شما احتمالاً در اسکریپتی رخ داده که یک‌بار اجرا شد و فراموش شد؛ لایهٔ ورود داده‌ای (Ingestion Layer) که هیچ مقدار مهندسی پرامپت نمی‌تواند آن را ترمیم کند.

تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اما اگر صفحات کتاب در اثر رطوبت به هم چسبیده یا کلماتش پاک شده باشند، دانش‌آموز هرچقدر هم باهوش باشد، جواب غلط می‌دهد. این موضوع در واقع ریشه‌ای عمیق‌تر از تنظیمات مدل دارد و می‌تواند به خطاهای بنیادین در مرحله بازیابی بازگردد که باعث می‌شود سیستم حتی با وجود مدل‌های قدرتمند، پاسخ اشتباه دهد. طبق یک راهنمای فنی منتشر شده در dev.to در ۸ سپتامبر ۲۰۲۶، فرآیند ورود داده یک گام ساده نیست، بلکه یک خط لوله پنج‌مرحله‌ای است. اگر هر یک از این مراحل شکست بخورد، اسناد تبدیل به «شکست‌های خاموش» می‌شوند؛ یعنی در ظاهر معتبر به نظر می‌رسند اما معنای آن‌ها به‌هم‌ریخته است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کیفیت خروجی همیشه تابع کیفیت ورودی است. در اینجا پنج مرحله حیاتی ورود داده آمده است:

• استخراج (Extraction): بیرون کشیدن داده‌های خام از دیسک‌ها، صفحات HTML از طریق پروتکل HTTP، پاسخ‌های صفحه‌بندی‌شده‌ی APIها که پشت محدودیت‌های نرخ درخواست (Rate Limits) هستند، یا استخراج ردیف‌ها از یک پایگاه داده با استفاده از Connection Pooling. این مرحله اغلب به دلیل محدودیت‌های زمانی (Timeout) شکست می‌خورد.
• تجزیه (Parsing): تبدیل داده‌های خام به متن ساختاریافته. در این مرحله، یک فایل PDF به بلوک‌های متنی همراه با متادیتای موقعیتی تبدیل می‌شود و HTML به متنی پاک و بدون تبلیغات تبدیل می‌گردد. اینجاست که PDFهای چندستونی اغلب به‌هم‌ریخته و ترتیب جملات جابه‌جا می‌شود. برای جلوگیری از این دست آسیب‌ها، راهکارهای جدیدی برای جلوگیری از قطع جملات و حفظ معنای تکه‌ها توسعه یافته‌اند تا از دست رفتن بافت معنایی در مرحله تجزیه جلوگیری شود.
• پاک‌سازی (Cleaning): نرمال‌سازی متن با اصلاح کدگذاری (Encoding)، کاهش فضاهای خالی اضافی و حذف هدرها، فوترها و متون تکراری (Boilerplate). این مرحله همچنین وظیفه حذف داده‌های تکراری (Deduplication) را دارد تا مثلاً یک FAQ که هم در ویکی، هم در مرکز کمک و هم در یک رشته ایمیل وجود دارد، به صورت سه نسخه مجزا ظاهر نشود.
• غنی‌سازی (Enrichment): افزودن متادیتای حیاتی مانند شناسه‌ی منبع، عناوین، برچسب‌های زمانی و نوع محتوا. بدون این مرحله، شما نمی‌توانید بازیابی را بر اساس تاریخ فیلتر کنید یا پاسخ‌ها را به یک منبع خاص نسبت دهید.
• خروجی (Output): ثبت سند نهایی به همراه منشأ (Provenance) و نسخه خط لوله‌ای که سند را پردازش کرده است.

به گزارش نویسنده این راهنما، خطرناک‌ترین بخش این فرآیند «شکست‌های خاموش» هستند. این باگ‌ها خطرناک‌اند چون هیچ خطایی (Error) صادر نمی‌کنند. برای مثال، یک تجزیه‌کننده ممکن است دو ستون جدول را با هم ادغام کند و اعداد را به ردیف‌های اشتباه نسبت دهد. یا یک صفحه اسکن‌شده ممکن است یک رشته خالی تولید کند که در سیستم به عنوان یک سند معتبر با عنوان ذخیره شود. همچنین یک لغزش در کدگذاری ممکن است علامت‌های نقل‌قول و خط تیره را به کاراکترهای نامفهوم (Mojibake) تبدیل کند که بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — هرگز آن‌ها را ندیده است.

از آنجا که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به‌طور پیش‌فرض با اعتمادبه‌نفس پاسخ می‌دهند، آن‌ها بر اساس این ورودی‌های تخریب‌شده، جوابی صیقل‌خورده و مقتدرانه می‌نویسند بدون اینکه هشدار دهند منبع خراب است. این پدیده نشان می‌دهد که حتی زمانی که بازیابی به درستی عمل می‌کند، نقص در معماری سیستم می‌تواند منجر به توهمات مدل شود.

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

• آستانه طول محتوا: شناسایی اسنادی که بیش از حد کوتاه هستند (به طوری که واقعی به نظر نرسند) یا آنقدر بلندند که احتمال ادغام دو سند با هم وجود داشته باشد.
• تشخیص زبان: این روش برای متونی با بیش از ۵۰ کلمه قابل اعتماد است و می‌تواند به عنوان یک فیلتر یا برچسب برای بازیابی عمل کند.
• اعتبارسنجی طرح‌واره (Schema): اجباری کردن وجود عنوان غیرخالی، منبع معتبر، برچسب زمانی و نوع محتوا برای هر سند.
• نسبت کاراکترهای الفبایی: متون عادی معمولاً ۷۰ تا ۸۵ درصد الفبایی هستند؛ هر عددی کمتر از این نشان‌دهنده شکست در استخراج است.

نگهداری از یک پایگاه دانش (Knowledge Base) نیازمند ورود داده‌های افزایشی است. سیستمی که فقط یک‌بار اجرا شود، دارایی‌ای است که به‌سرعت منقضی می‌شود، زیرا اسناد محصول با هر انتشار تغییر می‌کنند و سیاست‌ها هر سه ماه یک‌بار بازبینی می‌شوند. سیستم‌های کارآمد به سه قابلیت نیاز دارند:

• تشخیص تغییرات (Change Detection): استفاده از برچسب‌های زمانی تغییر (Modification Timestamps) برای سیستم‌های فایل، فیلترهای updated_at برای APIها، جریان‌های CDC برای پایگاه‌های داده یا هش‌های محتوایی (Content Hashes) برای خزنده‌ها (Crawlers).
• پردازش تفاضلی (Differential Processing): استفاده از یک رکورد وضعیت همگام‌سازی (Sync State) برای هر منبع جهت ردیابی آخرین زمان همگام‌سازی و شناسه‌ی اسنادی که مشاهده شده‌اند.
• پاک‌سازی (Cleanup): حذف اسنادی که در منبع اصلی پاک شده‌اند تا ایندکس همچنان با اطلاعاتی که دیگر درست نیستند، پاسخ ندهد.

برای کسانی که امروز در حال عیب‌یابی سیستم خود هستند، موثرترین گام، ممیزی دستی است. ۱۰ سند تصادفی را از ایندکس خود بیرون بکشید و آن‌ها را در کنار منبع اصلی مقایسه کنید. اگر متن ذخیره‌شده با منبع یکی نیست، تمام تنظیمات بازیابی شما بی‌معنی است.

این تغییر دیدگاه، بحث RAG را از «تنظیم مدل» به «مهندسی داده» منتقل می‌کند. لایه ورود داده خسته‌کننده است و بدون نظارت اجرا می‌شود، اما تعیین می‌کند که هوش مصنوعی شما بر اساس واقعیت پاسخ دهد یا بر اساس متونی تخریب‌شده دچار توهم (Hallucination) شود.

گام بعدی شما

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

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