شکاف فنی در مصاحبه‌های تنسنت؛ مدیران محصول در پیاده‌سازی RAG شکست می‌خورند

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

به نقل از یک پست ویروسی در جوامع مدیران محصول هوش مصنوعی چین در ۱۲ اوت ۲۰۲۶، شکاف عمیقی در نحوه ارزیابی استعدادها توسط شرکت‌های تنسنت (Tencent)، بایت‌دنس (ByteDance)، کیمی (Kimi) و دیپ‌سیک (DeepSeek) مشاهده می‌شود. طبق این گزارش، در حالی که اکثر کاندیداها مفهوم تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را می‌دانند، تعداد کمی از آن‌ها می‌توانند موازنه فنی لازم برای عرضه یک خط لوله عملیاتی را توضیح دهند. این معماری در واقع راهکاری بنیادین برای حذف توهمات مدل‌های زبانی از طریق جست‌وجوی برداری است که اکنون استانداردهای پیاده‌سازی آن در سطح صنعتی سخت‌گیرانه‌تر شده است.

برای اکثر متقاضیان، RAG صرفاً راهی برای انتقال دانش از وزن‌های مدل به یک پایگاه‌داده مجزا است. در این روش، به‌جای اینکه اطلاعات تخصصی یا به‌روز را از طریق تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — وارد مدل کنیم، یک پایگاه دانش در کنار مدل نگه می‌داریم و در لحظه استنتاج (Inference) — همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی نه دوره آموزش آشپز — تکه‌های مرتبط را بازیابی می‌کنیم. سپس مدل بر اساس آنچه بازیابی کرده است، استدلال می‌کند.

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، انعطاف‌پذیری در لایه داده‌ها کلید بقای سیستم‌های تجاری است. RAG به تیم‌ها اجازه می‌دهد بدون نیاز به آموزش‌های گران‌قیمت و تکراری، دانش سیستم را به‌روز کنند. از دیدگاه تجاری، این یعنی جابه‌جایی سطح تکرار از لایه مدل به لایه دانش؛ یعنی تیم‌های محصول، عملیات و فروش می‌توانند بدون هماهنگی با مهندسان ML برای اجرای یک دوره بازآموزی، آنچه سیستم می‌داند را تغییر دهند. این رویکرد شبیه به این است که به دانش‌آموزی اجازه دهید در امتحان از کتاب استفاده کند، به‌جای آنکه او را مجبور به حفظ کردن کل کتاب درسی کنید؛ این روش برای کسب‌وکار سریع‌تر و منعطف‌تر است، حلقه‌های بازخورد را تسریع می‌کند و وابستگی به زیرساخت‌های پیچیده یادگیری ماشین برای به‌روزرسانی‌های روتین را کاهش می‌دهد.

با این حال، طبق گزارش این جامعه تخصصی، مصاحبه‌کنندگان ارشد فراتر از مفاهیم پایه رفته و روی دو «مسئله سخت» تمرکز می‌کنند:

• دقت تکه‌بندی (Chunk Granularity): کاندیداها اغلب نادیده می‌گیرند که اسناد هنگام ذخیره در پایگاه‌داده برداری (Vector Database) چگونه تقسیم می‌شوند. تکه‌های خیلی بزرگ باعث نتایج غیردقیق می‌شوند؛ مثلاً وقتی فقط یک پاراگراف خاص مورد نیاز است، اما سیستم یک بخش کامل از سند را بازیابی می‌کند. در مقابل، تکه‌های خیلی کوچک، بستر متن را تکه‌تکه کرده و مدل را مجبور می‌کنند معنا را از قطعاتی بازسازی کند که با هم همخوانی ندارند. از آنجایی که هیچ تنظیم جهانی و صحیحی برای این اندازه وجود ندارد، تنظیم این مقدار بر اساس نوع سند و توزیع پرس‌وجوها (Query Distribution)، اکنون به عنوان یک سیگنال کلیدی از تجربه واقعی در دنیای عملی شناخته می‌شود. در واقع، تکیه صرف بر این متدها گاهی ناکافی است و بررسی دلایل شکست جست‌وجوی برداری خالص در داده‌های صنعتی نشان می‌دهد که رویکردهای ترکیبی (Hybrid) برای محیط‌های عملیاتی ضروری هستند.

• هزینه زمینه و تأخیر (Latency): هر فراخوانی RAG، متنی را به پرامپت اضافه می‌کند. این متن توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — مصرف می‌کند و توکن یعنی هزینه و زمان. در ابزارهای پشتیبانی مشتری یا دستیارهای بلادرنگ که سرعت حیاتی است، سربار بازیابی به‌علاوه یک پنجره متنی بزرگ می‌تواند بودجه زمانی پاسخ‌دهی را به‌طور کامل نابود کند. قضاوت یک مدیر محصول ارشد در اینجا مشخص می‌شود: او باید بداند چه زمانی پرداخت این هزینه ارزشمند است و چه زمانی یک معماری متفاوت، انتخاب بهتری است.

مدیران محصول ارشد اکنون باید «مرز» استفاده از RAG را تعریف کنند. توصیه می‌شود زمانی از RAG استفاده شود که سازمان داده‌های خصوصی دارد که نمی‌توان آن‌ها را در یک مدل عمومی جای داد و یا زمانی که قابلیت تأیید پاسخ‌ها (Verifiability) برای کسب‌وکار حیاتی است؛ زمینه‌هایی مانند انطباق (Compliance)، دقت در پشتیبانی و متون حقوقی همگی در این دسته قرار می‌گیرند.

در مقابل، زمانی باید از RAG پرهیز کرد که:
۱. کیفیت بازیابی به‌دلیل ساختار بد و نامنظم اسناد منبع، غیرقابل کنترل باشد.
۲. دانش به‌قدری پایدار و ثابت است که تنظیم دقیق (Fine-tuning) جایگزین بهتری باشد.
۳. محدودیت‌های تأخیر (Latency)، سربار بازیابی را غیرقابل تحمل کند.

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

این تغییرات نشان می‌دهد نقش مدیر محصول هوش مصنوعی در حال تکامل است. دو سال پیش، PM فقط باید مفهوم RAG را به‌طور مفهومی می‌دانست و جزئیات پیاده‌سازی را به مهندسان می‌سپرد. اکنون در غول‌های فناوری، PM باید مالک منطق پشت اندازه تکه‌ها و بودجه توکن‌ها باشد.

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

اگر امروز در حال ساخت خط لوله‌های RAG هستید، باید استراتژی تکه‌بندی و بودجه‌های تأخیر خود را بازبینی کنید، پیش از آنکه این موارد به گلوگاه‌های تولید تبدیل شوند.

گام بعدی شما

• استراتژی فعلی تکه‌بندی (Chunking) داده‌های خود را بازبینی کنید تا از عدم تکه‌تکه شدن معنا جلوگیری شود.
• بودجه تأخیر (Latency Budget) سیستم خود را اندازه‌گیری کنید تا متوجه شوید کجا RAG باعث کندی پاسخ‌دهی می‌شود.
• برای داده‌های پایدار و حجیم، امکان جایگزینی RAG با تنظیم دقیق (Fine-tuning) را بررسی کنید.

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