واقعیت درست بود، اما چه زمانی؟ معناشناسی زمان در سامانه‌های هوش مصنوعی

ساعت ۱۰:۰۴ عامل تدارکات می‌خواند تأمین‌کننده تأیید است و ۱۰:۰۷ سفارش را آزاد می‌کند. اصلاحیه ۱۰:۱۲ می‌گوید اعتبار نیمه‌شب تمام شده بود. در ممیزی کدام درست است: «تأیید بود»، «سامانه تأیید می‌دانست» یا «سفارش هنگام صدور معتبر بود»؟

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

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

حقیقت زمانی یک قرارداد عملیاتی است، نه قالب تاریخ

هر مهر زمانی فقط به پرسشی پاسخ می‌دهد که نام فیلد مشخص کرده است. مقدار «2026-08-13T06:34:00Z» می‌تواند زمان وقوع رویداد، زمان مشاهده گردآورنده، زمان ثبت ردیف یا زمان اجرای تصمیم باشد. وقتی پیام دیر می‌رسد، ساعت‌ها اختلاف دارند، واقعیت اصلاح می‌شود یا تصمیمی تاریخی را بازپخش می‌کنیم، هر یک از این معناها نتیجه متفاوتی می‌سازد.

RFC 3339 برای برنامه‌های اینترنتی قالب دقیقی از مهر زمانی، ناحیه زمانی و اعشار ثانیه تعریف می‌کند. این استاندارد برای نحو ضروری است، اما معنای کسب‌وکاری زمان را تعیین نمی‌کند. تبدیل همه زمان‌ها به UTC مقایسه را بهتر می‌کند؛ نمی‌گوید در آن لحظه چه اتفاقی افتاده است.

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

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

شش ساعت را در یک ستون ادغام نکنید

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

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

مدل داده لاگ OpenTelemetry فیلد Timestamp را زمان وقوع در مبدأ و ObservedTimestamp را زمان مشاهده تعریف می‌کند. اگر زمان اصلی نیست، زمان مشاهده را صادقانه نگه دارید؛ برچسب زمان رویداد روی آن نگذارید.

سامانه‌های تثبیت‌شده چه چیزی را تضمین می‌کنند؟

مدل داده منشأ W3C PROV موجودیت، فعالیت، عامل، تولید، استفاده و بی‌اعتبارشدن را جدا می‌کند. منشأ می‌گوید کدام نسخه پشت تصمیم بود؛ ثابت نمی‌کند آن نسخه جهان را درست توصیف کرده است.

راهنمای برنامه‌نویسی Apache Beam زمان رویداد را از پردازش جدا می‌کند. watermark کامل‌بودن ورودی را برآورد می‌کند و trigger و مهلت دیررسی میان تأخیر، کامل‌بودن و هزینه بده‌بستان می‌سازند. watermark پیشرفت است، نه اثبات نبود مدرک دیررس.

مستندات جداسازی تراکنش PostgreSQL می‌گوید Read Committed نمای ابتدای هر فرمان را می‌بیند، پس پرس‌وجوهای پیاپی می‌توانند متفاوت باشند. Repeatable Read نما را ثابت می‌کند و Serializable حفاظت بیشتری می‌دهد اما شاید اجرای دوباره لازم شود. این سطوح دیدپذیری نسخه‌های پایگاه داده را اداره می‌کنند، نه کامل‌بودن واقعیت بالادست را.

مستند گوگل درباره TrueTime و سازگاری بیرونی در Spanner ترتیب ثبت جهانی و خواندن نمای چندنسخه‌ای را شرح می‌دهد. این پاسخ «کدام وضعیت ثبت‌شده را خواندم؟» است، نه «تأمین‌کننده چه زمانی تأیید بود؟» مگر اینکه برنامه زمان دامنه را مدل کند.

این‌ها ویژگی‌های تأییدشده منابع‌اند. معماری ادامه، تحلیل ژرف برای ترکیب آن‌ها در سطح تصمیم است.

هر واقعیت پیامددار را در پاکت زمانی بگذارید

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

