دستیار معماری که با داده های شرکت صحبت می کند

سود:

• طراحی اجزا و جریان داده یک دستیار RAG سازمانی end-to-end
• ترکیب داده های چند منبع (ویکی، بلیط، PDF، پایگاه داده) در یک دستیار واحد
• تصمیمات معماری را برای مقیاس پذیری، حافظه پنهان و تأخیر اتخاذ کنید

در واحدهای قبلی قسمت ها را یکی یکی یاد گرفتیم: embedding، vector database، chunking، retrieval. حالا بیایید اینها را ترکیب کنیم و یک معماری سرتاسری از یک دستیار بسازیم که با داده های شرکت شما صحبت می کند. هدف این است که یک کارمند بپرسد "سیاست مرخصی ما چیست؟" سیستمی که در آن افراد می توانند سؤال بپرسند، پاسخ ها بر اساس اسناد داخلی واقعی، نقل قول ها و ترکیب منابع داده های متعدد است. این واحد کل معماری، جریان داده و تصمیمات سطح تولید را پردازش می کند.

اجزای انتها به انتها

یک دستیار RAG شرکتی از دو خط مجزا تشکیل شده است. خط نمایه سازی (آفلاین) داده ها را آماده می کند. خط پرس و جو (آنلاین) به سوال پاسخ می دهد.

اجزای خط نمایه سازی:

1. اتصال دهنده ها: رابط هایی که داده ها را از منابع - ویکی، سیستم بلیط، فروشگاه فایل، پایگاه داده، ایمیل می کشند.
2. عادی سازی: تبدیل فرمت های مختلف (PDF، HTML، DOCX) به متن تمیز. تمیز کردن هدر / پاورقی
3. قطعه بندی + فراداده: تکه تکه کردن و برچسب گذاری (منبع، تاریخ، منبع).
4. جاسازی + بارگذاری: نوشتن بردارها و ابرداده ها در پایگاه داده برداری.

پرس و جو اجزای خط لوله:

1. پیش پردازش پرس و جو: بازنویسی، تمرکززدایی.
2. بازیابی: جستجوی ترکیبی + فیلتر ابرداده + رتبه بندی مجدد.
3. ایجاد سریع: قرار دادن زمینه + سؤال + دستورالعمل در قالب.
4. Generation: پاسخ پایه (زمینه ای) از مدل + منابع.
5. پس پردازش: قالب‌بندی استناد، بررسی امنیتی، ثبت‌نام.

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

تجسم جریان داده

[INDEXING - آفلاین]منابع → عادی سازی → تکه + فراداده → جاسازی → DB برداری (ویکی، بلیط، PDF، DB)[QUERY - آنلاین]سؤال کاربر → پیش پردازش → بازیابی (ترکیبی+فیلتر+رتبه‌بندی مجدد) → درخواست (مدل → متن+ سؤالات)

ترکیب داده های چند منبعی

در شرکت های واقعی، پاسخ در یک جا متوقف نمی شود. "چگونه به مشتری بازپرداخت صادر کنیم؟" پاسخ این سوال را می توان هم در مقاله راهنما (رویه)، در تاریخچه بلیط (نمونه های واقعی) و هم در سیاست PDF (قوانین) یافت. دستیار باید همه آنها را در یک استخر جستجو کند.

نکته مهم: هنگام ترکیب منابع در یک ذخیره بردار واحد، هر خرده باید ابرداده «source_tour» را داشته باشد. بنابراین می توانید همه آنها را جستجو کنید و در صورت لزوم آنها را فیلتر کنید، مانند "فقط سیاست های رسمی را بیاورید". همچنین، منابع مختلف سطوح مختلفی از قابلیت اطمینان دارند: خط مشی رسمی > مقاله راهنما > یادداشت بلیط یک کارمند. می توانید این اولویت را در رتبه بندی مجدد یا درخواست مشخص کنید.

منبع

نوع محتوا

اعتماد

فرکانس به روز رسانی

سیاست PDF

قانون رسمی

بالا

ماهانه

مقاله راهنما

رویه

متوسط به بالا

هفتگی

تاریخچه بلیط

نمونه واقعی

متوسط

مستمر

ویکی

یادداشت ترکیبی / فعلی

متغیر

مستمر

مقیاس پذیری، کش و تأخیر

سه موضوع در تولید برجسته است. تأخیر: زمانی که کاربر بیش از 2 ثانیه منتظر بماند، تجربه بدتر می شود. راه حل: پاسخ را به صورت پخش نمایش دهید - همانطور که مدل می نویسد روی صفحه نمایش داده می شود. کش: برای سوالات متداول و زمینه های تکراری، کش هم سرعت را افزایش می دهد و هم هزینه را کاهش می دهد. مقیاس: با افزایش کاربر، لازم است بتوان فراخوانی را به صورت افقی مقیاس بندی کرد و مدل سازی کرد.

قانون سرانگشتی در مورد هزینه: گران ترین مرحله معمولاً تعداد توکن هایی است که به مدل بزرگتر می روند. بنابراین، کاهش بافت به 4 قسمت خوب با رتبه بندی مجدد، هم کیفیت و هم هزینه را بهبود می بخشد. یک طرح رایج استفاده از یک مدل کوچکتر/سریعتر برای طبقه بندی یا مسیریابی ساده و یک مدل قدرتمندتر برای پاسخ نهایی است (مانند claude-opus-4-8).

