دستیار هوش مصنوعی سازمانی؛ پاسخ از روی مدارک دفتر، همراه با منبع هر پاسخ

اگر توضیحات تبلیغاتی را کنار بگذاریم، هر دستیار سازمانی چهار جزء دارد:

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

چت‌بات بر اساس یک سناریوی ازپیش‌نوشته‌شده پاسخ می‌دهد. دستیار عمومی مانند ChatGPT بر اساس آنچه مدل در آموزش یاد گرفته پاسخ می‌دهد. دستیار سازمانی بر اساس مدارک شما پاسخ می‌دهد. عامل هوشمند یک گام جلوتر می‌رود و اقدام انجام می‌دهد: ایمیل می‌فرستد، درخواست ثبت می‌کند یا یک رکورد را تغییر می‌دهد.

بیشتر دفاتر بهتر است از گزینه‌ی سوم شروع کنند و مدتی در همان‌جا بمانند. ریسک دستیاری که فقط می‌خواند، با ریسک دستیاری که می‌نویسد یکسان نیست.

Microsoft 365 Copilot، ChatGPT Enterprise و محصولات مشابه از پیش امکان جست‌وجو در فایل‌های شرکت را دارند. اگر مدارک شما در سامانه‌ای نگهداری می‌شوند که این محصولات به آن متصل می‌شوند، کارکنان به انگلیسی می‌پرسند و همه‌ی کارکنان اجازه‌ی دیدن همه‌ی فایل‌ها را دارند، خرید اشتراک احتمالاً پاسخ مناسبی است و برای آن به ما یا شرکت مشابهی نیازی ندارید.

توسعه‌ی دستیار هوش مصنوعی اختصاصی زمانی ارزش هزینه‌ی خود را دارد که یکی از این شرایط برقرار باشد:

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

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

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

در یک دفتر معماری یا مهندسی، وظایفی که معمولاً این شرایط را دارند عبارت‌اند از:

• جست‌وجو در مشخصات فنی: کدام محصول، رده‌ی مقاومت یا رواداری در مشخصات تعیین شده است، همراه با شماره‌ی بند.
• استانداردهای دفتر: دستورالعمل ترسیم، قواعد نام‌گذاری، انتخاب تمپلیت‌ها و برنامه‌ی اجرای BIM.
• جست‌وجو در پروژه‌های پیشین: کدام پروژه‌ها سیستم، کارفرما یا جزئیات مشابهی داشته‌اند.
• سابقه‌ی RFIها و مکاتبات: چه چیزی پرسیده شد، چه پاسخی داده شد و در چه تاریخی.
• آشنایی کارکنان جدید: پرسش‌هایی که هر همکار تازه‌وارد در ماه نخست مطرح می‌کند.

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

روشی که تقریباً همه‌ی دستیارهای سازمانی بر آن استوارند، تولید متن با پشتیبانی بازیابی (RAG) نام دارد و از مقاله‌ای در سال ۲۰۲۰ به نویسندگی Patrick Lewis و همکارانش آمده است. نقطه‌ی شروع آن مقاله هنوز مسئله را به‌درستی توصیف می‌کند: توانایی مدل‌های زبانی در دسترسی دقیق به دانش محدود است و نشان‌دادن منبع پاسخ‌ها مسئله‌ای حل‌نشده بود.

در عمل، این روش چهار مرحله دارد:

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

بیشترین توجه معمولاً به مدل است، اما مرحله‌ای که پاسخ را تعیین می‌کند، بازیابی است. اگر بند درست بازیابی نشود، بهترین مدل موجود نیز پاسخی روان بر اساس بند نادرست می‌نویسد.

در نتیجه، پروژه‌ی اصلی خود مدارک است. مشخصات فنی‌ای که به‌صورت تصویر اسکن شده، سه پیش‌نویس از یک گزارش در یک پوشه یا استانداردی که سال گذشته جایگزین شده، همگی مستقیماً وارد پاسخ‌ها می‌شوند. آماده‌سازی داده برای هوش مصنوعی این کار را به‌طور کامل بررسی می‌کند و دستیار، نخستین جایی است که نادیده‌گرفتن آن آشکار می‌شود.

پروفایل هوش مصنوعی مولد NIST خطای اصلی این مدل‌ها را «confabulation» می‌نامد: تولید محتوایی که با اطمینان بیان می‌شود، اما نادرست است. این خطا را نمی‌توان به‌طور کامل از مدل حذف کرد، اما می‌توان سامانه را به‌گونه‌ای طراحی کرد که اثر آن محدود شود.

اگر از یک چت‌بات عمومی درباره‌ی جدول درهای پروژه‌ی دفتر خود بپرسید، باز هم پاسخ دریافت می‌کنید؛ پاسخی مرتب، روان و مربوط به دفتری دیگر.

سه قاعده دستیار سازمانی را قابل‌اعتماد نگه می‌دارد:

