بعد از این فصل میتوانید…
- RAG را از فاینتیون و آموزش اولیه جدا میکنید.
- برای دانش متغیر سازمان راهکار مناسب انتخاب میکنید.
- پرسشهای پذیرش یک دستیار دانش را طراحی میکنید.
سه نیاز متفاوت، سه راهحل متفاوت
گاهی مدل اطلاعات پرونده را ندارد؛ گاهی قالب و رفتار موردنظر را خوب رعایت نمیکند؛ گاهی خود مسئله به توانایی پایهٔ متفاوتی نیاز دارد. این سه نیاز را با عبارت کلی «مدل را آموزش بدهیم» یکی نکنید. برای دانستن آییننامهٔ تازه، ابتدا باید سند معتبر و قابلدسترسی داشته باشید. برای خروجی یکشکل، ابتدا پرامپت و نمونه را امتحان کنید.
آموزش اولیه، ساخت توانایی عمومی مدل از دادههای گسترده است. فاینتیون، تنظیم بیشتر پارامترهای یک مدل با نمونههای آموزشی برای رفتار یا وظیفهٔ مشخص است. RAG، هنگام پاسخ بخشهای مرتبط دانش را پیدا و به مدل ارائه میکند. یک سامانه میتواند ترکیبی از این روشها باشد؛ انتخاب باید به مسئله و شاهد ارزیابی وصل باشد.
| روش | چه چیزی تغییر میکند؟ | کاربرد آغازین |
|---|---|---|
| پرامپت و نمونه | دستور و زمینهٔ همین کار | قالب، لحن و فرایند ساده |
| فایل در گفتگو | اطلاعات در دسترس همان گفتگو/محیط | تحلیل موردی سند محدود |
| RAG | بازیابی اطلاعات مرتبط هنگام پاسخ | دانش سازمانی نسخهدار و قابلارجاع |
| فاینتیون | پارامترهای مدل با نمونههای آموزشی | رفتار یا وظیفهٔ پایدار پس از ارزیابی |
| آموزش اولیه | توانایی پایه با فرایند گسترده | پروژهٔ تخصصی با منابع و توجیه مستقل |
RAG را مانند کتابخانهٔ دارای فهرست ببینید
در یک طراحی رایج، اسناد دریافت و آماده میشوند، بخشبندی و فهرستگذاری میشوند، سؤال کاربر به جستوجو تبدیل میشود، بخشهای مرتبط بازیابی و سپس پاسخ با اتکا به آنها تولید میشود. مقالهٔ اولیهٔ RAG ترکیب حافظهٔ پارامتری و بازیابی بیرونی را بررسی کرد؛ سامانههای عملی امروز جزئیات متنوعی دارند.
اگر بخش درست بازیابی نشود، مدل ممکن است با زمینهٔ ناقص پاسخ بدهد. اگر سند اشتباه یا قدیمی باشد، ارجاع هم پاسخ را نجات نمیدهد. بنابراین کیفیت RAG فقط کیفیت مدل نیست: آمادهسازی سند، جستوجو، رتبهبندی، مجوز و شیوهٔ امتناع از پاسخ هم مهماند. نمودار سادهٔ «فایل → مدل → پاسخ» این کنترلها را پنهان میکند.
برای میز تصمیم: RAG راهی برای رساندن شاهد مرتبط به مدل است؛ تضمین حذف هذیانگویی نیست.
بردارسازی و جستوجوی معنایی بدون ریاضی پیچیده
Embedding یا بردارسازی، نمایش عددیای از متن یا داده میسازد که برای یافتن شباهت به کار میآید. جستوجوی معنایی میتواند عبارتی مانند «مرخصی بعد از تولد فرزند» را به بند مرتبطی با واژهٔ متفاوت نزدیک کند. اما شباهت معنایی برابر اعتبار، تازگی یا مجوز دسترسی نیست.
کد کالا، شمارهٔ قرارداد و شناسهٔ دقیق گاهی به جستوجوی واژگانی نیاز دارند. به همین دلیل ممکن است ترکیب جستوجوی دقیق و معنایی مناسب باشد. اندازهٔ بخشهای سند نیز مهم است: بخش بسیار کوتاه زمینه را از دست میدهد و بخش بسیار بلند اطلاعات نامرتبط میآورد. این تنظیمها باید با پرسشهای واقعی سازمان ارزیابی شوند.
مکث و تمرین
پنج سؤال از یک آییننامهٔ عمومی بنویسید: دو سؤال با واژهٔ دقیق، دو سؤال با بیان متفاوت و یک سؤال که اصلاً در سند پاسخ ندارد. رفتار مطلوب برای سؤال آخر را از قبل تعریف کنید.
دانش سازمانی یعنی نسخه و مجوز، نه پوشهٔ بزرگ فایل
برای هر سند، مالک، نسخه، تاریخ اثر، تاریخ بازبینی و سطح دسترسی ثبت کنید. نسخهٔ منسوخ باید از مسیر پاسخ خارج یا صریحاً با برچسب تاریخی ارائه شود. اگر دو سند تعارض دارند، سامانه باید تعارض را نشان دهد؛ نباید خودسرانه بند آسانتر را انتخاب کند. پاسخ دربارهٔ سیاست جاری به سند جاری نیاز دارد.
مجوز باید پیش از بازیابی و هنگام دسترسی اعمال شود، نه فقط در متن دستور. کاربری که حق دیدن پروندهٔ حقوقی ندارد نباید از طریق پاسخ یا ارجاع آن را کشف کند. حذف یک سند نیز باید در فهرست بازیابی و نسخههای وابسته پیگیری شود. گذاشتن فایل در پوشهای به نام «محرمانه» بهخودیخود کنترل دسترسی نیست.
- مالک و نسخهٔ معتبر برای هر سند تعیین کنید.
- دسترسی را با هویت واقعی کاربر کنترل کنید.
- سؤالهای خارج از دانش را در آزمون بگذارید.
- تعارض و منسوخبودن را قابلمشاهده کنید.
- حذف و بهروزرسانی را در فرایند عملیاتی بگنجانید.
فاینتیون چه زمانی موضوع جدی میشود؟
اگر پس از بهبود دستور و داده، یک وظیفهٔ پایدار هنوز کیفیت یا کارایی لازم را ندارد و نمونههای آموزشی مناسب دارید، فاینتیون میتواند نامزد بررسی باشد. نمونهها باید نمایندهٔ کار واقعی و از نظر کیفیت و مجوز مناسب باشند. یک مجموعهٔ ارزیابی جدا لازم است تا پیشرفت روی دادهٔ دیدهنشده سنجیده شود.
فاینتیون راه سادهای برای بهروزکردن روزانهٔ نرخ، موجودی یا آییننامه نیست. همچنین بارگذاری فایل در یک پروژه به معنای فاینتیون اختصاصی نیست. سیاست استفادهٔ سرویس از داده برای بهبود مدل، مسئلهای قراردادی و جدا از روش فنی پروژهٔ شماست. این دو موضوع را در جلسهٔ خرید با اصطلاح مبهم «آموزش» مخلوط نکنید.
برای نیاز زیر، پرامپت، فایل محدود، RAG و فاینتیون را مقایسه کن: [نیاز]. تازگی داده، نیاز به ارجاع، مجوز، نمونهٔ آموزشی، هزینهٔ نگهداری و معیار ارزیابی را بررسی کن. کمپیچیدگیترین گزینهٔ قابلآزمایش را پیشنهاد بده و روشن کن چه شاهدی تغییر راهکار را توجیه میکند.
آزمون پذیرش دستیار دانش سازمانی
مجموعهٔ آزمون فقط سؤالهای خوشساخت و آسان نباشد. سؤال مستقیم، مبهم، چندسندی، دارای تعارض، مربوط به نسخهٔ قدیمی، بدون پاسخ و خارج از مجوز را بگنجانید. برای هر سؤال پاسخ مرجع یا رفتار مطلوب بنویسید. سپس بازیابی درست، پشتیبانی پاسخ با منبع و رعایت مجوز را جدا امتیاز دهید.
نمونهٔ آزمایشی: از یک آییننامهٔ ساختگی بپرسید سقف خرید بدون تأیید چقدر است. سپس همان پرسش را با نسخهٔ قدیمی، نقش بدون دسترسی و سند حاوی دستور فریبنده امتحان کنید. سامانه باید نسخه و نقش را رعایت کند و متن سند نتواند اختیارش را تغییر دهد. پذیرش فقط با یک پاسخ زیبا دربارهٔ سؤال اول کامل نمیشود.
برای میز تصمیم: برای مدیر، مهمترین سؤال این است: پاسخ از کدام نسخه، با کدام مجوز و با چه شاهدی آمده است؟
دانش خود را بسنجید
پیش از رفتن به فصل بعد
چکلیست پایان فصل
پیشرفت و تیکها فقط در همین مرورگر ذخیره میشوند؛ تکمیل فصل بهمعنای گواهی مهارت نیست.