مگر اینکه دامنه قرارداد قوی‌تری داشته باشد، از بازه نیمه‌باز [valid_from, valid_to) استفاده کنید. این الگو نمی‌گذارد مرز مشترک دو نسخه دوبار شمرده شود. اگر تفسیر حقوقی یا عملیاتی به زمان محلی وابسته است، رشته و ناحیه زمانی اصلی را در کنار لحظه عادی‌شده نگه دارید.

دقت نامعلوم داده است، نه مجوز ساختن دقت. «از مرداد ۱۴۰۵» نباید بدون قاعده دامنه به نیمه‌شب اول ماه تبدیل شود. نبود valid_to می‌تواند پایان باز باشد، نه اعتبار ابدی. منبع بدون زمان دامنه باید همین محدودیت را حمل کند، نه اینکه recorded_at را قرض بگیرد.

اصلاح را دانش تازه ذخیره کنید، نه تاریخ بازنویسی‌شده

برای واقعیت تغییرپذیر، مدل دوزمانی روشن است: یک بازه اعتبار در دامنه مبدأ و دیگری زمان ثبت در سامانه را نشان می‌دهد. اولی می‌پرسد «چه چیزی درست بود؟» و دومی «آن زمان چه می‌دانستیم؟»

فرض کنید نسخه الف می‌گوید تأیید از ۱۰ مرداد به بعد معتبر بوده و در ۱۱ مرداد ثبت شده است. در ۲۲ مرداد نسخه ب می‌رسد و می‌گوید تأیید در ۲۱ مرداد پایان یافته است. نسخه الف را طوری ویرایش نکنید که انگار سامانه همیشه پایان اعتبار را می‌دانسته است. بازه ثبت الف را ببندید، ب را بیفزایید و آن را به‌عنوان اصلاحیه پیوند دهید. اکنون هر دو پرسش پاسخ دارد:

• بهترین نمای جاری: تأیید از ۱۰ تا پایان ۲۱ مرداد معتبر بود.
• نمای دانش تاریخی: ساعت ۱۰:۰۴ روز ۲۲ مرداد، سامانه تصمیم فقط نسخه الف را داشت.

این تفکیک مدرک ممیزی و اطمینان‌پذیری را ممکن می‌کند. ممیزی باید مدارک زمان تصمیم و اصلاحیه‌های بعدی را نشان دهد؛ پنهان کردن هر کدام گمراه‌کننده است.

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

نمای تصمیم را پیش از بازیابی نهایی تعریف کنید

نمای تصمیم، جهان محدود مدارکی است که تصمیم اجازه استفاده از آن‌ها را دارد. پیش از رتبه‌بندی نهایی یا ساخت پرامپت، یک شناسه تغییرناپذیر برای آن بسازید. حداقل این موارد را ثبت کنید:

1. هدف تصمیم، موضوع و نسخه سیاست؛
2. snapshot_at و سطح سازگاری خواندن یا ذخیره‌سازی؛
3. مرز زمانی منابع، watermark یا کران تازگی و ماندگی مجاز؛
4. شناسه دقیق نسخه واقعیت‌ها و چکیده اسناد پذیرفته‌شده؛
5. موارد حذف‌شده، تعارض‌ها، زمان‌های نامعلوم و مسیر جایگزین؛
6. نسخه مدل، بازیابی، ابزار و انتشار نرم‌افزار؛
7. زمان تصمیم پیشنهادی و رسید اقدام پایین‌دست.

نمای پایگاه داده فقط همان پایگاه را پوشش می‌دهد. اگر پرامپت PostgreSQL، نمایه جست‌وجو، API کش‌شده و مخزن برداری را ترکیب می‌کند، «خواندن تراکنشی» تضمین مشترک نیست. شناسه نسخه‌های تغییرناپذیر را مادی کنید، مرز مشترک بسازید یا پنجره ناسازگاری را اعلام کنید.

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

داده دیررس را یک رویداد سیاستی بدانید

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

برای هر دسته تصمیم، ماتریس اصلاح بنویسید:

