جستجو، بازیابی، و مرور سه کارند؛ یکی‌شان نکن
بخش زیادی از معماری ضعیف AI از این می‌آید که جستجو، بازیابی، و مرور را عوضی هم حساب می‌کنیم. هم‌پوشانی واقعی است. شغل یکی نیست. محصول وقتی تمیزتر می‌شود که این فرق را رعایت کنی.
جستجو پیدا کردن اطلاعات نامزد است. بازیابی کشیدن زمینه درست به داخل یک وظیفه است. مرور، گشتن در اطلاعات بیرونی در حال تغییر است به شکل تعاملی. وقتی این‌ها را له می‌کنی، پرامپت شلوغ می‌شود، ابزار سخت ارزیابی می‌شود، و رفتار محصول غیرقابل پیش‌بینی.
قبل از هیجان سه سؤال را جواب بده. چه چیزی آسان‌تر شد، چه چیزی امن‌تر شد، و چه چیزی همچنان سخت ماند. این قاب جلوی این را می‌گیرد که شتاب پلتفرم را با آمادگی محصول عوضی بگیری.
هر کدام چه قراردادی دارند
جستجو یک سؤال می‌گیرد و مجموعه‌ای از احتمال برمی‌گرداند. کاربر یا سیستم بعدی تصمیم می‌گیرد کدام احتمال به کار می‌آید. کیفیت این‌جا یعنی ربط و تنوع معقول، نه یک پاراگراف نهایی. اگر جعبه جستجو خودش جواب قطعی بسازد، داری دو محصول را در یک کنترل قاطی می‌کنی و هیچ‌کدام را نمی‌توانی جدا اندازه بگیری.
بازیابی برای یک وظیفه مشخص، تکه محدود از منبع مورد اعتماد می‌آورد. بودجه توکن، فیلتر دسترسی، و تازگی منبع این‌جا درجه‌اول‌اند. خروجی خوب بازیابی زمینه قابل استناد است، نه تور کامل اینترنت. اگر سیستم مجوز را در بازیابی رعایت نکند، مدل با زمینه دزدیده‌شده جواب «درست» می‌دهد.
مرور وقتی است که منبع از قبل در ایندکس تو نیست یا همین حالا عوض می‌شود و باید قدم‌به‌قدم دیده شود. صفحه جاری، وضعیت یک داشبورد، یا سندی که دیروز نبود. مرور کندتر، شکننده‌تر، و گران‌تر است. برای همین باید استثناء باشد نه پیش‌فرض هر سؤال.
وقتی این نقش‌ها جدا باشند، تأخیر را می‌شود بودجه‌بندی کرد. جستجو می‌تواند تعاملی بماند. بازیابی می‌تواند قبل از مدل تمام شود و شکستش صریح باشد. مرور می‌تواند به کار پس‌زمینه یا تأیید انسان برود. وقتی یکی باشند، همه سؤال‌ها هزینه کندترین حالت را می‌پردازند.
یک ابزار را جای بقیه قالب نزن
بردار، مرور وب نیست. فهرست نتیجه جستجو، جواب متکی به منبع نیست. خودکارسازی مرورگر، جایگزین منبع دانش گزینش‌شده نیست. هر میان‌بر ابهام تازه می‌آورد.
این میان‌برها در محصول این‌طور دیده می‌شوند. دستیار داخلی که برای سؤال درباره سیاست شرکت به وب می‌رود، چون ایندکس داخلی خالی یا بی‌فیلتر است. جستجویی که مستقیم به مدل وصل است و هر کلیک یک مقاله بلند می‌سازد، در حالی که کاربر دنبال لینک بود. مرورگری که برای هر تیکت پشتیبانی باز می‌شود، چون کسی بازیابی را از اسناد خود محصول جدا نکرده.
در کار روزانه، این جدایی روی بلیت، بودجه تأخیر، کش، و اینکه کدام endpoint تعاملی بماند اثر می‌گذارد. وقتی قابلیت پایدارتر شود، حرف محصول و مهندسی کمتر حدسی است. می‌شود درباره ترتیب عرضه، مسیر جایگزین، مشاهده‌پذیری، و پشتیبانی حرف زد به‌جای اینکه فقط بپرسی تجربه اصلی دوام می‌آورد یا نه.
در محصول زنده چطور جدا می‌کنم
برای یک گردش کار، نه برای کل پلتفرم، نقش را بنویس. اگر کاربر در اسناد خودتان دنبال صفحه می‌گردد، جستجو. اگر مدل باید بند مرتبط همان سند را در جواب بیاورد، بازیابی با سقف و با استناد. اگر جواب به وضعیت همین ساعت یک سایت ثالث بستگی دارد، مرور، با مهلت و با اجازه.
ابزار را جدا لاگ کن. هزینه و شکست «جستجو» را با هزینه «مرور» یکی نکن. اگر مرور در صدمورد به خاطر سؤال ساده‌ای روشن می‌شود که باید از بازیابی می‌آمد، معماری را عوض کن نه مدل را.
قابلیت تازه پلتفرم را اول صرف قابلیت اطمینان و وضوح کن، نه صرف جاه‌طلبی بیشتر. تیم‌هایی که این کار را می‌کنند سریع‌تر جمع می‌شوند. اگر گردش کار مبهم باشد یا کسی نتواند بگوید صدای گران کجاست و چرا، ابزار بهتر فقط راه سریع‌تری برای ادامه آشفتگی است.
اعتماد کاربر هم اغلب با تکه کسل‌کننده دور قابلیت ساخته می‌شود. حالت خطا، زمان پاسخ، تکرار، لاگ، قابل ممیزی بودن، و دست‌به‌دست شدن به کد معمولی اپ، به اندازه خود قابلیتی که تیتر شده مهم است.
این هفته یک گردش کار موجود را انتخاب کن که از این جدایی سود می‌برد. مرز وظیفه را تنگ کن. دور تأخیر و شکست و هزینه دید بگذار. فرضی را که عوض شده بنویس. این عادت معمولاً بیشتر از یک هفته آزمایش هیجان‌زده به بحث معماری کمک می‌کند.
وقتی این شغل‌ها را یکی ندانی، بقیه سیستم قابل استدلال‌تر می‌شود. این وضوح خودش ارزش دارد.
ارزیابی را هم جدا کن
اگر یک عدد «کیفیت دستیار» داشته باشی، نمی‌فهمی کدام شغل خراب است. برای جستجو بپرس آیا نامزد درست در چند نتیجه اول هست. برای بازیابی بپرس آیا تکه واردشده به مدل همان منبع مجاز و به‌اندازه کافی کوچک است. برای مرور بپرس آیا صفحه واقعاً باز شده و مهلت را رعایت کرده، نه اینکه مدل درباره آن صفحه قصه ساخته.
این سه معیار را در یک داشبورد قاطی نکن. شکست مرور اغلب نوسان شبکه است. شکست بازیابی اغلب فیلتر یا ایندکس است. شکست جستجو اغلب پرسش کاربر یا رتبه‌بندی است. درمان یکی، دیگری را درست نمی‌کند. وقتی جدا شدند، می‌توانی کش را فقط جلوی جستجوی تکراری بگذاری و مرور را از کش درازمدت دور نگه داری، چون تازگی دلیل وجودش است.
پرسش‌های کوتاه
محصول کوچک هم باید سه سرویس جدا داشته باشد؟ نه سه سرویس. سه قرارداد. حتی در یک پردازه، ورودی و خروجی و بودجه هر کدام را قاطی نکن.
RAG همه‌اش بازیابی نیست؟ بازیابی تکه‌اش هست. اگر قبلش جستجوی نامزد و بعدش تولید جواب را همان مرحله حساب کنی، دیگر نمی‌دانی شکست از ایندکس است یا از مدل.
مرور را برای تازگی جایگزین ایندکس کنم؟ فقط برای منبع واقعاً متغیر. برای دانش پایدار خودت، ایندکس با فیلتر دسترسی ارزان‌تر و قابل ممیزی‌تر است.