احتیاط: نمایه سازی را به صورت «یک بار انجامش بده، فراموشش کن» تنظیم نکنید. اسناد تغییر می کنند، حذف می شوند، اضافه می شوند. یک استراتژی نمایه سازی مجدد ایجاد کنید: اسناد تغییر یافته را شناسایی کنید و فقط آنها را دوباره پردازش کنید. شاخص بیات پاسخی را ایجاد می کند که به نظر می رسد فعلی اما اشتباه است.

معماری ضعیف / معماری قوی

ضعیف (تک فیلمنامه، همه چیز ترکیبی):

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

قدرتمند (لوله های تقسیم + ابرداده + حافظه پنهان + جریان):

نمایه سازی: دسته ای در شب اجرا می شود، اسناد تغییر یافته را تازه می کند. پرس و جو: خط سبک - پیش پردازش → بازیابی ترکیبی + فیلتر → رتبه بندی مجدد → اعلان → مدل (جریان) → نقل قول → گزارش. سوالات متداول و منبع ذخیره شده است.

سه کیف کوچک

مورد 1 - خط گیج، تاخیر سنگین. یک استارت‌آپ اسکریپتی نوشت که فایل‌های PDF را با هر سؤال دوباره پردازش می‌کند. هر پاسخ به طور متوسط ​​11 ثانیه طول کشید. هنگامی که خط نمایه سازی جدا شد و داده ها قبلاً به فروشگاه برداری منتقل شدند، زمان پرس و جو به 1.3 ثانیه کاهش یافت و با پخش جریانی، "اولین کلمه" در 400 میلی ثانیه ظاهر شد.

مورد 2 - منابع بسیار زیاد، اولویت اشتباه. یک دستیار پشتیبانی به سیاست PDF و یادداشت های بلیط قدیمی وزن یکسانی داد. این مدل گاهی اوقات رتبه نادرست یک کارمند را از دو سال پیش به عنوان قانون رسمی ارائه می دهد. هنگامی که ابرداده source_tour و دستورالعمل "در صورت بروز تضاد خط مشی رسمی را در نظر بگیرید" به دستور اضافه شد، خطاهای اولویت کاذب تا 89٪ کاهش یافت.

مورد 3 - شاخص کهنه. یک دستیار منابع انسانی با شاخصی کار می کرد که به مدت 3 ماه به روز نشده بود. سیاست مرخصی تغییر کرده است، اما دستیار می گفت روزگار قدیم. هنگامی که Refresh روزانه نصب شد، که فایل های تغییر یافته را شناسایی می کند، نرخ پاسخ فعلی از 70٪ به 99٪ افزایش یافت.

اشتباهات رایج

• ترکیب خطوط نمایه سازی و پرس و جو: پردازش سنگین در حالی انجام می شود که کاربر منتظر است. تاخیر منفجر می شود
• عدم قرار دادن نوع منبع در فراداده: بدون اولویت بندی و فیلتر. به نظر می رسد منبع نامعتبر رسمی باشد.
• عدم ایجاد استراتژی تجدید: شاخص کهنه می شود. پاسخ های اشتباهی که به نظر فعلی می رسند تولید می شوند.
• رد شدن از جریان: کاربر به یک صفحه خالی نگاه می کند. تاخیر درک شده زیاد می شود.
• استفاده از بزرگترین مدل در هر مرحله: هزینه به طور غیر ضروری افزایش می یابد. فرمان را به مدل کوچکتر بسپارید.

به طور خلاصه

• دستیار RAG شرکتی از دو خط جداگانه تشکیل شده است: نمایه سازی آفلاین و پرس و جو آنلاین. آنها را از نظر فیزیکی جدا کنید.
• نمایه سازی = رابط + عادی سازی + تکه / فراداده + جاسازی / آپلود. پرس و جو = پیش پردازش + بازیابی + اعلان + تولید + پس از فرآیند.
• داده‌های چند منبعی در یک مخزن واحد ترکیب می‌شوند، اما ابرداده‌های نوع منبع و اولویت اعتماد حفظ می‌شوند.
• پخش جریانی و حافظه پنهان برای تأخیر، مهار زمینه و انتخاب مدل برای هزینه بسیار مهم هستند.
• بدون نمایه سازی مجدد، شاخص کهنه می شود. تغییر اسناد را به طور منظم پردازش کنید.

وظیفه کاربردی

یک نمودار معماری از دستیار برای تیم خود ترسیم کنید. (1) حداقل سه منبع داده واقعی را شناسایی کنید و نیاز اتصال دهنده، فرکانس به روز رسانی و سطح اعتماد را برای هر کدام یادداشت کنید. (2) خطوط نمایه سازی و پرس و جو را به طور جداگانه با یک نمودار جعبه-پیکان رسم کنید. (3) "کجا تاخیر و هزینه را در این دستیار کاهش دهم؟" حداقل دو تصمیم مشخص برای سوال بنویسید. (4) استراتژی تازه سازی خود را در یک جمله توصیف کنید: کدام منبع و هر چند وقت یکبار مجددا ایندکس می شود؟

چک لیست

• [ ] می توانم خطوط نمایه سازی و پرس و جو را به طور جداگانه و با اجزای صحیح ترسیم کنم.
• [ ] می توانم داده های چند منبع را با source_type و اولویت اعتماد ترکیب کنم.
• [ ] می‌توانم برای زمان تأخیر و انتخاب مدل برای هزینه تصمیم‌گیری در جریان/حافظه پنهان بگیرم.
• [ ] من می دانم که چرا یک استراتژی نمایه سازی مجدد ضروری است.
• [ ] من به خاطر دارم که گران ترین مرحله در معماری من معمولاً نشانه ای است که به مدل بزرگتر می رود.