مادی‌بودن باید مالک دامنه داشته باشد. تغییر کدپستی شاید برای اعتبار بی‌اهمیت و برای تحویل حیاتی باشد. مدل تفاوت را خلاصه می‌کند؛ سیاست می‌گوید بازنگری لازم است یا نه.

مثال عملی: سفارش خرید آزاد شود یا متوقف بماند؟

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

ساعت ۱۰:۰۰ هماهنگ‌کننده نمای S-184 را با مرز 09:59:59Z می‌سازد. نسخه ۱۷ تأیید پایان باز دارد، غربال ۲۴ ساعت معتبر است، بودجه ۴۲ کافی است و قرارداد ۸ کالا را پوشش می‌دهد. پرامپت خلاصه‌ها و همین شناسه‌ها را می‌گیرد؛ نه رکوردی را که دو دقیقه بعد بالاترین رتبه دارد.

ساعت ۱۰:۰۳ مدل آزادسازی را پیشنهاد می‌دهد. نگهبان قطعی صلاحیت و نسخه‌ها را می‌سنجد و چکیده پیشنهاد، S-184، نسخه سیاست و زمان تصمیم را ثبت می‌کند. ساعت ۱۰:۰۵ مقصد سفارش را می‌پذیرد و رسید می‌دهد.

ساعت ۱۰:۱۲ نسخه ۱۸ می‌گوید اعتبار از نیمه‌شب تمام شده و نسخه ۱۷ را اصلاح می‌کند. پایشگر آن را به تصمیم‌های مبتنی بر ۱۷ پیوند می‌دهد و سفارش را «نیازمند بازبینی» علامت می‌زند. S-184 را بازنویسی یا وجود نسخه ۱۸ در ساعت ۱۰:۰۰ را جعل نمی‌کند. سیاست تغییر مادی پس از اقدام برگشت‌پذیر را می‌بیند و پیشنهاد توقف یا لغو برای بازبین مجاز می‌سازد.

اکنون می‌دانیم منبع تأمین‌کننده را تأییدشده نمی‌داند؛ سامانه هنگام S-184 این را نمی‌دانست؛ و اقدام پذیرفته‌شده در مسیر اصلاح است. این از برچسب «خطای هوش مصنوعی» یا «تصمیم درست» دقیق‌تر است.

صلاحیت زمانی را بیرون از رتبه‌بندی معنایی نگه دارید

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

ترتیب مقاوم بازیابی چنین است:

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

راهنمای مشاهده‌پذیری کیفیت داده تازگی و تبار را به قرارداد قابل‌اندازه‌گیری می‌بندد. صلاحیت زمانی را نیز بیفزایید. «نمایه تازه است» کافی نیست اگر رکورد، رویداد قدیمی یا اصلاح تصمیم امروز را توصیف کند.

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

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

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

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

الگوهای خرابی که باید در بازبینی طراحی رد شوند

چک‌لیست بازبینی حقیقت زمانی

پیش از اجازه دادن به گردش کار هوش مصنوعی برای تصمیم یا اقدام پیامددار، بررسی کنید:

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

چه چیز را پایش و چه زمانی قرارداد را بازنگری کنیم؟

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

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

یادداشت منابع — بازبینی‌شده در ۱۳ اوت ۲۰۲۶

• RFC 3339: تاریخ و زمان در اینترنت — نحو مهر زمانی، ناحیه زمانی و مرزهای عادی‌سازی بررسی شد.
• مدل داده W3C PROV — مفاهیم منشأ برای تولید، استفاده، بی‌اعتبارشدن، موجودیت، فعالیت و عامل بررسی شد.
• مدل داده لاگ OpenTelemetry — تفاوت زمان وقوع در مبدأ و زمان مشاهده بررسی شد.
• راهنمای برنامه‌نویسی Apache Beam — زمان رویداد، زمان پردازش، watermark، trigger و رفتار داده دیررس بررسی شد.
• جداسازی تراکنش PostgreSQL — رفتار نمای فرمان و تراکنش و نیاز به اجرای دوباره Serializable بررسی شد.
• Google Spanner: سازگاری بیرونی و TrueTime — ترتیب ثبت و ویژگی خواندن نمای چندنسخه‌ای بررسی شد.