اگر در حال ساخت سیستمی هستید که در آن دو منبع معتبر درباره یک حقیقت واحد اختلاف‌نظر دارند، احتمالاً اسکیمای استاندارد پایگاه داده شما به‌سرعت می‌شکند. این دقیقاً همان چالشی بود که تیم SAGE (مدرسه آموزش ژئومانسی باستان) هنگام توسعه پلتفرم هوش مصنوعی خود برای ژئومانسی غربی و رمال هندی با آن مواجه شد. این تیم با جزئیات شرح دادند که چگونه از توهم «منبع واحد حقیقت» عبور کردند تا بتوانند اختلافات تاریخی را به‌طور شفاف مدل‌سازی کنند.
زمینه و بستر مشکل
اکثر سیستم‌های نرم‌افزاری بر این فرض استوارند که تنها یک منبع واحد برای حقیقت وجود دارد. برای مثال، یک کاربر تنها یک آدرس ایمیل دارد، یک محصول یک قیمت مشخص دارد و یک سفارش یک وضعیت (Status) واحد دارد. پایگاه‌های داده، APIها و لایه‌های اعتبارسنجی معمولاً بر اساس همین فرض طراحی می‌شوند.
اما اتفاق می‌افتد اگر دامنه کاری شما شامل چندین حقیقت معتبر و هم‌زمان باشد؟ در ژئومانسی، کل سیستم بر پایه شانزده شکل بنیادین بنا شده است. هر یک از این شکل‌ها حامل ویژگی‌های متنوعی هستند، از جمله:
- عنصر (Element)
- حاکم سیاره‌ای (Planary ruler)
- تداعیات زودیاکی (Zodiac association)
- معانی تفسیری (Interpretive meanings)
- جایگاه‌ها و شرایط (Dignities and conditions)
تضاد سلسله‌مراتب (Lineages)
سنت‌های تاریخی مختلف همیشه با یکدیگر موافق نیستند. یک شکل ممکن است در یک سلسله‌مراتب غربی دارای مجموعه‌ای از تناظرات باشد، اما در یک سلسله‌مراتب رمال هندو-پرسی، مجموعه‌ای متفاوت داشته باشد. از منظر تاریخی، این موضوع کاملاً طبیعی است، اما از منظر نرم‌افزاری، یک مشکل طراحی فوری ایجاد می‌کند.
یک اسکیمای ساده‌انگارانه ممکن است به این شکل باشد:CREATE TABLE figures ( id VARCHAR PRIMARY KEY, name VARCHAR, element VARCHAR, planet VARCHAR, zodiac VARCHAR );
این ساختار تا زمانی که همه موافق باشند درست به نظر می‌رسد، اما به محض اینکه دو سنت معتبر، مقادیر متفاوتی را به یک شکل اختصاص دهند، پایگاه داده مجبور می‌شود به سوالی پاسخ دهد که مورخان قرن‌ها درباره آن بحث کرده‌اند: کدام نسخه درست است؟
شکست رویکرد «یک حقیقت»
بسیاری از سیستم‌ها این مشکل را با انتخاب یک مرجع حل می‌کنند: یک شکل $
ightarrow$ یک تفسیر $
ightarrow$ یک حقیقت. این روش پیاده‌سازی را ساده می‌کند، اما وفاداری تاریخی را نابود می‌سازد. به محض اینکه یک تفسیر به‌صورت سخت‌افزاری (Hardcode) ثبت شود، هر سلسله‌مراتب دیگری از نظر نرم‌افزار «غلط» تلقی می‌شود. این رویکرد برای پلتفرم SAGE غیرقابل قبول بود.
تغییر رویکرد: حقیقت به مثابه بافتار
دستاورد اصلی زمانی رخ داد که تیم SAGE متوقف کرد که تفاسیر را به عنوان «واقعیت» ببیند و در عوض، با آن‌ها به عنوان «بافتار» (Context) برخورد کرد. در این مدل، هویت یک شکل ثابت می‌ماند، اما ویژگی‌های آن وابسته به سلسله‌مراتب (Lineage) می‌شود.
برای مثال، شکل «puer» دارای یک امضای باینری «1101» است. در سلسله‌مراتب agrippa_western عنصر آن «آتش» و سیاره‌اش «مریخ» است. اما در سلسله‌مراتب ramal_traditional عنصر آن «باد» و سیاره‌اش «مریخ» است.
حالا سیستم به‌جای اینکه بپرسد «عنصر Puer چیست؟»، می‌پرسد «عنصر Puer در این سلسله‌مراتب خاص چیست؟»
جزئیات پیاده‌سازی فنی
پیاده‌سازی فنی این رویکرد بر سه مکانیزم اصلی برای مدیریت این پیچیدگی تکیه دارد:
- الگوی رجیستری (Registry Pattern): کپی کردن کامل مجموعه‌داده‌ها برای هر سنت، غیرقابل مدیریت بود. از آنجایی که اکثر سلسله‌مراتب‌ها روی اکثریت ویژگی‌ها توافق دارند، SAGE یک الگوی رجیستری لایه‌ای را پیاده کرد. ترتیب تفکیک (Resolution order) به این صورت است: جایگزینی‌های خاصِ سلسله‌مراتب $
ightarrow$ خط پایه سنت $
ightarrow$ رجیستری پیش‌فرض. - مدل‌سازی داده‌های بافتاری: ویژگی‌ها به‌جای ستون‌های استاتیک در جدول، به صورت اشیاء وابسته به بافتار ذخیره می‌شوند. این کار اجازه می‌دهد مجموعه‌داده‌ها کوچک‌تر باشند، نگهداری آسان‌تر شود و سنت‌های جدید سریع‌تر به سیستم اضافه شوند.
- اسنپ‌شات‌های تحلیل‌شده (Resolved Snapshots): برای تضمین بازتولیدپذیری، هر خوانش (Reading) تولید شده، یک اسنپ‌شات تحلیل‌شده را ذخیره می‌کند. این شامل
reading_id(شناسه خوانش)،tradition(سنت مورد استفاده، مثلاً western_agrippa)،schema_version(نسخه اسکما، مثلاً v1.2.0) وresolved_attributes(ویژگی‌های نهایی شده) است.
چرا اسنپ‌شات‌ها اهمیت دارند؟
یک خوانش که امروز تولید شده است، باید برای همیشه قابل بازتولید باشد. اگر پژوهش‌های تاریخی باعث شود تعریف یک سلسله‌مراتب شش ماه بعد بازنگری شود، خوانش‌های قدیمی نباید تغییر کنند. ذخیره اسنپ‌شات‌ها قابلیت حسابرسی (Auditability)، ثبات تاریخی و عیب‌یابی آسان‌تر را فراهم می‌کند و هر خوانش را به یک موجودیت مستقل تبدیل می‌کند.
کاربردهای گسترده‌تر
این تغییر، فرض بنیادین نمایش دانش در هوش مصنوعی را تغییر می‌دهد. این الگو مستقیماً در سایر دامنه‌های پیچیده کاربرد دارد:
- سیستم‌های حقوقی: حوزه‌های قضایی مختلف، مقررات را متفاوت تفسیر می‌کنند.
- پزشکی: دستورالعمل‌های بالینی در طول زمان تغییر می‌کنند.
- امور مالی: استانداردهای حسابداری در کشورهای مختلف متفاوت است.
- مالیات: قوانین بر اساس منطقه و نسخه تغییر می‌کنند.
- آرشیوهای تاریخی: منابع اغلب با یکدیگر در تضاد هستند.
با تبدیل حقیقت به بافتار، SAGE سیستمی ساخت که مقیاس‌پذیرتر از هر تلاشی برای تعیین «درست بودن» یک مرجع تاریخی است. نتیجه، پایگاه داده‌ای است که بدون قربانی کردن ظرافت‌های متون منبع، قابلیت حسابرسی و ثبات را حفظ می‌کند.
اگر پروژه فعلی شما شامل مراجع رقیب، استانداردهای در حال تکامل یا حوزه‌های قضایی متعدد است، احتمالاً مشکل شما «داده» نیست، بلکه مشکل «بافتار» است. مدل‌سازی بافتار اغلب بسیار آسان‌تر از مدل‌سازی حقیقت است.
گفتگو