• ارجاع برای هر پاسخ: نام فایل، شماره‌ی ویرایش و بند، صفحه یا شیت، به‌صورت پیوندی که خواننده بتواند آن را باز کند.
• اعلام نبود پاسخ در منابع: «در مدارکی که به آن‌ها دسترسی دارید پیدا نشد» پاسخ درستی است و دستیار باید برای همین حالت نیز آزمون شود.
• ماندن در محدوده‌ی وظیفه: پرسش‌های خارج از منابع به مرجع مناسب ارجاع داده می‌شوند و دستیار برای آن‌ها پاسخی نمی‌سازد.

ارجاع، شیوه‌ی استفاده از دستیار را تغییر می‌دهد. پاسخی که منبع دارد با بازکردن یک فایل بررسی می‌شود. پاسخی که منبع ندارد یا بدون بررسی پذیرفته می‌شود یا کنار گذاشته می‌شود و هیچ‌کدام از این دو نتیجه مطلوب نیست.

بیشتر راهنماها زبان انگلیسی را فرض می‌گیرند. دفتری که به فارسی کار می‌کند، با مسائلی روبه‌رو می‌شود که در این راهنماها مطرح نمی‌شوند.

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

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

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

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

دو تصمیم دیگر نیز در همین مرحله گرفته می‌شود:

• محل پردازش داده: مدلی که از طریق API فراخوانی می‌شود، بخش‌های مدارک را همراه هر پرسش به ارائه‌دهنده می‌فرستد. مدلی که روی سرور خود شرکت اجرا می‌شود این کار را نمی‌کند، اما میزبانی آن هزینه‌ی بیشتری دارد. شرایط ارائه‌دهنده درباره‌ی داده‌ها را پیش از نمایه‌سازی اولین مدرک بخوانید.
• اقدام‌های مجاز: کار را با دستیاری شروع کنید که فقط می‌خواند. OWASP تزریق دستور (prompt injection) را نخستین ریسک برنامه‌های مبتنی بر مدل زبانی می‌داند، از جمله حالت غیرمستقیم آن، که در آن دستورهایی پنهان در یک فایل یا صفحه‌ی وب، رفتار مدل را تغییر می‌دهند. دستیاری که فقط می‌خواند و ارجاع می‌دهد، در برابر این ریسک آسیب بسیار کمتری از دستیاری می‌بیند که می‌تواند بفرستد، ویرایش کند یا حذف کند.

پرسش‌ها، پاسخ‌ها و بخش‌های استفاده‌شده را از روز نخست ثبت کنید. به این ترتیب، هر پاسخ نادرست تا فایلی که باعث آن شده قابل‌ردیابی است.

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

آزمون پس از راه‌اندازی نیز ادامه پیدا می‌کند. مدارک تغییر می‌کنند، استانداردها جایگزین می‌شوند و هر پروژه‌ی جدید پوشه‌هایی اضافه می‌کند که هنوز نمایه‌سازی نشده‌اند. هر بار که منابع تغییر می‌کنند، فهرست را دوباره اجرا کنید و هر پرسش واقعی‌ای را که دستیار به آن پاسخ نادرست داده، به فهرست اضافه کنید. به این ترتیب، فهرست به دقیق‌ترین توصیف از کارهایی تبدیل می‌شود که می‌توان به دستیار سپرد.

مراحل ساخت، همان ترتیبی را دارند که در بخش‌های پیشین آمد:

1. تعیین محدوده: یک وظیفه، یک تیم و فهرست پرسش‌ها همراه با پاسخ درست هرکدام.
2. فهرست منابع: کدام فایل‌ها به این پرسش‌ها پاسخ می‌دهند، مالک هرکدام کیست و کدام نسخه به‌روز است.
3. نمونه‌ی اولیه روی بخشی از مدارک: مدارک یک پروژه، به اندازه‌ای که مشخص شود بازیابی بخش‌های درست را پیدا می‌کند یا نه.
4. آزمون: اجرای فهرست پرسش‌ها، شامل پرسش‌هایی که باید رد شوند.
5. اجرای آزمایشی: یک تیم، پرسش‌های واقعی و ثبت تمام پرسش و پاسخ‌ها.
6. گسترش: افزودن منابع یا تیم دوم، فقط پس از آنکه تیم نخست به دستیار اعتماد کرده باشد.

هزینه به همان عواملی بستگی دارد که در هر نرم‌افزار اختصاصی دیگری مؤثرند: تعداد سامانه‌های منبع، وضعیت مدارک، جزئیات دسترسی‌ها و اینکه دستیار از طریق API یک ارائه‌دهنده اجرا می‌شود یا روی سخت‌افزار خود شرکت. نمونه‌ی اولیه روی بخشی از مدارک، کم‌هزینه‌ترین راه برای شناختن پرهزینه‌ترین بخش پروژه، پیش از قیمت‌گذاری ساخت کامل است. این رویکرد مرحله‌ای، همان رویکردی است که در تحقیق و توسعه‌ی آرتینکست به کار می‌رود.