اگر برای عاملهای هوش مصنوعی خود حافظه بلندمدت تعریف کردهاید، احتمالاً با مشکل «لغزش زمانی» مواجه شدهاید؛ جایی که مدل یادداشتهای قدیمی را صرفاً چون امروز وارد شدهاند، به عنوان اطلاعات جدید میشناسد. موتور حافظه محلی Uteke در تاریخ ۱۴ سپتامبر ۲۰۲۶ با انتشار نسخه ۰.۱۸.۰، این نقص ساختاری را با مکانیزم لنگرهای زمانی برطرف کرد. تمرکز این نسخه بر روی «لولهکشیهای عملیاتی» است؛ یعنی دقیقاً اینکه خاطرات چگونه تاریخگذاری، ذخیره و بازیابی شوند.
Uteke یک موتور حافظه است که به صورت یک فایل باینری تکفایلی با زبان Rust و تحت لایسنس Apache 2.0 عرضه شده است. این ابزار برای کار به هیچ کلید API یا اتصال به ابر نیاز ندارد و تا لحظه نگارش این متن، ۲۴۶ ستاره در گیتهاب دارد.
بسیاری از سامانههای حافظه، لحظه وارد شدن داده را به عنوان زمان وقوع حقیقت در نظر میگیرند. این موضوع باعث میشود اگر شما یادداشتهای یک ماه پیش را امروز وارد کنید، عامل هوش مصنوعی آنها را «تازه» تشخیص دهد. همانطور که در تحلیلهای پیشین ما درباره امنیت مدلهای بازمتن اشاره کردیم، دقت در مدیریت وضعیت (State) عاملها برای کاربردهای صنعتی حیاتی است. در حالت فعلی، قابلیتهایی مثل بازیابی در زمان خاص (recall --at)، تقویت نتایج بر اساس تازگی (Recency Boosts) و زنجیرههای حسابرسی (Audit Chains)، به دلیل اینکه ترتیب ورود دادهها تعیینکننده نتیجه بود، غیرقابل اعتماد بودند. این چالشها در واقع ریشه در تفاوت بنیادین میان بازیابی داده و اجرای دستورات دارد، موضوعی که در بررسی شکست حفاظهای عاملهای هوش مصنوعی به تفصیل به آن پرداختیم.
به نقل از مستندات نسخه جدید، Uteke اکنون از لنگرهای زمانی پشتیبانی میکند. شما میتوانید با استفاده از پرچم --timestamp در محیط خط فرمان (CLI)، زمان دقیق وقوع یک خاطره را تعیین کنید. برای مثال: uteke remember "Ship window moved to March 15" --timestamp "2026-03-15T09:00:00Z". این قابلیت برای وارد کردن دستهای دادهها نیز فعال شده است تا یک پوشه از یادداشتهای قدیمی بتواند در یک مرحله، تاریخهای واقعی خود را به سیستم منتقل کند. این امر تضمین میکند تصمیمی که در ماه مارس گرفته شده، فارغ از زمان ورود به پایگاهداده، مانند یک خاطره مربوط به مارس رفتار کند. لازم به ذکر است که متغیر محیطی LMEVAL_DATE_ANCHOR که در لیست تغییرات ذکر شده، صرفاً برای سیستم بنچمارک (Benchmark Harness) است و تأثیری روی فایل باینری نهایی ندارد.
مدیریت اتاقها و حافظه
این بهروزرسانی عملیات کامل چرخه حیات را برای «اتاقها» (Rooms) معرفی کرده است. اتاقها در واقع بخشهای مجزای حافظه برای هر پروژه هستند. کاربران اکنون میتوانند:
- نام اتاقها را تغییر دهند، آنها را بهروزرسانی کنند یا خاطرات را بین اتاقها جابهجا کنند. این کار از طریق دستورات CLI (مانند
uteke room rename،uteke room updateوuteke room move-memory)، مسیرهای HTTP (مانندPOST /room/renameو/room/updateو/room/memory/move) و ابزارهای MCP امکانپذیر است. - از یکپارچگی دادهها هنگام تغییر نام مطمئن شوند؛ زیرا سیستم تمام ارجاعات رجیستری و هر ارجاع به اتاق را در یک تراکنش واحد بازنویسی میکند تا از ایجاد وضعیتهای نیمهکاره (Half-renamed states) جلوگیری شود.
- با استفاده از طرحواره (Schema) v19، برای اتاقها توضیحات اضافه کنند. این نسخه افزایشی (Additive) است و خروجیهای سازگار با نسخههای قدیمی را فراهم میکند. این رویکرد در مدیریت حافظه مجزا، مشابه تلاشهای آنتروپیک برای ادغام سیستمهای حافظه در کلود است تا نیاز به تکرار جزئیات پروژه کاهش یابد.
- تکتک خاطرات را با دستور
uteke update <id>ویرایش کنند تا محتوا، برچسبها، میزان اهمیت، وضعیت پینشده یا نوع خاطره را در همان مکان تغییر دهند. در حالی که مسیر HTTPPUT /memoryو ابزار MCPuteke_updateپیش از این از این قابلیت پشتیبانی میکردند، اکنون محیط CLI نیز این امکان را فراهم کرده است.
اصلاح امتیازدهی بازیابی
طبق گزارش توسعهدهندگان، یک آستانه (Threshold) قدیمی از نسخه ۰.۱۶.۰ به بعد، تقریباً تمام نتایج را بهطور خاموش فیلتر میکرد. سیستم از استراتژی RRF (Reciprocal Rank Fusion) وزنی استفاده میکرد که امتیازات آن معمولاً بین ۰.۰ و ۰.۲ بود، اما مقدار پیشفرض CLI روی ۰.۳ مانده بود؛ عددی که مربوط به دوران قدیمی شباهت کسینوسی (Cosine Similarity) بود، زمانی که امتیازات معمولاً بالای ۰.۵ خوشهبندی میشدند.
تستها روی مدل embeddinggemma-q4 نشان داد که ۲۰ نمونه بازنویسی شده (Paraphrase Probes)، در رتبه اول امتیازی بین ۰.۱۶۹ و ۰.۱۸۶ کسب کردند. چون این اعداد کمتر از ۰.۳ بودند، کاربران خروجی خالی میدیدند. نسخه ۰.۱۸ این مقدار پیشفرض را به ۰.۰ کاهش داد تا فیلتر کردن فقط زمانی رخ دهد که کاربر صراحتاً آن را درخواست کند؛ مثلاً از طریق [recall] min_score در تنظیمات، پرچم --min در CLI، پرچم --strict (برای مقدار ۰.۵) یا پارامتر min_score در درخواستهای HTTP.
قراردادهای داده و محکها
در نسخه ۰.۱۸، قراردادهای مربوط به دادههای بازیابی (Recall Payload) تثبیت شدهاند و تستهای انطباق در تمامی سطوح CLI، HTTP و MCP اجرا شدهاند. اکنون هر نتیجه بازیابی، تمام دادههای کامل خود را منتقل میکند نه فقط یک شمارنده ساده (Hit-count stub)، تا بهینهسازیهای آینده باعث شکست در وعدههای عملکردی نشوند. این دقت در انتقال دادهها برای جلوگیری از سوگیریهای آماری ضروری است، چرا که تاریخچه ناقص یا کورکورانه دادهها میتواند تحلیلهای ریشهای هوش مصنوعی را به شدت تحت تأثیر قرار دهد.
اگرچه رفتار بازیابی تغییر نکرده و امتیاز Recall@5 در مقدار ۰.۹۴۵۷ در بخش non-abstention باقی مانده است، اما نحوه ذخیره این محکها (Benchmarks) متمرکز شده است. تمام این دادهها اکنون در دایرکتوری جدید benchmarks/ قرار دارند و یک فهرست در benchmarks/README.md برای آنها ایجاد شده است. این تغییر جایگزین نتایج قدیمی شده و خطای برچسبگذاری یک خط مبنا (Baseline) را اصلاح کرده است؛ به گونهای که اعداد ۰.۸۵۴ و ۰.۸۸۵ مربوط به ماه اوت، اکنون بهدرستی به عنوان نتایج اجرای «فقط برداری» (Vector-only run) شناسایی شدهاند.
برای کسانی که این موتور را اجرا میکنند، بهروزرسانی از طریق دستور زیر در دسترس است:UTEKE_VERSION=v0.18.0 curl -fsSL https://raw.githubusercontent.com/codecoradev/uteke/main/install.sh | sh.
همچنین کاربران میتوانند از دستور uteke upgrade برای جایگزینی CLI استفاده کنند. پس از ارتقا، تأیید کنید که uteke ، uteke-serve و uteke-mcp همگی نسخه ۰.۱۸.۰ را گزارش میکنند تا از همگامسازی باینریهای سرور و MCP مطمئن شوید.
گام بعدی شما
- اگر از نسخههای قدیمی استفاده میکنید، با دستور
uteke upgradeابزار خود را بهروز کنید. - پس از نصب، دستور
uteke-serveوuteke-mcpرا اجرا کنید تا مطمئن شوید هر سه باینری روی نسخه ۰.۱۸.۰ هستند. - برای دادههای قدیمی، از پرچم
--timestampاستفاده کنید تا ترتیب زمانی حافظه عامل شما به هم نریزد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو