문제의식: 균일 양자화는 모든 파라미터가 똑같이 압축 가능하다고 가정한다

MoE 아키텍처는 토큰마다 소수의 전문가(expert) 서브네트워크만 활성화시켜 파라미터 수와 토큰당 연산량을 분리합니다. 그런데 인터랙티브 서빙처럼 배치 크기가 작은 상황에서는 연산량이 아니라 대역폭이 병목이 됩니다. 토큰이 여러 전문가로 흩어지다 보니 각 전문가의 가중치 행렬은 몇 개 토큰을 처리하려고 매번 HBM에서 새로 실려 나오고, GPU는 대부분의 시간을 연산이 아니라 메모리 대기에 씁니다. NVFP4처럼 4비트로 가중치를 압축하는 초저정밀도 포맷은 이 병목을 정면으로 공략하지만, 모델 전체를 균일하게 양자화하는 접근은 모든 파라미터 블록이 똑같이 압축을 견딘다고 암묵적으로 가정합니다.

저자들은 이 가정이 틀렸다고 지적합니다. MoE에는 구조적으로 특별한 두 부분이 있습니다. 하나는 라우터입니다. 라우터의 출력은 argmax를 거쳐 이산적인 라우팅 결정으로 이어지기 때문에, 다른 은닉 상태처럼 노이즈가 더해지는 것으로 끝나지 않고 로짓이 조금만 흔들려도 토큰이 완전히 다른 전문가로 튈 수 있습니다. 다른 하나는 트래픽이 낮은 “희귀” 전문가입니다. 이들은 실려 나오는 빈도가 낮아 전체 대역폭 비용에는 거의 기여하지 않지만, 그 전문가로 라우팅되는 소수의 토큰은 그 전문가의 특화된 표현에 의존합니다. 트래픽 가중 관점에서 보면 라우터와 희귀 전문가는 스트리밍되는 바이트에서 차지하는 비중이 작기 때문에, 보호하는 데 드는 대가는 작으면서 얻는 안정성은 크다는 것이 논문의 핵심 통찰입니다.

Switch-Base-8 MoE 아키텍처를 바탕으로 한 개념적 트래픽 분포입니다. 실측 데이터가 아니라 논문의 정책 설계를 설명하기 위한 예시 그림으로, 트래픽 순위를 정규화한 뒤 RASQ의 레이어별 중앙값 분할 경계를 표시했습니다.

핵심 기여: RASQ 정책과 정직하게 재정의된 비교 질문

논문은 이 정책을 Router-Aware Selective NVFP4 Quantization, 줄여서 RASQ라고 부릅니다. 정의는 간단합니다. MoE 레이어마다 전문가를 트래픽으로 순위를 매기고 중앙값을 기준으로, 트래픽이 많은 상위 절반은 4비트로 양자화하고 트래픽이 적은 하위 절반은 전정밀도(16비트)로 남겨둡니다. 라우터 선형 레이어는 예외 없이 항상 전정밀도로 고정합니다. 저자들은 이 median split이 진짜 “긴 꼬리의 희귀 전문가”만 골라내는 정교한 방법이 아니라 각 레이어 전문가의 절반을 보호하는 거친 근사치라는 점도 분명히 밝히고, 하위 10퍼센트만 보호하는 식의 더 정교한 변형이나 지식배낭(knapsack) 형태의 예산 제약 할당으로 확장할 수 있는 여지를 남겨둡니다.

이 정책을 실제로 비교 가능하게 만들기 위해 논문은 스토리지 비트 단위의 비용 모델을 수식으로 제시합니다. 4비트로 양자화된 레이어는 가중치 4비트에 채널별 스케일·제로포인트 오버헤드를 더해서 계산하고, 전정밀도로 남긴 레이어는 16비트 그대로 계산합니다. 이 틀 안에서 균일 4비트 양자화는 RASQ의 임계값을 극단으로 밀어 모든 전문가를 4비트로 만든 특수한 경우로 정확히 환원됩니다. 즉 균일 양자화와 RASQ는 같은 한 개 파라미터짜리 임계값 계열 위의 두 점일 뿐입니다.

논문 3장의 비용 모델을 기준으로 계산한 개념적 저장 비용 분해입니다. 균일 NVFP4는 모든 전문가 선형 레이어를 4비트로, RASQ는 라우터와 희귀 전문가 레이어를 16비트로 두고 트래픽이 많은 전문가만 4비트로 압축합니다.

여기서 논문이 특히 정직한 대목이 나옵니다. 저자들은 이 정적 스토리지 지표 아래에서는 RASQ가 구성상 필연적으로 균일 4비트보다 더 많은 비트를 저장할 수밖에 없다는 사실을 스스로 짚습니다. 트래픽이 적은 절반을 전정밀도로 지키는 순간 양자화되는 파라미터 수가 줄어들기 때문입니다. 그래서 RASQ가 균일 양자화를 두 축 모두에서 앞서는 엄밀한 파레토 지배를 주장하는 것은 애초에 산술적으로 불가능하며, 그런 주장을 검증하려는 시도 자체가 틀린 질문이라고 못박습니다. 대신 논문이 던지는 잘 정의된 질문은 보간 효율성입니다. 균일 양자화와 전정밀도 기준선 사이의 정확도 격차 중 RASQ가 얼마나 회복하는지를, 그 대가로 지불하는 저장 공간 프리미엄의 비율과 나란히 놓고 비교하는 것입니다. 이를 위해 논문은 google/switch-base-8이라는 실제 공개 Switch-Transformer 모델을 프록시로 삼아, 채널별 affine 4비트 가짜 양자화 연산자로 NVFP4의 정확도 효과를 하드웨어 독립적으로 근사하는 완전한 재현 가능 평가 프로토콜을 세 가지 설정(전정밀도 기준선, 균일 4비트, 선택적 4비트인 RASQ)으로 구체화합니다.

이 프로토콜을 실행하기 위해 실제로 H200 GPU 클러스터에 Kueue 커스텀 라우트 잡을 제출했지만, tkai-prod-compute-h200이라는 GPU 컨텍스트가 제출 시점에 존재하지 않는다는 오류로 잡 자체가 첫 forward pass도 시작하기 전에 실패했습니다. 저자들은 이를 부정적인 실험 결과로 포장하지 않고, “측정된 것이 아니라 건너뛴 것”이라고 있는 그대로 보고합니다. 그 결과 이 논문이 실제로 내놓는 것은 실측치가 아니라 형식화된 정책과 비용 모델, 그리고 클러스터가 복구되는 즉시 그대로 실행할 수 있는 완결된 프로토콜입니다.

회사·사회·과학에 걸친 기여

논문은 기여를 세 층위로 나눕니다. 플랫폼·산업 층위에서는 RASQ를 Kueue 같은 배치 스케줄러가 H200이나 Blackwell급 클러스터에 MoE 추론 잡을 배치할 때 기본값으로 채택할 수 있는 정책으로 제안합니다. 오프라인에서 한 번 트래픽을 프로파일링하고 나면 정적인 정밀도 맵이 고정되므로, 런타임 제어 루프 없이도 모델 로딩·admission 로직과 깔끔하게 결합됩니다. 사회적 층위에서는 토큰당 추론 비용과 에너지를 낮춤으로써, 강력한 오픈 MoE 모델을 자원이 제한된 조직이나 개인도 전정밀도 서빙 비용 부담 없이 쓸 수 있게 넓히는 효과를 기대합니다. 과학적 층위에서는 전문가 트래픽 분포에 기반한 선택적 정밀도 배분이 균일 NVFP4 양자화 대비 정확도-비용 파레토 곡선을 어디까지 개선하는지를 실측 가능한 형태로 질문하며, 균일·블록 단위 NVFP4 양자화를 다뤄온 기존 PTQ 문헌에 저장 비용 모델과 균일 양자화의 엄밀한 특수 케이스 환원, 예산 제약 할당으로의 확장 경로를 더합니다.

정확도-저장비용 파레토 프론티어 위에서 RASQ가 균일 4비트(최소 저장, 최대 오차)와 전정밀도 기준선(최대 저장, 최소 오차) 사이를 어떻게 보간하는지 보여주는 개념도입니다. 실측치가 아니라 4장 한계에서 밝히듯 실제 측정은 이루어지지 않았으며, 정확도 축은 16문장 프로브셋의 크로스엔트로피 손실, 저장 축은 정적 전체 모델 스토리지 비트 기준입니다.

측정치가 없는 대신 논문은 문헌에 근거한 명시적으로 조건부인 예측을 제시합니다. 라우터 로짓 섭동이 라우팅 자체를 불안정하게 만든다는 기존 연구, 전문가 트래픽이 롱테일이라 균일 배분이 예산을 낭비한다는 utilization-aware 정밀도 연구, 저비트 양자화를 비트 예산 대비 품질의 파레토 문제로 보는 스케일링 법칙 연구를 근거로, RASQ가 균일 4비트 대비 정확도 격차의 큰 부분을 작은 저장 프리미엄만으로 회복하는 효율적인 중간점이 될 것이라 기대한다고 밝힙니다. 다만 이는 어디까지나 예측이며, 그 어떤 것도 발견(finding)으로 제시하지 않습니다.

한계

가장 근본적인 한계는 실측이 전혀 없다는 것입니다. 클러스터 인프라 결함으로 잡이 forward pass 전에 실패했기 때문에, 논문에 나오는 모든 수치적 서술은 정의이거나 예측일 뿐 결과가 아닙니다. 두 번째로, 정확도 측정에 쓰는 채널별 affine 4비트 가짜 양자화 연산자는 NVFP4의 2단계 마이크로블록 스케일링 수치 체계와 반올림 방식이 다른 프록시일 뿐입니다. H200은 Hopper 세대라 네이티브 FP4 텐서코어가 없어 이 프록시가 필요했고, 따라서 이 프로토콜은 정확도 효과만 근사할 수 있을 뿐 NVFP4의 실제 처리 속도 향상은 측정할 수 없습니다. 세 번째로, 프로토콜은 top-1 라우팅을 쓰는 소형 Switch-Transformer 모델 하나만 대상으로 하므로, 더 큰 MoE나 top-k 라우팅, 다른 전문가 수를 가진 아키텍처로 결과가 그대로 전이될지는 불확실합니다. 네 번째로, RASQ가 쓰는 정적·오프라인 트래픽 프로파일은 배포 워크로드가 바뀌면 어긋날 위험이 있습니다. 기존 utilization-aware 연구가 보고하듯 전문가 트래픽은 워크로드에 따라 어느 전문가가 핫한지가 달라질 수 있어서, 한 번 계산한 중앙값 분할이 배포 시점에는 엉뚱한 전문가를 보호하고 있을 수 있습니다. 마지막으로, 트래픽 프로파일링과 정확도 평가 모두 같은 16문장짜리 소규모 프로브셋을 재사용하기 때문에 두 측정이 서로 결합돼 있다는 점도 저자들이 스스로 지적하는 약점입니다.

논문 상세 페이지: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-12-nvfp4-moe-selective-quant

نظرة عامة

حتى الآن، كانت سير عمل البرمجة متعددة الوكلاء تجري غالباً ضمن مورد واحد فقط. ففي Claude Code مثلاً، يقود Opus العمل بينما تعمل Sonnet أو Haiku كوكلاء فرعيين. والنقطة اللافتة في fable-advisor هي أنها تبني هذا التقسيم عبر حدود الموردين. حيث يتولى Fable 5 من Anthropic طبقة التنسيق، بينما يتولى Grok 4.5 من xAI طبقة التنفيذ.

الرؤية الجوهرية لهذا التصميم واضحة. القيادة والتنفيذ يتطلبان قدرات مختلفة، وبنية تكلفة مختلفة أيضاً. كتابة المواصفات ومراجعة الفروقات تقع في مجال الحكم والاستدلال، مما يستلزم نموذجاً مناسباً للقيادة، بينما تتطلب كتابة كميات كبيرة من الشيفرة كفاءة في الإنتاجية والتكلفة. تضع fable-advisor كلاً من هاتين المهمتين على نماذج من موردين مختلفين، بحيث يُستخدم في كل طبقة النموذج الأنسب لها. كونها مفتوحة المصدر ومجانية، وإمكانية تخصيص منطق التوجيه مباشرة، يخفّض أيضاً عتبة التبني في الاستخدام الفعلي.

ما هذه التقنية

fable-advisor هي إضافة تُركَّب فوق Claude Code، وتفرض فصلاً بين ثلاثة أدوار.

أولاً، الموجّه (Fable 5) يكتب المواصفات ويراجع النتائج. يستقبل طلب المستخدم ويحلله إلى مواصفات تنفيذ، ثم يراجع الفروقات (diff) بعد اكتمال التنفيذ. والمهم هنا أن الموجّه لا يكتب الشيفرة مباشرة، بل يركز على الحكم وتعريف العقود.

ثانياً، المُنفِّذ (Grok 4.5) يتولى الكتابة الفعلية وحده. يستقبل المواصفات التي يسلّمها الموجّه، ويكتب Grok 4.5 الشيفرة عبر Grok CLI. وإذا تفحصنا تاريخ المستودع، نجد أنه اعتباراً من الإصدار v3 تم استبدال وكلاء التنفيذ السابقين المعتمدين على Sonnet/Opus بـ grok-implementer، ليصبح Grok 4.5 مسار الكتابة الافتراضي. بعبارة أخرى، لم تكن هذه الإضافة متعددة الموردين منذ البداية، بل هي نتاج تطور تدريجي نحو نقل مسار التنفيذ إلى نموذج منخفض التكلفة وعالي الإنتاجية.

ثالثاً، التنفيذ المتوازي. تُنفَّذ المواصفات المستقلة عن بعضها البعض في آن واحد عبر وكلاء متوازيين. فعندما يقسّم الموجّه المهمة إلى وحدات لا تعتمد على بعضها، تمضي كل وحدة قدماً في وقت واحد عبر وكيل تنفيذ منفصل. وهذا ليس مجرد تفويض تسلسلي بسيط، بل أقرب إلى تقسيم عمل على شكل DAG (رسم بياني موجّه غير دوري).

إذا نظرنا إلى سير العمل الكامل بشكل تخطيطي، يكون كما يلي.

flowchart TB
    U[طلب المستخدم] --> F[موجّه Fable 5<br/>كتابة المواصفات ومراجعة diff]
    F -->|تحليل مواصفات مستقلة| S1[مواصفة A]
    F -->|تحليل مواصفات مستقلة| S2[مواصفة B]
    S1 -.Grok CLI.-> G1[منفّذ Grok 4.5 A]
    S2 -.Grok CLI.-> G2[منفّذ Grok 4.5 B]
    G1 -->|diff| F
    G2 -->|diff| F
    F --> R[نتيجة الدمج والمراجعة]

التثبيت والتكامل

تثبيت الإضافة يتم بسطر واحد فقط. يكفي إضافة المستودع إلى سوق إضافات Claude Code.

claude plugin marketplace add DannyMac180/fable-advisor

يتطلب Grok CLI، المسؤول عن مسار التنفيذ، مصادقة منفصلة. فعند تسجيل الدخول عبر grok login، يعمل النظام بمصادقة OAuth قائمة على اشتراك SuperGrok أو X Premium+، وبحسب وصف المستودع، يتيح هذا المسار تشغيل وكيل التنفيذ بالاشتراك فقط ودون رسوم API لكل رمز (token). وهذه النقطة هي جوهر بنية التكلفة. فالموجّه يقوم بعدد قليل فقط من الاستدعاءات التي تتطلب حكماً، بينما تُعالَج الكمية الكبيرة من كتابة الشيفرة ضمن خطة الاشتراك، مما يقلّل إلى أدنى حد الجزء الخاضع للرسوم حسب الاستخدام.

من زاوية التكامل، الجانب الجدير بالملاحظة هو أن منطق التوجيه مفتوح. إذ يمكن للمستخدم أن يضبط بنفسه أي مهمة تُرسَل إلى أي نموذج، وفي أي شروط يتم التوازي، مما يتيح إعادة تشكيل المسارات بما يتناسب مع ميزانية الفريق ومتطلبات الجودة.

كيف يعمل هذا التصميم فعلياً

بما أن fable-advisor ليست أداة تعتمد على أرقام قياسية (بنشمارك)، بل نمط سير عمل، فسنتناول هنا الأثر البنيوي الذي يُحدثه هذا التصميم بدلاً من أرقام أداء قابلة للتكرار. وبما أن المستودع لا يقدّم مؤشرات كمية، فإن هذا المقال أيضاً لن يختلق أرقاماً، بل سيتناول المزايا البنيوية فقط.

أكبر أثر هو الفصل بين التكلفة والجودة. فعندما يُوكَل التنسيق الذي يتطلب حكماً إلى الموجّه، ويُوكَل التنفيذ الذي يتطلب إنتاجية عالية إلى منفّذ منخفض التكلفة، ينخفض السعر الإجمالي لسير العمل مع بقاء جودة الحكم كما هي. وهكذا يتشكّل بشكل طبيعي توزيع مفاده “لا يُستدعى الموجّه كثيراً لكنه غالي الثمن، بينما يُستدعى المنفّذ كثيراً دون أن يكون مكلفاً”.

الأثر الثاني هو التحقق المتقاطع. كون المنفّذ والمراجِع نموذجين من موردين مختلفين يُنتج أثراً جانبياً مثيراً للاهتمام. فعندما يراجع النموذج نفسه شيفرته الخاصة، يسهل عليه إغفال نفس الأخطاء، أما عندما يراجع نموذج من سلالة مختلفة الفروقات (diff)، تزداد فرصة اكتشاف النقاط العمياء لدى كل منهما. وبذلك يصبح الفصل بين الموجّه والعامل أكثر من مجرد تقسيم عمل بسيط، بل نوعاً من آلية التحقق المتبادل.

الأثر الثالث هو تقليص زمن الاستجابة بفضل التوازي. فعند تنفيذ المواصفات المستقلة في آن واحد، لا يكون إجمالي وقت العمل مجموعاً تسلسلياً، بل يتقارب مع أطول سلسلة مفردة. وكلما أحسن الموجّه تحليل المهمة إلى وحدات، ازدادت هذه الميزة.

تعميم نمط الموجّه والعامل

إذا نظرنا إلى fable-advisor ليس كإضافة منفردة بل كنمط تصميم، يتضح سياق أوسع. جوهر هذا النمط هو “الجلسة الرئيسية تقود فقط، والمهام الثقيلة تُفوَّض”. وكون العمل عابراً للموردين ليس سوى صورة واحدة من صور هذا النمط، إذ يصح فعلياً حتى داخل مورد واحد. فمثلاً في Claude Code، يُستخدم على نطاق واسع بالفعل تكوين يجعل Fable 5 موجّهاً، بينما يُوكَل الاستكشاف إلى Haiku، والتنفيذ إلى Sonnet، والاستدلال المعقد إلى وكلاء فرعيين من Opus. وما فعلته fable-advisor هو توسيع نطاق النماذج المستهدفة بهذا التفويض إلى ما وراء حدود المورد الواحد.

من هذا المنظور، تصبح معايير اختيار نموذج الموجّه أكثر وضوحاً. فالموجّه مسؤول عن الحكم والتفرّع والتجميع، لذا فإن الدقة وجودة الاستدلال مهمتان، بينما يكون تكرار الاستدعاء منخفضاً نسبياً. في المقابل، يهتم المنفّذ بالإنتاجية والسعر. لذا فإن التنسيق الجيد ليس “وضع النموذج الأغلى كموجّه ومعالجة كل شيء به”، بل “تخصيص نموذج بالخصائص التي تتطلبها كل طبقة لتلك الطبقة تحديداً”. وتطور الإصدار v3 الذي نقل فيه fable-advisor مسار التنفيذ إلى نموذج اشتراك منخفض التكلفة هو نتيجة مطابقة تماماً لهذا المبدأ.

نقطة واحدة يجب الانتباه إليها هي أن هذا النمط لا يكون فعالاً إلا إذا كانت حدود التفويض واضحة. فإذا سلّم الموجّه مواصفات غامضة، يضطر المنفّذ إلى ملء الفجوات بالتخمين، وتزداد نتيجة لذلك عبء المراجعة. لا تتحقق فائدة التفويض إلا عندما تكون المواصفات محددة بما فيه الكفاية. وهذا لا يختلف عن تقسيم العمل في المنظمات البشرية، فكلما كانت المواصفات أوضح، عمل التفويض بشكل أفضل.

دلالات التطبيق على منتجات ThakiCloud

يتقاطع هذا التصميم بشكل لافت مع الطريقة التي تُشغّل بها ThakiCloud وكلاءها.

من منظور Paxis، يكون الارتباط الأوثق مباشرةً. فـ Paxis هو مستوى التحكم الخاص بـ ThakiCloud للسحابة القائمة على الوكلاء (Agent-Native Cloud)، ويتعامل مع تنفيذ الوكلاء المتعددين على شكل DAG كقدرة أساسية. البنية التي تُظهرها fable-advisor — “كتابة المواصفات ← تنفيذ موزّع ← مراجعة متقاطعة” — تحمل نفس الهيكل الذي يعتمده حزام أدوات المهارات (skill harness) في Paxis، حيث يُحلَّل العمل إلى مهام فرعية، وتُنفَّذ بشكل متوازٍ داخل صناديق رملية معزولة، ثم تُغلَق عبر مرحلة تحقق. وعلى وجه الخصوص، فإن المبدأ القائل بأن الموجّه لا يكتب الشيفرة مباشرة بل يركّز على الحكم وتعريف العقود، يتطابق تماماً مع فلسفة التصميم لدينا التي تستمد القدرة من بنية العقد المحيطة لا من درجة النموذج. كما أن التدفق الذي يُعيد فيه الموجّه مراجعة نتائج نماذج مختلفة، يتقاطع أيضاً مع مبدأنا التشغيلي القاضي بإغلاق توسّع الوكلاء المتعددين (fan-out) عبر مرحلة تحقق لمنع تراكم الهلوسة.

من منظور ai-platform، تكون زاوية بنية التكلفة سارية المفعول. فمنصة ai-platform الخاصة بـ ThakiCloud تجدول أحمال عمل وحدات معالجة الرسوميات (GPU) اعتماداً على K8s وKueue، وتخدم أحمال الاستدلال والتدريب لدى العملاء. الفكرة التي تعتمدها fable-advisor بتفويض مسار التنفيذ إلى نموذج منخفض التكلفة لخفض السعر الإجمالي لسير العمل، هي نمط يمكن لعملاء السحابة القائمة على GPU تطبيقه مباشرة عند تصميم أحمال عملهم. فعندما تُوضَع مراحل الحكم القليلة التي تتطلب استدلالاً ثقيلاً، ومراحل التنفيذ الكثيرة التي تتطلب إنتاجية عالية، على موارد من فئات مختلفة، يمكن الحصول على النتيجة نفسها بتكلفة أقل. وبما أن الخدمة منخفضة التكلفة هي ما يصنع جدوى الوكلاء الاقتصادية، فإن كفاءة تكلفة ai-platform وتنسيق وكلاء Paxis يكمّلان بعضهما البعض.

القيود والاعتراضات

لهذا التصميم أيضاً ثمن واضح يجب دفعه. أولاً، تعقيد التشغيل. فربط نموذجين من موردين مختلفين في سير عمل واحد يعني إدارة نظامي مصادقة، وخطتي تسعير، ونقطتي فشل محتملتين. فإذا تغيّرت واجهة سطر الأوامر لأحد الموردين أو انتهت صلاحية المصادقة، قد يتوقف سير العمل بأكمله. وبما أن هذا يعني التخلي عن بساطة سير العمل أحادي المورد مقابل هذه الميزة، فإن كل فريق قد يقيّم بشكل مختلف ما إذا كانت الميزة تبرر هذا التعقيد.

ثانياً، مخاطر تفويض الجودة. إسناد التنفيذ إلى نموذج منخفض التكلفة يعني أنه إذا لم تكن مواصفات ومراجعات الموجّه دقيقة بما فيه الكفاية، فقد يمر تنفيذ منخفض الجودة دون رصد. وجودة سير العمل هذا تعتمد في نهاية المطاف على مدى صرامة بوابة المراجعة لدى الموجّه. فإذا كانت المراجعة شكلية، يختفي أثر التحقق المتقاطع الناتج عن تقسيم العمل بين الموردين، ويتحول الأمر إلى خط أنابيب منخفض الجودة لا يوفر سوى التكلفة.

ثالثاً، قيود المصادقة القائمة على الاشتراك. كون Grok CLI يعمل بمصادقة OAuth قائمة على الاشتراك يمثّل ميزة من حيث التكلفة للأفراد أو الفرق الصغيرة، لكن في الأتمتة واسعة النطاق أو خطوط الأنابيب غير المأهولة، قد تصبح حدود الاشتراك وتجديد المصادقة عنق زجاجة. وميزة عدم وجود رسوم حسب الاستخدام تعني، إذا نظرنا إليها من الجانب الآخر، أن التوسع يُغلَق بمجرد تجاوز الاستخدام للحد المسموح.

ومع ذلك، فإن الرسالة التي تطرحها fable-advisor واضحة. مستقبل وكلاء البرمجة لا يكمن في نموذج واحد شامل، بل في تنسيق يجمع بين النماذج الأنسب لكل طبقة. وهذا يشير بالضبط إلى نفس الوجهة التي تسلكها ThakiCloud في تعاملها مع الوكلاء المتعددين وتوجيه النماذج كمورد أساسي من الدرجة الأولى.

المصادر

• fable-advisor (GitHub)
• Grok CLI (x.ai/cli)

نظرة عامة

النهج الشائع لمعالجة مشكلة ذاكرة العامل هو قاعدة البيانات المتجهية. تُحوَّل المحادثات والمستندات إلى متجهات تضمين (embeddings) وتُخزَّن، ثم تُستدعى عند الحاجة عبر بحث دلالي. هذا النهج قوي لكن عبء تشغيله كبير. يجب إدارة خط أنابيب التضمين، والفهرس المتجهي، وجدولة إعادة الفهرسة، وهي بنية تحتية مفرطة بالنسبة لفرد يريد إضافتها إلى سير عمله الخاص.

يسلك personal-monorepo-template اتجاهًا معاكسًا تمامًا. يعيد تعريف الذاكرة لا كمشكلة بحث، بل كمشكلة بنية ملفات. يوضع الأشخاص في مجلد people/، والمشاريع كحزم مشاريع، وأنماط العمل المتكررة كمهارات داخل المستودع نفسه. ويحمّل العامل هذه البنية باستمرار عبر AGENTS.md في بداية كل جلسة. فبدلًا من التطابق التقريبي للبحث المتجهي، يصل العامل إلى الذاكرة عبر عنوان دقيق هو مسار المجلد.

خلفية صاحب المشروع تضفي ثقلًا على هذا التصميم. jxnl هو صانع مكتبة الإخراج المهيكل (structured output) المسماة Instructor، والتي تُحمَّل ملايين المرات شهريًا، ويُقال إن OpenAI استشهدت بها كمصدر إلهام لميزة الإخراج المهيكل الخاصة بها. وهو حاليًا مهندس تجربة المطوّرين (Developer Experience) في فريق OpenAI Codex، ما يجعل قيمة هذا المرجع كبيرة كونه أداة صنعها شخص يشغّل عوامل البرمجة يوميًا في الميدان لحل مشكلته الخاصة.

ما هذه التقنية

الفكرة الجوهرية واحدة. تمثيل ذاكرة العامل عبر مجلدات وماركداون عادية داخل مستودع أحادي (monorepo)، وتحميلها تلقائيًا في كل جلسة. يمكن تقسيمها إلى ثلاثة محاور.

المحور الأول هو سجلات الأشخاص والمشاريع. يفحص المستودع سلاك والبريد الإلكتروني والتقويم وGitHub لإنشاء ملفات people وحزم المشاريع، ويقترح تحديثات على AGENTS.md المحمَّل باستمرار. عند ذكر اسم زميل معيّن، يقرأ العامل ملف ذلك الشخص لاستعادة السياق فورًا. دون قاعدة بيانات متجهية، يجد العامل “من هو هذا الشخص” عبر مسار مجلد دقيق.

المحور الثاني هو المهارات المحلية داخل المستودع. حين توضع أنماط العمل المتكررة كمهارات داخل المستودع، تُحمَّل تلقائيًا في كل جلسة ويتبعها العامل. من أبرز الأمثلة مهارة write-like-me المدمجة، التي تتعلم من رسائل البريد الإلكتروني ورسائل سلاك المُرسَلة سابقًا لتكتب بأسلوب المستخدم نفسه. بنية يصبح فيها الإنتاج السابق للمستخدم بيانات تدريب للمهارة نفسها.

المحور الثالث هو التسجيل التلقائي (check-in). صُمم المستودع لتشغيل تسجيل تلقائي في التاسعة صباحًا والرابعة مساءً يوميًا، حيث يلخّص حالة المشاريع والسياق المتعلق بالأشخاص لذلك اليوم ويقترح التحديثات. هذه حلقة يحدّث فيها العامل ذاكرته من تلقاء نفسه في أوقات محددة، بدلًا من انتظار استدعاء يدوي.

يوضّح المخطط التالي التدفق الكامل.

flowchart TB
    SRC[سلاك · البريد الإلكتروني · التقويم · GitHub] -->|فحص| SCAN[نص برمجي للتسجيل التلقائي]
    SCAN --> PEOPLE[اقتراح ملف people]
    SCAN --> PKT[اقتراح حزمة مشروع]
    SCAN --> AGD[اقتراح تحديث AGENTS.md]
    AGD -.تحميل مستمر عند بدء الجلسة.-> AGENT[العامل البرمجي]
    PEOPLE -.استعلام عبر مسار المجلد.-> AGENT
    SKILL[مهارات محلية داخل المستودع<br/>بما فيها write-like-me] -.تحميل تلقائي.-> AGENT
    CRON[تسجيل تلقائي يوميًا الساعة 09:00 و16:00] --> SCAN

سبب أهمية هذا التصميم أنه يتقاطع تمامًا مع فلسفة “Codex-maxxing” التي شرحها صاحب المستودع نفسه في مقال منفصل. الاتجاه هنا ليس إلحاق نموذج أفضل بالعامل، بل بناء بنية محيطة سميكة حتى لا يبدأ العامل من صفحة بيضاء في كل مرة.

التثبيت والتكامل

هذا المستودع قالب (template) كما يوحي اسمه. يُدمج بنسخه إلى حساب GitHub الخاص بالمستخدم، ثم بضبط عامل البرمجة (Codex أو واجهة سطر أوامر مشابهة) ليتخذ جذر المستودع دليل عمل له. نقطة الدخول الأساسية هي ملف AGENTS.md في جذر المستودع، حيث يقرأه العامل عند بدء الجلسة ليتعرف على بنية المجلدات، وسياق الأشخاص والمشاريع، وقائمة المهارات الواجب تحميلها.

نقطة التكامل المهمة هنا أن AGENTS.md ليس مجرد مستند، بل عقد يُحمَّل باستمرار. بما أن هذا الملف يوضع في مقدمة السياق في كل جلسة، فإن ما يُكتب فيه يحدد مباشرة السلوك الافتراضي للعامل. ولأن بنية المجلدات ثابتة، يصل العامل إلى الذاكرة بطريقة حتمية على شاكلة “إذا احتجت سياق الزميل A، فاقرأ people/A.md”. وبخلاف التقريب الاحتمالي للبحث المتجهي، يشير مسار الملف دائمًا إلى المكان نفسه.

يُدمج التسجيل التلقائي عبر ربط نص برمجي للتسجيل بجدولة (من نوع cron) ليعمل في وقت محدد يوميًا. هذا الجزء آلية تُبقي الذاكرة محدَّثة دون حاجة إلى استدعاء بشري في كل مرة، وهو أيضًا قرار تصميمي مهم من زاوية التكلفة. فبدلًا من الاستطلاع المستمر، هناك تنفيذان محدودان يوميًا فقط، فلا يُستهلك عدد رموز (tokens) هائل في حلقة لا نهائية.

كيف يعمل هذا التصميم فعليًا

هذا المستودع ليس أداة تعرض أرقام قياس أداء، بل نمط سير عمل، لذا نتناول هنا الأثر الفعلي للتصميم من الناحية البنيوية. لا يقدّم المستودع أرقام أداء قابلة لإعادة الإنتاج، وحتى صاحب المشروع نفسه يستند إلى تحسّن سير العمل اليومي لا إلى مؤشرات كمية. لذلك لن نختلق أرقامًا في هذا المقال، بل نتناول المزايا البنيوية فقط.

الأثر الأكبر هو إزالة تكلفة استعادة السياق. يمر الوصول عبر قاعدة بيانات متجهية بحساب تضمين وبحث تشابه في كل استعلام، بينما يقتصر الوصول عبر مسار المجلد على قراءة ملف واحد. حين يقول المستخدم “ذلك المشروع من المرة السابقة”، يقرأ العامل حزمة ذلك المشروع مباشرة، ويستعيد السياق الدقيق دون أخطاء إيجابية كاذبة يسببها البحث التقريبي. تصبح دقة الذاكرة رهينة جودة تصميم المجلدات لا جودة البحث.

الأثر الثاني هو إمكانية التدقيق. بما أن كل الذاكرة مخزَّنة كماركداون قابل للقراءة البشرية، يمكن للمطور فتحها والتحقق منها وتعديلها مباشرة ليعرف ما يعرفه العامل. من الصعب على الإنسان التحقق بصريًا من متجهات التضمين، لكن people/A.md مجرد ملف نصي. القدرة على تصحيح ذاكرة العامل فورًا حين تكون خاطئة تُحدث فرقًا كبيرًا في الممارسة العملية.

الأثر الثالث هو قابلية النقل. بما أن التصميم لا يرتبط بمزوّد قاعدة بيانات متجهية أو نموذج تضمين معيّن، فإن المستودع نفسه هو الذاكرة الكاملة. عند النقل إلى جهاز آخر أو عامل آخر، تعمل المجلدات والماركداون كما هي. هذا الاستقلال عن البنية التحتية يرتبط مباشرة بمنظور السيادة والحوسبة الداخلية (on-premise) الذي نتناوله لاحقًا.

دلالات التطبيق على منتجات ThakiCloud

يتقاطع هذا التصميم مع محورَي تشغيل العوامل في ThakiCloud كليهما.

من منظور Paxis يبدو التقاطع الأكثر مباشرة. Paxis هو مستوى تحكم السحابة الأصلية للعوامل (Agent-Native Cloud) في ThakiCloud، ويتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. النمط الذي يعرضه personal-monorepo-template، أي “مهارات محلية داخل المستودع + عقد محمَّل باستمرار (AGENTS.md)”، يتطابق تمامًا مع اتجاه تصميم حاضنة المهارات في Paxis. يختار Paxis بالفعل عددًا من المهارات عبر BM25 وينفّذها في بيئة معزولة (sandbox)، ونهج هذا المستودع يجيب بوضوح، عبر بنية المجلدات، على سؤال أسبق وهو “أي معرفة توضع باستمرار في سياق الجلسة”. وبشكل خاص، إبقاء الذاكرة كملفات قابلة للقراءة البشرية وجعل كل تحديث قابلًا للتدقيق ينسجم مع نفس فلسفة Paxis التي تُمرّر كل سلوك للعامل عبر بوابات السياسات وسجلات التدقيق. فكرة استخلاص قدرة العامل من البنية المحيطة لا من درجة النموذج نفسها تتطابق شكليًا مع تصميمنا الذي يتعامل مع المهارات كموارد من الدرجة الأولى.

من منظور ai-platform، تبرز زاوية عبء البنية التحتية بشكل لافت. منصة ai-platform في ThakiCloud بنية تحتية للذكاء الاصطناعي وتعلّم الآلة قائمة على K8s، وتخدم أحمال عمل عملاء الذكاء الاصطناعي السيادي والداخلي (on-premise). بالنسبة لهؤلاء العملاء، فإن بنية ذاكرة تتطلب تشغيل قاعدة بيانات متجهية باستمرار تعني سطحًا إضافيًا للبنية التحتية وتكلفة إدارة إضافية. في المقابل، الذاكرة المُمثَّلة بمجلدات وماركداون تعمل بنظام الملفات وحده دون مخزن حالة منفصل، ما يقلل عبء التشغيل كثيرًا في البيئات الخاضعة للتنظيم أو الشبكات المغلقة. زاوية “منح العامل استمرارية مع تقليل بنية الذاكرة التحتية إلى أدنى حد” يمكن أن تكون نقطة بيع فعلية للعملاء الذين يتطلبون ذكاءً اصطناعيًا سياديًا.

القيود والحجج المضادة

هذا التصميم ليس حلًا شاملًا. القيد الأوضح هو الحجم. الوصول عبر مسار المجلد قوي حين يعرف الإنسان أو العامل عنوان الذاكرة مسبقًا. لكن في المواقف التي يجب فيها البحث عن معلومة “لا يُعرف مكانها” بين عشرات الآلاف من المستندات، يظل البحث المتجهي الدلالي متفوقًا. يفترض هذا المستودع فضاء ذاكرة صغيرًا نسبيًا وواضح البنية، وهو أشخاص المستخدم ومشاريعه وخبراته الشخصية. عند التوسع إلى قاعدة معرفة ضخمة لفريق كامل بأسره، تظهر حدود بنية المجلدات وحدها.

الحجة المضادة الثانية هي خصوصية الفحص. إن فحص سلاك والبريد الإلكتروني والتقويم لإنشاء ملفات الأشخاص يعني أيضًا أن محادثات حساسة تُخزَّن كنص عادي في ماركداون. هذا مريح للاستخدام الشخصي، لكن تبنّيه في منظمة يتطلب حتمًا ضوابط وصول وسياسات احتفاظ. بقدر ما تُعد إمكانية التدقيق ميزة، فإنها تتحول إلى مخاطرة إن لم يوجد ضبط لمن يصل إلى تلك الملفات.

الثالثة هي موثوقية التحديث التلقائي. إذا كتب التسجيل التلقائي، الذي يعمل مرتين يوميًا، ملخصًا خاطئًا في ملف شخص، يستمر هذا الخطأ في الحقن في الجلسات اللاحقة. هذا هو السبب في أن المستودع يجعل التحديثات “اقتراحات” تفترض مراجعة بشرية. فالدفع نحو الأتمتة الكاملة قد يلوّث الذاكرة بصمت، لذا فإن إبقاء بوابة مراجعة بشرية أكثر أمانًا.

وأخيرًا، يُقدَّم هذا النهج كـ”بديل مجاني مقابل راتب مساعد بشري”، لكن الحفاظ فعليًا على سير عمل بهذا المستوى يتطلب قدرة هندسية معتبرة على تصميم بنية المستودع وصقلها ذاتيًا. مجانية الأداة وتكلفة تشغيله بكفاءة أمران مختلفان تمامًا.

ومع ذلك، فإن الرسالة الجوهرية التي يطرحها هذا المستودع واضحة. ذاكرة العامل لا يجب أن تكون بالضرورة بنية تحتية ثقيلة، ويمكن تحقيق استمرارية معتبرة ببنية مجلدات جيدة وعقد يُحمَّل باستمرار فقط. وهذا يشير بالضبط إلى الاتجاه نفسه الذي تسلكه ThakiCloud في تعاملها مع المهارات والمعرفة كموارد من الدرجة الأولى.

المصادر

• jxnl/personal-monorepo-template (GitHub)
• Codex-maxxing (jxnl.co)

جاء serve-sim، الذي طوره Evan Bacon من فريق نواة Expo، ليواجه هذا الحائط مباشرة. وقد ذاع صيت هذه الأداة فعلياً عندما قدّمها المطور المستقل levelsio قائلاً إنها “تتيح رؤية تطبيق iOS الذي بناه Claude Code على Mac Mini في السحابة مباشرة عبر المتصفح في الوقت الفعلي”. وشعار serve-sim بسيط: “أمر npx serve الخاص بمحاكيات آبل”.

نظرة عامة

ما يجعل serve-sim مثيراً للاهتمام هو أنه ليس مجرد أداة لعكس الشاشة. فهذه الأداة تفتح قناتين في آن واحد: الأولى هي تدفق فيديو يرسل شاشة المحاكي إلى المتصفح، والثانية قناة تحكم تتيح للمتصفح أو للوكيل التفاعل مع المحاكي. بعبارة أخرى، تجعل “المشاهدة” و”التحكم” ممكنتين عن بُعد في آن معاً.

أهمية هذا المزيج تكمن في أنه يُكمل حلقة التطوير الخاصة بوكلاء البرمجة بالذكاء الاصطناعي. يصبح بإمكان الوكيل تعديل الكود، وبناء المشروع، وتشغيله، ثم رؤية النتيجة على الشاشة، والضغط على الأزرار للانتقال إلى الخطوة التالية، وتكرار هذه الدورة الكاملة دون تدخل بشري. وهذا يتقاطع تماماً مع توجه Paxis، السحابة المخصصة للوكلاء (Agent-Native Cloud) لدى ThakiCloud، القائم على فكرة “أن ينفذ الوكيل عملاً فعلياً في بيئة معزولة”، مما يجعل من المفيد دراسة كيفية تنفيذ أداة مفتوحة المصدر واحدة لهذا النوع من سير العمل.

تصوير لبنية تحوّل شاشة المحاكي على خادم بدون واجهة رسومية إلى تدفق يصل إلى متصفح بعيد.

ما هو serve-sim

آلية عمل serve-sim أبسط وأذكى مما قد يبدو للوهلة الأولى. لا حاجة لتثبيت إضافة (plugin) خاصة في Xcode ولا لزرع كود قياس داخل التطبيق. بدلاً من ذلك، يشغّل serve-sim عملية مساعدة صغيرة مكتوبة بلغة Swift تلتقط الإطارات المرئية لمحاكي iOS المُقلع مسبقاً عبر واجهة simctl io التي توفرها آبل.

تُعرض الشاشة الملتقطة عبر مسارين. أولاً، تدفق MJPEG يرسل فيديو إلى المتصفح بمعدل يصل إلى 60 إطاراً في الثانية. ثانياً، تُفتح قناة تحكم عبر WebSocket تتيح للمتصفح إرسال مدخلات مثل النقر والإيماءات إلى المحاكي. وفوق ذلك، تُركّب واجهة معاينة مبنية بـ React تتيح للمستخدم التفاعل مع التطبيق في المتصفح وكأنه جهاز فعلي.

flowchart TB
    A[محاكي iOS مُقلَع] --> B[عملية مساعدة بلغة Swift]
    B --> C[التقاط الإطارات المرئية<br/>عبر simctl io]
    C --> D[تدفق فيديو MJPEG<br/>حتى 60 FPS]
    C --> E[قناة تحكم عبر WebSocket]
    D --> F[واجهة معاينة React في المتصفح]
    E --> F
    E --> G[سطر أوامر الوكيل<br/>نقر، إيماءات، دوران، كاميرا]
    F -.تحكم بشري.-> E
    G -.تحكم الوكيل.-> E

الجوهر هنا هو أن الأداة تعمل مع “أي محاكي مُقلَع” أياً كان. لا حاجة لتعديل التطبيق، فيمكن ربطها مباشرة بمشروع قائم بالفعل. كذلك، تنقل الأداة سجلات المحاكي إلى المتصفح، مما يتيح لأدوات MCP من فئة browser-use قراءة تلك السجلات لتقييم الحالة. وتوجد أيضاً ميزة عملية تتيح إفلات ملفات فيديو أو صور في نافذة المتصفح لتُضاف كملفات إلى جهاز المحاكي.

التثبيت والاستخدام

عتبة الدخول إلى serve-sim منخفضة. يكفي سطر واحد على جهاز Mac يحتوي على Node.js.

npx serve-sim

بعد التشغيل، يمكن مشاهدة المعاينة محلياً على http://localhost:3200. تدعم الأداة ثلاثة أنماط استخدام: محلياً، أو عبر الشبكة المحلية (LAN) من جهاز آخر على نفس الشبكة، أو على جهاز Mac بعيد مع نفق (tunnel) يتيح الوصول من أي مكان. حالة levelsio هي النمط الثالث تحديداً، حيث يعمل serve-sim على Mac Mini سحابي بدون واجهة رسومية بينما تجري المشاهدة عبر متصفح بعيد.

يُقدَّم دمج الوكلاء عبر مهارة وكيل (Agent Skill) منفصلة. هذه المهارة، الموجودة في skills/serve-sim ضمن المستودع، تعلّم Claude Code وCursor وCodex CLI وGemini CLI وأي مضيف آخر يطبّق معيار Agent Skills المفتوح كيفية التحكم في المحاكي عبر سطر الأوامر. وتشمل هذه القدرات النقر والإيماءات وأزرار الأجهزة الفعلية ودوران الشاشة وحقن مدخلات الكاميرا، إضافة إلى تمرير التدفق إلى نافذة المعاينة الخاصة بالمضيف.

ملاحظة حول إعادة الإنتاج

بيئة التنفيذ التي كُتب فيها هذا المقال هي جلسة معالجة دفعية بدون واجهة رسومية، حيث تشغيل Node.js محظور بموجب السياسة المتبعة، لذا لم يتسنَّ تشغيل npx serve-sim مباشرة والتقاط الشاشة فعلياً. وعليه، فإن الأوامر ووصف السلوك في هذا المقال مستندة إلى ما ورد في ملف README الخاص بالمستودع والمواد التعريفية الرسمية، دون اختلاق أي أرقام قياس أداء. يُنصح بالتحقق من مشهد بث المحاكي الفعلي وزمن الاستجابة الحقيقي عبر تشغيل الأمر أعلاه مباشرة في بيئة macOS مع محاكي Xcode مُقلَع.

دلالات على منتجات ThakiCloud

يبدو serve-sim للوهلة الأولى أداة موجهة لمطوري iOS، لكن خلفها يكمن تيار أوسع هو التطوير المصمم أصلاً للوكلاء (agent-native development).

عدسة Paxis (التطوير المصمم للوكلاء). Paxis من ThakiCloud هي مستوى تحكم لسحابة مخصصة للوكلاء يشغّل المهارات في صناديق رملية معزولة ويمرر كل سلوك عبر بوابات سياسات وسجلات تدقيق. ومعيار Agent Skills المفتوح الذي يعتمده serve-sim هو نفس نموذج العقد الذي تتعامل معه بنية مهارات Paxis. فكرة أن تقدّم مهارة واحدة قدرة “النقر على المحاكي وتدويره وقراءة شاشته” لعدة مضيفي وكلاء مختلفين تسير في نفس اتجاه بنية Paxis التي تختار أكثر من 960 مهارة عبر خوارزمية BM25 وتنفذها في عزل. وبشكل خاص، فإن أعباء العمل التي يتحكم فيها الوكيل فعلياً في واجهة مستخدم حقيقية، كما في قناة التحكم لدى serve-sim، لا يمكن رفعها بأمان إلى بيئة الإنتاج إلا إذا مرّ ذلك التحكم عبر بوابة سياسات وسُجّل في سجل تدقيق. إذا كان serve-sim يقدّم “القدرة”، فإن Paxis تقدّم طبقة “الضبط الآمن” لتلك القدرة.

عدسة ai-platform (بنية التنفيذ بدون واجهة رسومية). تكمن الجاذبية الحقيقية لـ serve-sim في عمله على جهاز Mac بعيد بدون واجهة رسومية. وفكرة البناء والبث على خادم بدون واجهة رسومية تشبه فلسفياً الطريقة التي تجدول بها منصة ai-platform من ThakiCloud أعباء العمل وتنفذها على Kubernetes دون الحاجة إلى واجهة رسومية. وأي خط أنابيب (pipeline) يُلحق فيه مشغّل macOS المطلوب لبناء تطبيقات iOS عند الطلب، يبني الوكيل عليه ويختبر تلقائياً، ثم يُبث النتيجة فقط إلى المستخدم البشري، يمكن أن يمتد إلى ما هو أبعد من التكامل المستمر (CI) نحو “ضمان جودة يقوده الوكيل”. وهذه بنية تجعل فيها البنية التحتية للتنفيذ بدون واجهة رسومية منخفضة التكلفة (ai-platform) ركيزة تدعم جدوى أتمتة الوكلاء اقتصادياً (Paxis).

القيود والحجج المضادة

هناك عدة نقاط ينبغي تناولها بموضوعية.

أولاً، يستهدف serve-sim المحاكي وليس الجهاز الفعلي. وبما أنه محاكٍ لا جهاز مادي حقيقي، تبقى المشكلات التي تظهر فقط على الأجهزة الفعلية، كالكاميرا والحساسات وخصائص الأداء، خارج نطاق الاكتشاف. ويبقى القيد القديم قائماً: نجاح الاختبار على المحاكي لا يضمن نجاحه على الجهاز الفعلي.

ثانياً، بث MJPEG بسيط ومتوافق على نطاق واسع، لكن كفاءة ضغطه ليست عالية. فبث فيديو عالي الجودة بمعدل 60 إطاراً في الثانية باستمرار عبر نفق بعيد قد يجعل عرض النطاق الترددي وزمن الاستجابة عنق زجاجة. وفي اختبارات الإيماءات التي تتطلب سرعة استجابة، ينعكس زمن الرحلة عبر الشبكة مباشرة كتأخير في التحكم.

ثالثاً، إتاحة “الرؤية والتحكم” للوكيل شيء، ودقة قراره شيء آخر تماماً. يظل احتمال أن يُسيء الوكيل تفسير التدفق ويضغط على زر خاطئ قائماً، وهذه بالتحديد هي النقطة التي تحتاج إلى بوابة سياسات ومراجعة بشرية. فكلما فتحت الأداة مزيداً من القدرات، ازدادت أهمية الطبقة التي تضبط تلك القدرات.

مع ذلك، فإن اتجاه serve-sim واضح. لقد أرسى جسراً عملياً حقيقياً للانتقال من “مرحلة يكتفي فيها الوكيل بكتابة الكود” إلى “مرحلة يبني فيها الوكيل ويشغّل ويتحكم مباشرة في الشاشة للتحقق”. وأي فريق يريد تطوير تطبيقات جوّال بواسطة وكلاء ذكاء اصطناعي على سحابة بدون واجهة رسومية يمكنه فتح هذا العالم فوراً بسطر واحد هو npx serve-sim.

المصادر

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio، تغريدة تعريفية بـ serve-sim. https://x.com/levelsio/status/2075328941317886210

نظرة عامة

إذا سبق لك تشغيل نموذج لغوي كبير محليا، فمن المرجح أنك رأيت تسميات مثل Q4_K_M وQ5_K_M وQ8_0. يتوقف معظم الناس عند فهم مفاده أن “Q4 يعني 4 بت، إذن لا بد أنه الأصغر والأسرع”، ثم يقومون بتحميل الملف وتشغيله مباشرة. لكن هذه التسمية تخفي أكثر مما تظهر. قلة قليلة من الناس فتحوا فعليا ملفا موسوما بـ Q4_K_M وتحققوا، مصفوفة تلو الأخرى، مما إذا كان ممتلئا حقا ببيانات ذات 4 بت.

هذا المقال موجه لقادة الهندسة، والممارسين المسؤولين عن تكلفة الاستدلال، والفرق التي تسعى لتقديم النماذج محليا (on-premises). قمنا بتحميل ملف GGUF لنموذج Qwen2.5-0.5B-Instruct على عدة مستويات تكميم، وقسنا أحجام الملفات الفعلية، وقمنا بتشريح ملف واحد من نوع Q4_K_M بشكل كامل مصفوفة تلو الأخرى. جاءت النتيجة مختلفة تماما عن الحدس. نوضح لماذا يهم فهم هذه الفجوة لتكلفة الخدمة وجودتها، وماذا يعني ذلك بالنسبة لبنية الاستدلال التحتية لدى ThakiCloud.

ولنذكر الخلاصة أولا: في ملف Q4_K_M الخاص بهذا النموذج، لم تشكل المصفوفات التي هي فعلا تكميم K رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان، وكان عرض البت الفعلي للملف ليس 4 بل 6.16 بت. أي أن التسمية كانت أقرب إلى كذبة تقريبا.

ما هي هذه التقنية

GGUF هو صيغة نموذج أحادية الملف تستخدم في منظومة llama.cpp. يجمع ملف واحد بين البيانات الوصفية (البنية المعمارية، أداة تجزئة الرموز، المعاملات الفائقة) وأوزان جميع المصفوفات المكممة معا. النقطة الجوهرية هي أن كل مصفوفة يمكن أن تستخدم نوع تكميم مختلفا. لذلك فإن تسمية على مستوى الملف مثل Q4_K_M لا تشير إلا إلى “النوع السائد”، وليس إلى أن الملف بأكمله من ذلك النوع.

تنقسم أنواع التكميم في llama.cpp إلى فئتين رئيسيتين. الأولى هي الفئة القديمة (legacy) (Q4_0، Q5_0، Q8_0) التي تجمع 32 وزنا في كتلة واحدة. والثانية هي فئة تكميم K (Q4_K، Q5_K، Q6_K) التي تجمع 256 وزنا في كتلة فائقة واحدة (superblock). ولأن تكميم K يقسم المقياس (scale) والحد الأدنى داخل الكتلة الفائقة بشكل أدق، فإنه يقدم جودة أفضل من الفئة القديمة عند نفس عرض البت. الحرف K في Q4_K_M يشير إلى تكميم K هذا، بينما M يعني الإعداد المسبق “المتوسط” الذي يرفع بعض المصفوفات الحساسة إلى دقة أعلى (Q6_K).

بالنظر عن قرب إلى بنية الكتلة الفائقة، يتضح سبب كفاءة تكميم K الأعلى. على سبيل المثال، يخزن Q4_K 256 وزنا في 144 بايت. من ذلك، تشغل القيم النقية ذات 4 بت مساحة 256 × 4 بت = 128 بايت، أما البايتات الـ16 المتبقية فهي بيانات وصفية تقسم الكتلة الفائقة إلى 8 كتل فرعية وتعيد تكميم مقياس كل منها وحدها الأدنى بـ6 بت. بعبارة أخرى، القيم نفسها ذات 4 بت، لكن الاحتفاظ بمقاييس دقيقة لإعادة بنائها يقلل من الخطأ. وهذا يتباين مع Q4_0 القديم الذي يحتفظ بمقياس واحد فقط لكل 32 وزنا. لذا فإن عرض البت الفعلي لـ Q4_K هو 144 × 8 ÷ 256 = 4.5 بت، أكبر قليلا من 4 بت النقية، لكن الجودة أكثر استقرارا بكثير.

هناك قيد حاسم واحد هنا. لا يمكن استخدام تكميم K إلا عندما يكون عدد أعمدة المصفوفة (ne[0] بمصطلحات ggml) قابلا للقسمة على 256. والسبب أن الكتلة الفائقة تعمل بوحدات من 256. وإذا لم يتحقق هذا الشرط، فإن llama.cpp يعود بصمت إلى الفئة القديمة (غالبا Q5_0). هذه القاعدة الواحدة تفسر نتيجة تجربة اليوم بأكملها.

flowchart TB
    A["ملف GGUF (Q4_K_M)"] --> B["تحديد النوع لكل مصفوفة<br/>llama_tensor_get_type()"]
    B --> C{"هل عدد الأعمدة ne[0]<br/>قابل للقسمة على 256؟"}
    C -->|"نعم"| D["استخدام تكميم K<br/>Q4_K / Q6_K (كتلة فائقة 256)"]
    C -->|"لا"| E["العودة إلى الفئة القديمة<br/>Q5_0 (كتلة 32)"]
    B --> F["رفع الدقة للمصفوفات الحساسة"]
    F --> G["output.weight -> Q8_0<br/>attn_v.weight -> Q8_0<br/>ffn_down.weight -> Q6_K"]
    D --> H["تجميع عرض البت الفعلي"]
    E --> H
    G --> H
    H --> I["عرض البت الفعلي لكامل الملف = 6.16<br/>(التسمية 'Q4' = 4.0)"]

الإعداد والتكامل

يمكن إعادة إنتاج التجربة دون أي تبعيات إضافية. تعيد واجهة برمجة تطبيقات Hugging Face عدد البايتات الفعلي لحجم الملف، ويمكن قراءة أنواع المصفوفات مباشرة باستخدام قارئ gguf.

# 1) تثبيت أداة القراءة والتحميل
pip install gguf huggingface_hub

# 2) تحميل ملف واحد فقط من نوع Q4_K_M (أقل من 500 ميجابايت لأنه نموذج 0.5B)
hf download Qwen/Qwen2.5-0.5B-Instruct-GGUF \
  qwen2.5-0.5b-instruct-q4_k_m.gguf --local-dir ./gguf

فيما يلي الشيفرة الخاصة بفتح أنواع مصفوفات الملف المحمل. يحتوي رأس (header) ملف GGUF على اسم كل مصفوفة وأبعادها ورقم نوع ggml مباشرة، لذا فإن مجرد تجميع هذه القيم يكشف بالضبط ما الذي يملأ الملف فعليا.

from collections import Counter
from gguf import GGUFReader

r = GGUFReader("gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf")
hist = Counter()
for t in r.tensors:
    hist[t.tensor_type.name] += 1
    # التحقق من النوع الفعلي لبعض المصفوفات التمثيلية
    if t.name in ("token_embd.weight", "output.weight",
                  "blk.0.attn_v.weight", "blk.0.ffn_down.weight",
                  "blk.0.attn_q.weight"):
        print(f"{t.name:26s} {t.shape} -> {t.tensor_type.name}")
print(dict(hist))

عدد البايتات لكل كتلة يأتي مباشرة من تعريفات ggml. فمثلا، يخزن Q4_K 256 وزنا في 144 بايت أي 4.5 بت لكل وزن، ويخزن Q6_K 256 وزنا في 210 بايت أي 6.5625 بت لكل وزن، بينما يخزن Q5_0 القديم 32 وزنا في 22 بايت أي 5.5 بت لكل وزن. وبجمع (عدد العناصر ÷ حجم الكتلة) × بايتات الكتلة لكل مصفوفة، يمكن حساب عرض البت الفعلي للملف بدقة.

نتائج التجربة الفعلية

أولا، أحجام الملفات. هذه هي القيم المقاسة فعليا لنفس النموذج بعد تحميله على 7 مستويات تكميم، مقارنة بالأصل بصيغة fp16 (1266 ميجابايت).

هناك ما يثير الغرابة بالفعل هنا. الفرق بين Q2_K (415 ميجابايت) و Q4_0 (429 ميجابايت) هو 14 ميجابايت فقط. خفضنا عدد البتات إلى النصف، لكن حجم الملف لم ينخفض تقريبا. بل إن Q4_K_M (491 ميجابايت) أكبر فعليا من Q4_0 (429 ميجابايت) ذي 4 بت النقية. بالنظر إلى الأسماء وحدها، هذه النتيجة غير مفهومة.

يتضح السبب الحقيقي عند فتح ملف Q4_K_M مصفوفة تلو الأخرى. فيما يلي توزيع الأنواع عبر 291 مصفوفة فيه.

على الرغم من تسمية Q4_K_M، لم يشكل تكميم K الحقيقي رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان. وبدلا من ذلك، استحوذ النوع القديم Q5_0 ذو 5.5 بت على أكثر من النصف (54.9 بالمئة)، واستهلك Q8_0 ذو 8.5 بت نسبة 30 بالمئة. وعند حساب عرض البت الفعلي لكامل الملف، نحصل على 6.16 بت، أي أكثر من 1.5 ضعف الـ4 بت التي توحي بها التسمية.

بالتحقق من المصفوفات التمثيلية واحدة تلو الأخرى، يتضح النمط بجلاء. كانت الأنواع المقاسة فعليا كما يلي:

• token_embd.weight (896 × 151936) -> Q5_0
• output.weight (896 × 151936) -> Q8_0
• blk.0.ffn_down.weight (4864 × 896) -> Q6_K
• blk.0.attn_v.weight (896 × 128) -> Q8_0
• blk.0.attn_q.weight (896 × 896) -> Q5_0

هل تلاحظ النمط؟ لم تظهر المصفوفات التي تحمل تكميم K (Q4_K، Q6_K) إلا حيث كان عدد الأعمدة ne[0] يساوي 4864، كما في ffn_down. والرقم 4864 قابل للقسمة على 256 (19 × 256). أما معظم المصفوفات الأخرى فعدد أعمدتها ne[0] يساوي 896، والرقم 896 غير قابل للقسمة على 256 (3.5 × 256). لذلك لم تتمكن هذه المصفوفات من استخدام تكميم K إطلاقا وعادت جميعها إلى الفئة القديمة Q5_0. وإذا أضفنا إلى ذلك رفع الدقة (Q5_0، Q8_0) للمصفوفات الحساسة للجودة مثل التضمين (embedding) والمخرجات وقيمة الانتباه (attention value)، نحصل على ملف موسوم بـ Q4_K_M لكن جوهره الفعلي كتل تتراوح بين 5.5 و8.5 بت.

هذا بالضبط مصدر عرض البت الفعلي البالغ 6.16. يحتوي هذا الملف على ما مجموعه 630 مليون وزن خاضع للتكميم، مخزنة في نحو 485 ميجابايت من البايتات. 485,452,288 بايت × 8 ÷ 630,167,424 وزنا = 6.16 بت لكل وزن. وبإضافة نحو 6 ميجابايت من البيانات الوصفية للملف وحشو المحاذاة (alignment padding)، تتطابق النتيجة تماما مع حجم الملف الفعلي البالغ 491 ميجابايت. وتطابق الحساب مع حجم الملف هو أيضا دليل على دقة قراءة أنواع المصفوفات.

هذا يفسر أيضا النقطتين الغريبتين في جدول أحجام الملفات. السبب في أن Q2_K (415 ميجابايت) أصغر بالكاد من Q4_0 (429 ميجابايت) هو أن مصفوفات التضمين والمخرجات في هذا النموذج الصغير تشكل حصة كبيرة من إجمالي الأوزان، وهي تبقى بدقة عالية عند أي مستوى تكميم. مهما خفضت عدد البتات، تبقى تكلفة ثابتة في القاع لا تنخفض. أما سبب كون Q4_K_M أكبر من Q4_0 النقي ذي 4 بت، فهو أن الإعداد المسبق M دفع ثمن رفع المصفوفات الحساسة إلى Q6_K وQ8_0 على شكل زيادة في حجم الملف. رقم التسمية أقل، لكن عرض البت الفعلي أعلى في الواقع.

وباختصار، أظهرت هذه التجربة من خلال القياس ثلاث حقائق. أولا، تشير التسمية على مستوى الملف إلى النوع السائد فقط ولا تضمن عرض البت الفعلي. ثانيا، في النماذج الصغيرة التي لا يكون فيها الحجم المخفي (hidden size) من مضاعفات 256، يتعطل تكميم K إلى حد كبير، مما يوسع الفجوة بين التسمية والجوهر. ثالثا، تشكل مصفوفات التضمين والمخرجات في النماذج الصغيرة حصة كبيرة من إجمالي السعة، وبمجرد الاحتفاظ بها بدقة عالية، تتضاءل بشكل كبير وفورات “التكميم الرباعي البت” المفترضة.

الدلالات على منتجات ThakiCloud

اقتصرت هذه التجربة على تشريح نموذج صغير واحد، لكن دروسها تنتقل مباشرة إلى بنية الخدمة الإنتاجية التحتية. تقدم منصة ai-platform التابعة لـ ThakiCloud النماذج لبيئات عملاء متنوعة فوق Kubernetes وجدولة موارد GPU القائمة على Kueue. وفي هذا السياق، فإن “أي تكميم نختار” ليس مسألة ذوق، بل قرار يحدد تخصيص ذاكرة GPU، وحجم الدُفعة (batch)، وفي النهاية التكلفة لكل رمز (token).

الثقة بالتسمية كما هي تخل بتخطيط السعة. إذا افترضت أن Q4_K_M يعني “4 بت، إذن ربع الحجم الأصلي” وخصصت ذاكرة GPU على هذا الأساس، فستجد، كما في التجربة أعلاه، أنه يستهلك فعليا نحو 40 بالمئة من الأصل، وتنفد فتحات الدُفعات أسرع مما هو متوقع. يهم هذا الأمر بشكل خاص في الخدمة متعددة المستأجرين (multi-tenant)، حيث يجب حشر العديد من النماذج الصغيرة بكثافة على عقدة واحدة. وهناك، فإن الفرق بين قياس عرض البت الفعلي فعليا والاكتفاء بالثقة بالتسمية ينعكس مباشرة على عدد النماذج التي يمكن للعقدة استيعابها. لهذا السبب بالتحديد نتحقق من ملفات GGUF مصفوفة تلو الأخرى عند بناء صور الخدمة (serving images). وبالنسبة للعملاء الذين يتطلبون استضافة ذاتية أو نشرا محليا أو سياديا على وجه الخصوص، تتحول عادة القياس هذه بدلا من الافتراض إلى ميزة تنافسية حقيقية من حيث التكلفة.

جعل هذا التحقق نفسه مهمة قابلة للتكرار هو دور Paxis. وPaxis هي منصة التحكم الخاصة بـ ThakiCloud للسحابة الأصلية للوكلاء (Agent-Native Cloud) التي تعمل فوق ai-platform، وتتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. فإذا تم تسجيل تجربة اليوم، أي تحميل ملف GGUF وتجميع أنواع المصفوفات وإطلاق تحذير عند تجاوز عرض البت الفعلي حدا معينا، كمهارة واحدة، فإنها تعمل في بيئة معزولة (sandbox) وتمر جميع النتائج عبر بوابات السياسات وسجلات التدقيق. وبدلا من أن يفتح شخص الملف يدويا في كل مرة يصل فيها نموذج جديد إلى السجل، يعمل هيكل معتمد (validated skeleton) تلقائيا. هكذا يترابط الاقتصاد الذي تخلقه الخدمة منخفضة التكلفة (ai-platform) مع التنسيق (Paxis) الذي يجعل تلك الخدمة قابلة للتكرار بأمان.

القيود والحجج المضادة

هناك بعض النقاط التي يجب توضيحها بشكل صريح.

أولا، هذه النتائج تقترب من حالة قصوى خاصة بنموذج Qwen2.5-0.5B الذي يبلغ حجمه المخفي 896. أما في النماذج الأكبر التي يكون فيها الحجم المخفي من مضاعفات 256 (مثل 4096 أو 8192)، فإن تكميم K يُطبق بشكل طبيعي، ويقترب عرض البت الفعلي لـ Q4_K_M كثيرا من التسمية، عند نحو 4.8 بت.

بعبارة أخرى، الدرس الصحيح ليس أن “التسمية كذبة دائما”، بل أن “الفجوة بين التسمية والجوهر تختلف بشكل كبير حسب بنية النموذج، وتكون أكبر كلما كان النموذج أصغر”.

ثانيا، ليس بالضرورة أن يكون حجم الملف الكبير أمرا سيئا. فالاحتفاظ بمصفوفات التضمين والمخرجات بدقة عالية هو خيار متعمد لمنع انهيار الجودة في النماذج الصغيرة. بعبارة أخرى، ملف Q4_K_M هذا ليس ملفا “سيء الصنع”، بل هو نتيجة منطقية لرفع الدقة تلقائيا للحفاظ على الجودة في نموذج صغير. غير أن هذا الثمن لا يظهر في التسمية.

ثالثا، اقتصر هذا المقال على قياس بنية الملف وسعته، ولم يقس جودة الاستدلال الفعلية (الحيرة اللغوية perplexity، أو نتائج المعايير القياسية). وتتطلب العلاقة بين عرض البت والجودة تجربة منفصلة، نتركها موضوعا لمقال قادم. وما يمكن قوله هنا هو مبدأ تشغيلي واحد فقط: لا تخطط للسعة والذاكرة استنادا إلى التسمية، بل قسها فعليا.

الفرق بين الاكتفاء بالضغط على زر تشغيل نموذج محلي ومعرفة ما بداخل الملف فعليا يكمن بالضبط في عادة القياس هذه. خمس دقائق تقضيها في التحقق من الأرقام وراء التسمية يمكن أن تغير دقة خطة تكلفة الخدمة بأكملها.

المصادر

• مستودع نموذج Qwen2.5-0.5B-Instruct-GGUF: huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
• وثائق التكميم في llama.cpp: github.com/ggml-org/llama.cpp
• تم قياس أحجام الملفات وتوزيعات أنواع المصفوفات وعروض البت الفعلية مباشرة من ملفات فعلية تم تحميلها من المستودع أعلاه.

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

كل من شغّل وكيلاً حوارياً لفترة طويلة رأى هذا الفشل من قبل. تفضيل أو قرار أعلنه المستخدم بوضوح قبل أيام ينساه الوكيل في لحظة ما، ويتصرف على عكسه. نافذة السياق محدودة، وعندما تطول المحادثة بما يكفي، يجب ضغط جزء من الماضي أو التخلص منه. السؤال الحقيقي هو: ماذا نتخلص منه؟

أجابت ذاكرة الوكلاء حتى الآن على هذا السؤال في الغالب بمعايير وصفية: هل هذا مرتبط بالموضوع؟ هل هو بارز؟ هل يُلخَّص بشكل جيد؟ تجادل هذه الورقة، “Remember the Decision, Not the Description” (arXiv 2605.10870)، التي شارك في تأليفها باحث من Meta AI، بأن هذا المعيار نفسه خاطئ. هذا المقال موجّه للمهندسين والباحثين الذين يصممون وكلاء الذكاء الاصطناعي، وللفرق التي تحتاج إلى وضع ذاكرة طويلة المدى في الإنتاج. نلخّص هنا إعادة الصياغة الجوهرية للورقة والنتائج التجريبية الداعمة لها، ونستعرض كيف ينطبق هذا المبدأ على Paxis، منصة الوكلاء لدى ThakiCloud.

أين تكمن المشكلة

ينطلق المؤلفون من رؤية بسيطة. الذاكرة قيّمة للوكيل ليس لأنها تصف الماضي بأمانة، بل لأنها تحافظ على الفصل بين تاريخَين يتطلبان سلوكَين مختلفَين حتى ضمن ميزانية ثابتة.

لنأخذ مثالاً بسيطاً. قال المستخدم بالأمس: “يجب ألا يتم هذا النشر إلا بعد موافقة يدوية”. واليوم، في سياق مشابه، قال: “يمكن تشغيل هذا السكربت تلقائياً”. العبارتان متشابهتان جداً في ظاهرهما. تتقاطعان في كلمات مثل النشر والتنفيذ والموافقة، وعند تلخيصهما تصبحان تقريباً نفس الجملة. من السهل أن تدمج الذاكرة القائمة على الصلة هاتين الحالتين في كتلة واحدة توصف بـ”تعليمات متعلقة بالنشر”. في تلك اللحظة يفقد الوكيل القدرة على تمييز أي تعليمة تنطبق على أي موقف، ويرتكب خطأ دفع نشر يتطلب موافقة يدوية بشكل تلقائي. الملخّص صحيح وصفياً، لكن الدمج قاتل من حيث القرار.

نمط الفشل الملموس هو كالتالي. موقفان يبدوان متشابهَين نصياً لكنهما في الواقع يتطلبان إجراءَين متعارضَين. عندما تكون ميزانية الذاكرة ضيقة، يصبح الضغط ضرورياً، والضغط يستدعي حتماً الدمج. إذا نظرنا فقط إلى التشابه الوصفي، سيُدمج هذان الموقفان في واحد. والنتيجة أن الوكيل يتخذ قراراً خاطئاً باستمرار كلما وصل إلى تلك الحالة. الصلة أو جودة التلخيص لا تجيبان عن السؤال الحقيقي، وهو: هل يمكن دمج هذين حقاً؟ المعيار يجب ألا يكون ما يبدو متشابهاً، بل ما يتطلب سلوكاً مختلفاً.

الفكرة الجوهرية: rate-distortion محوره القرار

ينقل المؤلفون هذه المشكلة إلى إطار نظرية المعلومات الخاص بـ rate-distortion. تتناول نظرية rate-distortion أصلاً مقدار التشويه (distortion) الناتج عن قدر معين من الضغط (rate)، والخطوة المحورية هنا هي إعادة تعريف التشويه نفسه. بدلاً من أن يكون التشويه خطأ إعادة بناء الإشارة، يُعرَّف كـ الخسارة في جودة القرار القابلة للتحقيق نتيجة الضغط (decision loss).

flowchart TB
    A["تاريخ تفاعل طويل<br/>(ميزانية ذاكرة ثابتة)"] --> B{"هل ندمج الموقفين؟"}
    B --> C["معيار محوره الوصف<br/>الصلة، البروز، جودة التلخيص"]
    B --> D["معيار محوره القرار<br/>هل تسبب الحالة المشتركة تعارضاً في القرار"]
    C --> E["الدمج إذا بدا الموقفان متشابهَين<br/>-> دمج سلوكَين متعارضَين في واحد"]
    E --> F["أخطاء قرار مستمرة"]
    D --> G["الفصل فقط عند إثبات تعارض القرار<br/>certified refinement"]
    G --> H["حدّ نسيان دقيق (exact forgetting boundary)<br/>+ حدود memory-distortion frontier"]
    H --> I["جودة قرار أفضل عند نفس الميزانية"]

إليكم تشبيهاً. عند ضغط الصوت، نتخلص أولاً من الترددات التي لا تسمعها الأذن البشرية، لأن معيار التشويه هو “ما يسمعه الإنسان”. يرى المؤلفون أن ذاكرة الوكلاء يجب أن تعمل بالطريقة نفسها. ما يجب التخلص منه ليس “الذكرى التي تبدو أقل صلة”، بل “الذكرى التي لن يتغير أي قرار مستقبلي لو حذفناها”. هنا، rate هو ميزانية الذاكرة، وdistortion هو خسارة القرار التي يسببها هذا الضغط. إذا لم يؤدِّ دمج موقفَين في نفس الخانة إلى أي قرار خاطئ مستقبلاً، فإن هذا الدمج مجاني. وعلى العكس، إذا كان الدمج يطمس سلوكَين متعارضَين، فهو تشويه باهظ الثمن.

يترتب على هذا التعريف أمران. أولاً، حد النسيان الدقيق (exact forgetting boundary)، الذي يحدد بدقة حدود ما يمكن نسيانه بأمان دون الإضرار بجودة القرار. ثانياً، حدود memory-distortion frontier، التي تصف منحنى المفاضلة الأمثل بين ميزانية الذاكرة وجودة القرار. بعبارة أخرى، تضع الورقة نظرياً حداً أدنى مفاده: “إذا خفّضت الميزانية بهذا القدر، فستنخفض جودة القرار حتماً بمقدار لا يقل عن كذا”.

DeMem: تحويل النظرية إلى خوارزمية

DeMem هي التي تنقل هذه النظرية إلى ذاكرة وكيل فعلية قائمة على الخانات (slots). DeMem خوارزمية تعلّم ذاكرة عبر الإنترنت (online)، وتعمل وفق مبدأ واحد: لا تُقسِّم قسمة الذاكرة (partition) إلا عندما تُثبت البيانات (certify) أن حالة مشتركة تسبب تعارضاً في القرار.

كلمة “تُثبت” هنا مهمة. لا يُفصل الموقفان بمجرد أن يبدوا مختلفَين، بل يُفصلان فقط بعد أن تتراكم أدلة فعلية على أن نفس حالة الذاكرة تتطلب قرارَين مختلفَين. وعلى العكس، إذا لم تتوفر مثل هذه الأدلة، يُبقى على الدمج توفيراً للميزانية. هذا التحفظ هو جوهر الطريقة. الفصل المتسرع يهدر الميزانية ولا يترك مكاناً للتمييزات المهمة فعلاً، بينما الدمج المتسرع يطمس سلوكيات متعارضة. certified refinement هو الانضباط الذي ينتظر، بين هذين الحدين، حتى تتحدث البيانات. يثبت المؤلفون أن هذا الإجراء يحقق ضماناً من نوع near-minimax regret، أي أن الندم (regret) بالمقارنة مع الأمثل يظل، حتى في أسوأ الحالات، مقيداً قريباً من الحد النظري.

يتحقق المؤلفون من هذه الآلية على مستويَين. أولاً، في بيئة تشخيصية اصطناعية، يصممون مهاماً يتعمدون فيها جعل التشابه الوصفي والتشابه القراري متباعدَين. هنا، تستمر المعايير الوصفية فقط في دمج المواقف المتشابهة ظاهرياً، مما يراكم الندم، بينما يتجنب DeMem هذا الفخ بالفصل فقط عند إثبات تعارض القرار. بعد ذلك، يتحققون مما إذا كانت هذه الأفضلية تنتقل إلى معايير قياس محادثات طويلة المدى فعلية، عبر نماذج تجارية ونماذج مفتوحة الأوزان على حد سواء. هذا البناء الذي ينطلق من النظرية، ويمر عبر تحقق آلي مضبوط، وينتهي عند معايير قياس واقعية، يحوّل النتائج إلى تفسير لـ”لماذا يفوز”، لا مجرد جدول أداء.

نتائج التجارب

في التشخيص الاصطناعي، سجّل DeMem أدنى ندم تراكمي (cumulative regret) بين جميع الأساليب المتساوية في الميزانية، واتسعت الأفضلية كلما زادت الفجوة بين التشابه الوصفي والتشابه القراري. بينما استمرت المعايير الوصفية فقط في دمج المواقف المتعارضة منتجةً أخطاء مستمرة، تجنّب DeMem ذلك بالفصل فقط عند إثبات تعارض القرار.

استمرت النتائج في معايير القياس الفعلية أيضاً. فيما يلي القيم المقاسة للدرجة الإجمالية على LoCoMo (بنموذج GPT-4.1-mini الأساسي).

حقق DeMem أفضل درجة إجمالية، وكان قوياً بشكل خاص في فئات Temporal وOpen-Domain وMulti-Hop، حيث يكون الحفاظ على التمييز بين تفاعلات بعيدة زمنياً أمراً حاسماً. أما في فئة Single-Hop، التي تتعلق باسترجاع حقيقة واحدة، فقد تفوّق Mnemis (0.940) على DeMem (0.935) بفارق ضئيل، وهو ما يتفق مع تفسير أن فائدة الفصل المحوري بالقرار تكون أصغر في الاسترجاع أحادي الخطوة. وفي LongMemEval أيضاً، حقق DeMem أفضل متوسط درجات على كلا النموذجَين الأساسيَين، وكانت أكبر المكاسب في الفئات التي تتطلب دمجاً عبر جلسات متعددة. والأهم أن الأفضلية استمرت حتى على النموذج مفتوح الأوزان Llama-3.1-70B، مما يدل على أن هذه الميزة ليست مرتبطة بنموذج تجاري معين.

دلالات على منتجات ThakiCloud

تلتقي رؤية هذه الورقة تماماً مع تصميم الذاكرة في Paxis، مستوى التحكم لمنصة Agent-Native Cloud لدى ThakiCloud. Paxis هو مستوى تحكم يعمل فوق ai-platform ويتعامل مع المهارات (skills) والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى، وضمن ذلك يحدد محرك المعرفة وطبقة الذاكرة يومياً ما الذي يُدمج وما الذي يُفصل.

أولاً، يمكن نقل معيار الدمج في محرك معرفة HKE Wiki ليصبح محورياً بالقرار. إذا دُمجت العناصر المتشابهة بمجرد التشابه النصي، فهناك خطر أن تُدمج حالتان تتطلبان إجراءَين متعارضَين في واحدة. وضع بوابة قبل الدمج مباشرة تسأل “هل يسبب هذان الأمران سلوكَين مختلفَين؟” هو نقل مباشر لمبدأ certified refinement في هذه الورقة.

ثانياً، يمنح هذا أساساً نظرياً لإدارة ميزانية الذاكرة الساخنة المقيمة في الجلسة (session-resident hot memory). الذاكرة الساخنة تفرض بالفعل ميزانيتها بحد أقصى من الأحرف، ومحاذاة معيار ما يُبقى وما يُحذف مع مبدأ “الحفاظ على التمييزات المؤثرة في القرار” يرفع جودة التقليم (pruning). أي إعطاء الأولوية للعناصر التي تفرّق بين القرارات، لا العناصر التي تُلخَّص بسلاسة.

ثالثاً، تُعد بوابات السياسات وسجلات التدقيق التي يخلّفها Paxis مصدر بيانات طبيعياً لإثبات لاحقاً أن “نفس الحالة أفضت إلى قرار مختلف”. إذا كان تشغيل certified refinement عبر الإنترنت لدى DeMem في الوقت الفعلي صعباً، يمكن اتباع مسار عملي بتحليل سجلات التدقيق هذه على دفعات غير متصلة (offline) وتحديث سياسة الدمج والفصل بشكل دوري. وهنا يلتقي مبدأ الذاكرة المحورية بالقرار مع التنسيق (orchestration) القائم على التدقيق الذي يجعل هذا المبدأ قابلاً للتكرار بأمان.

القيود والاعتراضات

لا بد من توضيح بعض النقاط.

أولاً، الإثبات (certify) له تكلفة. إثبات تعارض القرار من البيانات يتطلب تراكم ملاحظات، وفي بيئات البداية الباردة (cold start) أو التفاعل النادر، يتأخر الفصل، ولذلك يصعب الحكم من نص الورقة وحده على مصير جودة القرار في المراحل المبكرة.

ثانياً، تقدير “خسارة جودة القرار” عبر الإنترنت في بيئة الإنتاج يتطلب إشارة مكافأة أو حكماً (judge). تملك معايير القياس إجابات صحيحة تجعل الحصول على هذه الإشارة سهلاً، لكن كيفية تأمين هذه الإشارة في محادثات فعلية بلا إجابة صحيحة تبقى مهمة قادمة. قد يكون استخدام سجلات التدقيق المقترح أعلاه أحد الحلول، لكن ذلك خارج نطاق الورقة.

ثالثاً، يتضمن الملحق إثباتاً لصعوبة حسابية (computational hardness)، وهو ما يعني أن إيجاد القسمة (partition) المثلى صعب بشكل عام. DeMem هو تقريب عملي لذلك، وتلزم حدود إضافية حول الشروط التي ينهار عندها هذا التقريب.

ومع ذلك، فإن المبدأ نفسه، وهو نقل ذاكرة الوكيل من الوصف إلى القرار، بسيط وقوي، ويستحق النظر في تبنّيه الآن. إذا كان الوكيل ينسى باستمرار قراراته السابقة، فقد لا تكون المشكلة أن ذاكرته صغيرة، بل أن ذاكرته تحتفظ بالشيء الخطأ.

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

المصادر

• الورقة: Remember the Decision, Not the Description: A Rate-Distortion Framework for Agent Memory (arXiv 2605.10870)
• معايير القياس: LoCoMo، LongMemEval / النماذج الأساسية: GPT-4o-mini، GPT-4.1-mini، Qwen2.5-14B-Instruct، Llama-3.1-70B
• الأرقام في الجدول مقتبسة من الجدول 1 (LoCoMo، GPT-4.1-mini) في الورقة.

تتناول الورقة البحثية “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508)، التي نشرها باحثون من جامعة تسينغهوا وشركة Z AI في 8 يوليو 2026، هذه النقطة مباشرة. والخلاصة أن الباحثين تخلّوا عن “أخذ العينات الجماعي” (group sampling)، وهو جوهر GRPO الشائع الاستخدام. ولم يقتصر الأمر على تجربة هذا الأسلوب في تجارب الورقة فحسب، بل طبّقوه فعلياً في خط أنابيب حقيقي لتدريب النموذج المفتوح GLM-5.2 البالغ حجمه 750B.

نظرة عامة

سبب أهمية هذه الورقة الآن هو أن عنق الزجاجة في تكلفة التدريب انتقل من الخوارزمية إلى معدل استغلال البنية التحتية. فدوال الخسارة التي تجعل النموذج أكثر ذكاءً موجودة بالفعل بأشكال متعددة. المشكلة الحقيقية هي أنه حتى مع تشغيل مئات وحدات GPU معاً، يُنفَق معظم الوقت في “الانتظار” لإنتاج خطوة تدريب واحدة فقط.

تُشغّل ThakiCloud أيضاً خمس تقنيات لما بعد التدريب، هي SFT وCPT وDPO وGRPO وGKD، ضمن نظام تدريب نماذج اللغة الكبيرة المبني على kubeflow. لذلك فإن الثمن الذي يدفعه أخذ العينات الجماعي في GRPO عند التعامل مع rollouts طويلة، والمخاطر الجديدة التي قد يجلبها أي بديل يُزيل هذا الثمن، ليست قضية بعيدة عنا. يستعرض هذا المقال ما غيّرته SAO، وما تعنيه هذه التغييرات لمؤسسة مثلنا تسعى لتدريب وكلاء على عناقيد GPU متعددة المستأجرين (multi-tenant).

تصوير تخيلي يقابل بين rollout واحد يصل تباعاً بشكل مستمر، وrollouts تتجمّد في قائمة الانتظار إلى أن تكتمل المجموعة بأكملها.

ما هي هذه التقنية؟

يجمع اسم SAO، كما هو، بين مفهومين: “rollout واحد” (single-rollout) و”التحسين غير المتزامن” (asynchronous optimization).

كانت خطوط أنابيب التعلّم المعزز التقليدية متزامنة (synchronous). تُحدَّد دفعة من الطلبات، ويُولَّد لكل طلب عدد من الـ rollouts، وعندما تكتمل جميعها تُحسَب المكافأة ويُنفَّذ تحديث واحد للسياسة. نجح هذا الأسلوب جيداً في المهام التي تُنتج إجابات قصيرة، لأن أطوال الـ rollouts كانت متقاربة.

لكن المشكلة تظهر في مهام الوكلاء. فمهمة برمجية واحدة قد تنتهي خلال 3 جولات فقط، بينما تستمر مهمة مجاورة في استدعاء الأدوات عبر 40 جولة. وفي خط الأنابيب المتزامن، تبقى بقية وحدات GPU عاطلة حتى ينتهي أبطأ rollout في الدفعة. ظهر التعلّم المعزز غير المتزامن أصلاً لإزالة هذا الهدر: يُحدَّث النموذج فور اكتمال كل rollout، بينما يستمر المولّد (generator) دون توقف في إنتاج الـ rollout التالي.

flowchart TB
    subgraph SYNC[GRPO المتزامن]
        A1[دفعة من الطلبات] --> A2[توليد G من الـ rollouts<br/>لكل طلب كمجموعة]
        A2 --> A3[الانتظار حتى اكتمال<br/>أبطأ rollout]
        A3 --> A4[حساب المكافأة النسبية للمجموعة<br/>تحديث واحد للسياسة]
        A4 -.توقف GPU.-> A2
    end
    subgraph SAO[SAO غير المتزامن]
        B1[توليد rollout واحد<br/>لكل طلب] --> B2[وصول فوري<br/>عند الاكتمال]
        B2 --> B3[كبح تحديثات off-policy<br/>عبر تقليم الرموز ثنائي الاتجاه]
        B3 --> B4[تحديث مستمر للسياسة]
        B4 --> B1
    end
    SYNC -->|إزالة حاجز المجموعة| SAO

هنا ينشأ التعارض الجوهري. فاسم GRPO (Group Relative Policy Optimization) يحمل معنى “النسبية الجماعية” منذ البداية. تُجمَع عدة rollouts لطلب واحد في مجموعة واحدة، وتُقارَن داخل هذه المجموعة الـ rollouts الأفضل نسبياً بالأسوأ لحساب الأفضلية (advantage). وميزة GRPO، التي هي في الوقت نفسه قيدها، أنها تُنتج إشارة التدريب من المقارنة داخل المجموعة فقط دون الحاجة إلى دالة قيمة (critic) منفصلة. فإن لم تكتمل المجموعة، يستحيل حساب الأفضلية. وهكذا يتعارض جوهرياً البناء غير المتزامن الذي يتعلّم فور وصول كل rollout مع GRPO الذي يفرض الانتظار حتى تكتمل المجموعة.

لماذا لا يتناسب GRPO مع التعلّم غير المتزامن؟

لنتأمل هذا التعارض بمزيد من التفصيل. فللحفاظ على المجموعة داخل خط أنابيب غير متزامن، لا مفر من أحد خيارين سيئين.

الأول هو الانتظار على مستوى المجموعة، وحينها تتلاشى ميزة اللاتزامن، وينتهي الأمر بالعودة فعلياً إلى النمط المتزامن الذي ينتظر أبطأ rollout.

والثاني هو توليد rollouts المجموعة الواحدة بسياسات (policies) مختلفة زمنياً. فإذا أنتجت سياسة قديمة بعض rollouts المجموعة، وأنتجت سياسة مُحدَّثة بعد بضع خطوات rollouts أخرى ضمن المجموعة نفسها، فإن تجميعها ومقارنتها نسبياً كمجموعة واحدة يصبح ملوّثاً إحصائياً من الأساس. فحين تتفاوت درجة off-policy من rollout إلى آخر، لكنها تُعامَل كأنها baseline واحد متجانس، يصبح التدريب غير مستقر.

إجابة SAO بسيطة: إلغاء المجموعة تماماً. يُولَّد rollout واحد فقط لكل طلب، وحالما يصل يُستخدَم مباشرة في التدريب. وبزوال حاجز المجموعة، لا يضطر المولّد إلى الانتظار إطلاقاً، فيتقلّص وقت خمول GPU بشكل كبير.

ركيزتا SAO: rollout واحد وتقليم الرموز ثنائي الاتجاه

لكن إلغاء المجموعة يعني فقدان ما كانت GRPO تحصل عليه مجاناً. فالمقارنة داخل المجموعة كانت تلعب بحد ذاتها دور baseline يُقلّل التباين. وحين يكون هناك rollout واحد فقط، يختفي معيار المقارنة القائم على “هل تفوّق هذا الـ rollout على متوسط المجموعة؟”. فضلاً عن ذلك، في البنية غير المتزامنة تنشأ فجوة زمنية بين السياسة التي أنتجت الـ rollout والسياسة التي يُراد تحديثها الآن. وهذه الفجوة، أي مشكلة off-policy، هي الخطر الثاني الذي يهدد استقرار التدريب.

تتصدى SAO لمشكلة الاستقرار هذه عبر “تقليم صارم ثنائي الاتجاه على مستوى الرمز” (strict double-side token-level clipping). فالتقليم (clipping) الذي كانت تستخدمه عائلة PPO أصلاً هو آلية تقصّ التدرّج (gradient) عندما تخرج نسبة الأهمية (importance ratio) عن نطاق محدد. وتُطبّق SAO هذا التقليم على مستوى كل رمز (token) على حدة، وبصرامة في الاتجاهين الأعلى والأسفل معاً. فعند الرموز التي تباعدت فيها rollout السياسة القديمة كثيراً عن السياسة الحالية، يُكبَح التحديث بقوة، مما يمنع الإشارات ذات الفجوة الزمنية الكبيرة من إفساد التدريب.

ونتيجة هذا المزيج، تُفيد الورقة بأن SAO واصلت التدريب باستقرار على مدى 1,000 خطوة. وإذا أخذنا بعين الاعتبار أن حالات التباعد أو الانهيار شائعة في التعلّم المعزز غير المتزامن بعد تجاوز بضع مئات من الخطوات، فإن استقرار التدريب لـ 1,000 خطوة يُعدّ دليلاً داعماً للمزاعم الأساسية لهذه الطريقة.

النتائج الفعلية والتحقق

قارنت الورقة SAO بـ GRPO ومتغيراتها، وأفادت بتفوّقها باستمرار في معايير قياس الترميز والاستدلال الخاصة بالوكلاء. والمعايير المذكورة هي SWE-Bench Verified (حل مشكلات GitHub الحقيقية)، وBeyondAIME (رياضيات عالية الصعوبة)، وIMOAnswerBench (رياضيات بمستوى الأولمبياد). وتشترك المعايير الثلاثة في كونها مهام متعددة الخطوات وطويلة النَفَس، وليست إجابات قصيرة مباشرة، وهو بالضبط المجال الذي تستهدفه SAO.

أما التحقق الأكثر إقناعاً فليس في جداول المعايير، بل في واقعة النشر ذاتها. فقد استُخدِمت SAO في خط أنابيب فعلي للتعلّم المعزز للوكلاء لتدريب النموذج المفتوح GLM-5.2 (نموذج MoE بحجم إجمالي 750B وحجم فعّال 40B من المعاملات النشطة، 750B-A40B). وكون طريقة بحثية لم تبقَ حبيسة الورقة العلمية، بل استُخدِمت في تدريب إنتاجي لنموذج بحجم مئات المليارات، إشارة قوية على أن هذه الطريقة تصمد عند المقياس الحقيقي، لا في إعدادات تجريبية صغيرة فقط.

غير أن هذا المقال لا يقتبس الأرقام التفصيلية للمعايير. فإن تعذّر إعادة إنتاج الأرقام الدقيقة التي تحقّق منها النص الأصلي في هذا المكان، فالأمانة تقتضي نقل بنية الطريقة وأسماء المعايير المذكورة صراحة دون اختلاق أي رقم. ومن يحتاج إلى الدرجات الدقيقة، فليرجع إلى النص الأصلي أدناه مباشرة.

دلالات التطبيق على منتجات ThakiCloud

لا يقتصر درس SAO على كونه ورقة خوارزمية واحدة، بل يمسّ مباشرة طريقة تشغيل عناقيد GPU.

عدسة ai-platform (البنية التحتية لتدريب GPU). تجدول منصة ai-platform التابعة لـ ThakiCloud تدريب GPU متعدد المستأجرين فوق Kubernetes وKueue. ونظام تدريب نماذج اللغة الكبيرة المبني على kubeflow يدعم بالفعل GRPO كأحد تقنيات ما بعد التدريب. والسؤال الذي تطرحه SAO واضح: كم يتراجع معدل استغلال GPU في مهام تدريبنا بسبب التفاوت في أطوال الـ rollouts؟ ففي المهام المتفاوتة الطول كـ rollouts الوكلاء، يتحوّل انتظار المجموعة المتزامن إلى تكلفة مباشرة. وفصل توليد الـ rollouts غير المتزامن عن التدريب يتيح استخلاص خطوات تدريب فعّالة أكثر من العدد نفسه من وحدات GPU، وهو ما يشكّل رافعة مباشرة لخفض تكلفة التدريب لكل مستأجر في بيئة متعددة المستأجرين. كما أن التحقق مما إذا كانت جدولة gang scheduling وإدارة الطوابير في Kueue تفرض نمط “الانتظار حتى تكتمل المجموعة” يُعدّ نقطة تحسين عملية أخرى.

عدسة Paxis (نتاج تدريب الوكلاء). Paxis، وهي منصة Agent-Native Cloud التابعة لـ ThakiCloud، مستوى تحكّم يُشغّل المهارات (skills) في صناديق رملية معزولة (sandbox) ويمرّر كل سلوك عبر بوابات سياسات وسجلات تدقيق. والوكيل الذي تسعى SAO لتدريبه جيداً، أي وكيل يستدعي الأدوات عبر جولات متعددة ويُصلح قواعد الأكواد، هو بالضبط عبء العمل الذي تُشغّله Paxis. بل إن آثار الوكلاء (agent traces) الفعلية التي تُولّدها Paxis داخل الصناديق الرملية المعزولة يمكن أن تكون بحدّ ذاتها مصدر rollouts للتعلّم المعزز غير المتزامن على غرار SAO. وبذلك تكتمل حلقة: تُنتج ai-platform الـ rollouts وتدرّب عليها بتكلفة منخفضة، وتُشغّل Paxis الوكيل الناتج بأمان، لتُولّد بدورها بيانات تدريب جديدة. إنها بنية تقوم فيها بنية التدريب منخفضة التكلفة (ai-platform) بدعم جدوى الوكلاء الاقتصادية (Paxis).

القيود والاعتراضات

قبل تبنّي هذه الطريقة دون تمحيص، ينبغي التوقف عند بضع نقاط.

أولاً، يتخلّى الـ rollout الواحد عن تقليل التباين الذي كانت توفّره المجموعة. وتُعوّض SAO عن ذلك بالتقليم، لكن التقليم بطبيعته آلية تقصّ إشارة التدريب. فالتقليم الصارم أكثر مما ينبغي قد يُلقي حتى بالتدرّجات الصالحة، مما يُبطئ التدريب. ونقطة التوازن بين “الاستقرار” و”سرعة التعلّم” قابلة للتغيّر بشكل كبير تبعاً للمهمة والمقياس.

ثانياً، التحقق عبر تدريب نموذج بحجم 750B مثير للإعجاب، لكن نجاحه عند هذا المقياس لا يعني أنه الأمثل بالضرورة في إعدادات المؤسسات الصغيرة. فخط الأنابيب غير المتزامن يتطلّب تعقيداً إضافياً في البنية التحتية لفصل المولّد عن المدرّب. وبالنسبة للفرق التي تُجري ضبطاً دقيقاً قصيراً بعدد محدود من الـ rollouts، قد يكون GRPO المتزامن أبسط وكافياً.

ثالثاً، توجد مقاربات نشطة في الاتجاه المعاكس أيضاً. فقد ظهرت في الفترة نفسها دراسة تتناول العلاقة بين staleness ومعدل التعلّم في RLHF غير المتزامن عبر قوانين تحجيم (scaling laws) (arXiv 2607.01083)، كما ظهرت مقاربات تُثبّت التدريب غير المتزامن عبر محاذاة التدرّجات (gradient alignment). ولذلك فالأدق أن نعتبر مبدأ SAO القائم على “إلغاء المجموعة وكبح ذلك بالتقليم” واحداً من عدة إجابات قوية محتملة على مسألة مفتوحة هي التعلّم المعزز غير المتزامن للوكلاء، لا الإجابة الوحيدة الصحيحة.

ومع ذلك، فإن إسهام SAO واضح. فقد حدّدت المشكلة بدقة (عدم كفاءة أخذ العينات الجماعي عند طول الـ rollouts)، وتحقّقت من الحل (rollout واحد مع تقليم ثنائي الاتجاه) عبر تدريب إنتاجي فعلي بمقياس مئات المليارات من المعاملات. وأي مؤسسة يمثّل فيها معدل استغلال GPU تكلفة التدريب مباشرة، لديها سبب وجيه لحساب المبلغ الذي يُهدَر في خط أنابيبها بسبب “انتظار المجموعة”.

المصادر

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• ذو صلة: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

المشكلة: مبدأ للتحقق موجود، لكن لا قياس فعلياً له

في الأنظمة متعددة الوكلاء حيث ينتج كل وكيل عامل (worker) نتائجه بشكل مستقل، هناك دائماً خطر أن ينتج نموذج عامل منخفض التكلفة نتيجة تبدو معقولة لكنها في الواقع غير مدعومة بأساس حقيقي. لمواجهة هذا الخطر، استقر العمل الفعلي على مبدأ “كل عملية fan-out يجب أن تُغلَق بتحقق عدائي (adversarial verification)”. بموجب هذا المخطط، يحاول عدة وكلاء مستقلين يلعبون دور المشكك (skeptic) دحض كل نتيجة ينتجها العامل، وعندما تتجاوز حالات الدحض عتبة محددة مسبقاً، يقوم الكود تلقائياً بإسقاط تلك النتيجة.

المشكلة أن متغيرين داخل هذا المبدأ، وهما مستوى نموذج التحقق المكلَّف بدور المشكك وعدد المشككين الذين سيُعيَّنون، إضافة إلى قاعدة الأغلبية المستخدَمة، ظلوا في معظمهم مثبَّتين بالعرف دون قياس فعلي. الافتراض بأن استخدام نموذج تحقق أغلى يعني أماناً أكبر، وأن زيادة عدد المشككين تعني أماناً أكبر، يبدو منطقياً بشكل حدسي، لكن لم تُقدِّم أي دراسة سابقة تأكيداً لهذا الافتراض على نظام تشغيل حقيقي متعدد الوكلاء مقابل معيار مرجعي (benchmark) ذي حقيقة أرضية معروفة قبل هذه الورقة البحثية.

المساهمة الأساسية: إعادة بناء 27 تهيئة من 12 نتيجة و180 استدعاء فعلي لواجهة برمجة التطبيقات

بنى الباحثون معياراً مرجعياً محكوماً فوق نظام تنسيق فعلي متعدد الوكلاء بمستوى إنتاجي حقيقي. أعدّوا 12 نتيجة (finding) إجمالاً، 6 منها صحيحة فعلاً و6 مُصطنَعة عمداً، وجمعوا 5 أحكام (verdicts) مستقلة من مشككين لكل نتيجة عبر كل من مستويات التحقق الثلاثة: Haiku وSonnet وOpus. بلغ عدد استدعاءات واجهة برمجة التطبيقات الفعلية المجموعة بهذه الطريقة 180 استدعاءً، بلا أي فشل، وبتكلفة إجمالية قدرها 96.91 دولاراً. المنهجية الأساسية هنا هي أن هذه العينة الواحدة (draw) قُطِّعت لاحقاً (post-hoc slicing): جميع التهيئات الـ27 التي تجمع بين عدد المشككين N (1/3/5) وثلاث قواعد عتبة، وهي الأغلبية والإجماع ونقض الفرد الواحد (strict veto)، أُعيد بناؤها بشكل حتمي دون أي استدعاءات إضافية لواجهة برمجة التطبيقات.

نتائج قياس معدل بقاء الهلوسة (hallucination survival rate) مقابل التكلفة، موزّعة حسب المستوى وعدد المشككين. باستثناء تهيئات Opus التي استخدمت قاعدتي الأغلبية أو الإجماع بعدد 3 إلى 5 مشككين، حجبت جميع التهيئات المُحقَّقة الهلوسة بالكامل (0.0)، بينما سمح خط الأساس غير المُحقَّق بمرور جميع النتائج كما هي (1.0). كانت تهيئة مشكك واحد من Haiku (3.46 دولار) هي النقطة المثلى الوحيدة على منحنى باريتو (Pareto).

أول ما تأكد هو أن نقطة مثلى واحدة فقط من بين التهيئات الـ27 كانت على منحنى باريتو، وكانت هي الأرخص. بلغت تكلفة التحقق من كامل النتائج الـ12 باستخدام مشكك واحد فقط من Haiku 3.46 دولار، وحققت هذه التهيئة في الوقت نفسه معدل بقاء هلوسة قدره 0.0 ومعدل بقاء نتائج صحيحة قدره 1.0. جميع التهيئات الـ26 المتبقية كانت أقل من هذه التهيئة في واحد على الأقل من المحاور الثلاثة: التكلفة وحجب الهلوسة والحفاظ على النتائج الصحيحة.

النتيجة الثانية اللافتة هي أن Opus لم تكن أبداً على منحنى باريتو المثالي، ولا مرة واحدة. مشكك واحد فقط من Opus طابق جودة مشكك واحد من Sonnet تماماً بينما كانت تكلفته أعلى بمقدار 1.68 مرة، وعند استخدام Opus بعدد 5 مشككين مع قاعدة الأغلبية، كانت التكلفة أعلى بمقدار 15.66 مرة من النقطة المثلى بينما ساء معدل بقاء الهلوسة فعلياً ليصل إلى 0.167. الحدس العملي القائل بأن رفع مستوى نموذج التحقق يشتري أماناً أكبر لم يصمد على هذا المعيار المرجعي.

نتائج قياس معدل بقاء النتائج الصحيحة (true-finding survival rate) موزّعة حسب المستوى. لم يفقد Sonnet وOpus أي نتيجة صحيحة واحدة عبر أي مزيج من عدد المشككين والقواعد (1.0)، لكن Haiku تحت قاعدة نقض الفرد الواحد بعدد 3 و5 مشككين أسقط خطأً نتيجة صحيحة واحدة بسبب حكم خاطئ من أحد المشككين (0.833).

كان الاكتشاف الأكثر إثارة للاهتمام هو أن زيادة عدد المشككين ليست دائماً أكثر أماناً. تحت تهيئة Opus مع قاعدة الأغلبية، أدى رفع عدد المشككين من 3 إلى 5 إلى تدهور معدل بقاء الهلوسة فعلياً، من 0.0 إلى 0.167. عند تتبع السبب، تبين أن نتيجة مصطنعة واحدة محددة لم يدحضها بشكل صحيح سوى 2 من أصل 5 مشككين، أي بمعدل دقة 40 بالمئة. في عينة الـ3 مشككين، شكّل هذان التصويتان الصحيحان 2/3، أي 67 بالمئة، متجاوزَين عتبة الأغلبية فأُسقِطت تلك النتيجة. أما في عينة الـ5 مشككين، فشكّل التصويتان الصحيحان أنفسهما 2/5 فقط، أي 40 بالمئة، وهو ما لم يبلغ الأغلبية فبقيت النتيجة على حالها. هذا شكل من أشكال تخفيف الأصوات (vote dilution) يشبه بنيوياً مفارقة كوندورسيه (Condorcet)، حيث تصبح قواعد الأغلبية النسبية هشة بنيوياً في العناصر الصعبة حين تنخفض دقة المشكك الفردي عن 50 بالمئة.

رسم بياني تحليلي يوضح الأثر غير الرتيب (non-monotonic) الذي تنخفض فيه سلامة التحقق فعلياً كلما زاد عدد المشككين. تحت قاعدة Opus/الأغلبية، كان معدل بقاء الهلوسة 0.0 عند N=1 ثم ارتفع إلى 0.167 عند N=5، بما يتسق مع أثر تخفيف على طراز كوندورسيه حيث يفقد تجميع الأغلبية أمانه بنيوياً بمجرد أن تنخفض دقة المشكك الفردي لكل عنصر عن 50 بالمئة.

تكشف هذه النتيجة أيضاً أهمية اختيار القاعدة. تبدو قاعدة “الإجماع” من اسمها الأكثر حذراً، لكنها في الواقع كانت الأكثر هشاشة، إذ سجّلت معدل بقاء هلوسة قدره 0.167 عند كل من N=3 وN=5 تحت مستوى Opus. في المقابل، كانت قاعدة نقض الفرد الواحد (strict veto)، التي تُسقِط النتيجة فوراً إذا دحضها ولو مشكك واحد فقط، القاعدة الوحيدة التي حققت معدل بقاء هلوسة صفراً عبر جميع المستويات وجميع تهيئات عدد المشككين. غير أن هذه القاعدة لم تكن بلا ثمن، فعند مستوى Haiku منخفض التكلفة، تسببت أحكام خاطئة ناتجة عن الضجيج (noise) لدى المشككين في حالات قليلة أُسقِطت فيها نتيجة صحيحة عن طريق الخطأ (معدل بقاء نتائج صحيحة قدره 0.833).

المساهمة على مستوى الشركة والمجتمع والعلم

كانت ThakiCloud تعمل بالفعل بموجب قاعدة داخلية مفادها أن “عملية fan-out تُغلَق بالتحقق”، لكن التوليفة المثلى بين مستوى نموذج التحقق وعدد المشككين وقاعدة الأغلبية ظلّت مجرد مبدأ وصفي لم يُقَس فعلياً من قبل. تقدّم هذه الدراسة منحنى باريتو مستمداً من نظام تشغيل إنتاجي حقيقي وسكربت تجميع حتمي، ما يوفر أساساً قائماً على التكلفة لتحسين إعدادات بوابة التحقق في مسارات العمل متعددة الوكلاء الجارية بالفعل، مثل مراجعة المهارات (skill review) وعمليات fan-out البحثية وخط أنابيب الأوراق البحثية.

وعلى نطاق أوسع، تُثبت هذه الدراسة أن حتى الفرق الصغيرة التي لا تملك ميزانية تحقق واسعة يمكنها بناء خط أنابيب موثوق لتدقيق الوكلاء بتكلفة منخفضة. كما أنها أول دراسة تُقدِّم قياساً كمياً، على معيار مرجعي محكوم بحقيقة أرضية معروفة، لتأثير مستوى نموذج التحقق وعدد المشككين وعتبة الأغلبية على معدل بقاء الهلوسة في خط أنابيب متعدد الوكلاء من نمط fan-out. لقد رفعت ممارسة التحقق العدائي، التي ظلت حتى الآن على مستوى المبدأ الوصفي، إلى منحنى قابل للقياس.

القيود

يوضح الباحثون بصراحة حدود هذه النتائج. المعيار المرجعي نفسه تجربة صغيرة النطاق قائمة على 12 نتيجة وعينة واحدة، لذا تتحرك النسب المئوية بخطوات خشنة من الأسداس. وعلى وجه الخصوص، فإن حالتي N=3 وN=5 ليستا تجربتين مستقلتين أُعيد سحبهما بشكل منفصل، بل بُنيتا عبر تقطيع العينة نفسها المكوّنة من 5 محاولات لاحقاً، ما يعني أن قيمة شاذة واحدة قد تؤثر في عدة خلايا في آن واحد، ولهذا السبب لم يُجرَ أي اختبار دلالة إحصائية بسبب حجم العينة. اختُبِرت فقط ثلاثة مستويات ضمن عائلة Claude، وهي Haiku وSonnet وOpus، لذا لا يوجد أساس لافتراض أن هذا الترتيب بين المستويات ينتقل إلى عائلات نماذج أخرى، كما تعكس أرقام التكلفة أسعار واجهة برمجة التطبيقات كما كانت في 10 يوليو 2026، وقد تتغير التهيئة المسيطرة إذا تغيرت الأسعار. يشدد الباحثون على أن آلية تخفيف كوندورسيه نفسها سليمة رياضياً، لكن هذا المعيار المرجعي الصغير وحده لا يمكنه الإجابة عن مدى تكرار وقوع العناصر الصعبة في نطاق دقة مشكك أقل من 50 بالمئة في ظروف التشغيل الفعلية، ويقترحون كخطوة تالية معياراً مرجعياً أكبر حجماً ذا بذور محددة (seeded) مع إعادة سحب مستقلة لكل خلية.

يمكن الاطلاع على تفاصيل الورقة البحثية كاملة على صفحة مجموعة بيانات Hugging Face: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-11-verify-gated-fanout-pareto

شرائح ذات صلة

هذه الشرائح تلخّص محتوى هذا المقال باستخدام نمط cinematic_infographic في NotebookLM.

Overview

Until now, multi-agent coding workflows have largely stayed within a single vendor. In Claude Code, Opus conducts while Sonnet or Haiku runs as subagents. What makes fable-advisor interesting is that it structures this division of labor across vendor boundaries. Anthropic’s Fable 5 handles the orchestration layer, while xAI’s Grok 4.5 handles the implementation layer.

The core insight of this design is straightforward. Conducting and implementing demand different capabilities, and they have different cost structures. Spec writing and diff review are matters of judgment and reasoning, so they require a model suited to conducting, whereas bulk code typing is where throughput and cost efficiency matter most. fable-advisor places each of these two roles on models from different vendors, letting each layer use whichever model fits it best. The fact that it is free and open source, with routing logic that can be customized directly, also lowers the barrier to real-world adoption.

What This Technology Is

fable-advisor is a plugin layered on top of Claude Code that enforces a three-way separation of roles.

First, the conductor (Fable 5) writes specs and reviews outcomes. It takes the user’s request, breaks it down into an implementation spec, and reviews the resulting diff once implementation is done. The important point is that the conductor never writes code directly. It focuses entirely on judgment and contract definition.

Second, the implementer (Grok 4.5) handles all the actual typing. It receives the spec passed down by the conductor and writes code through the Grok CLI, powered by Grok 4.5. Looking at the repository’s history, starting with v3 the existing Sonnet/Opus implementation agent was replaced by grok-implementer, making Grok 4.5 the default typing lane. In other words, this plugin was not cross-vendor from the start; it is the result of an evolution that moved the implementation lane toward a lower-cost, higher-throughput model.

Third, there is parallel execution. Independent specs are run simultaneously as parallel agents. When the conductor breaks work down into units that do not depend on each other, each unit proceeds concurrently as a separate implementation agent. This is not simple sequential delegation but closer to a division of labor shaped like a DAG (directed acyclic graph).

The overall flow looks like this in diagram form.

flowchart TB
    U[User request] --> F[Fable 5 conductor<br/>spec writing & diff review]
    F -->|split into independent specs| S1[Spec A]
    F -->|split into independent specs| S2[Spec B]
    S1 -.Grok CLI.-> G1[Grok 4.5 implementer A]
    S2 -.Grok CLI.-> G2[Grok 4.5 implementer B]
    G1 -->|diff| F
    G2 -->|diff| F
    F --> R[Integration & review result]

Installation and Integration

Installing the plugin takes one line. You add the repository to Claude Code’s plugin marketplace.

claude plugin marketplace add DannyMac180/fable-advisor

The Grok CLI, which handles the implementation lane, requires separate authentication. Logging in with grok login sets up OAuth authentication based on a SuperGrok or X Premium+ subscription, and according to the repository description, this path lets you run the implementation agent without per-token API charges, purely through your subscription. This is the crux of the cost structure. The conductor makes only a small number of judgment-heavy calls, while the bulk of code typing happens within the subscription plan, minimizing exposure to usage-based billing.

From an integration standpoint, it is worth noting that the routing logic is open. You can adjust directly which task goes to which model and under what conditions work gets parallelized, so a team can reconfigure the lanes to fit its budget and quality requirements.

How This Design Actually Performs

fable-advisor is not a tool that touts benchmark numbers but a workflow pattern, so instead of reproducible performance figures, this section covers the structural effects the design produces. Since the repository does not present quantitative metrics, this post also avoids inventing numbers and sticks to structural benefits.

The biggest effect is the separation of cost and quality. When orchestration that requires judgment goes to the conductor and implementation that requires throughput goes to a low-cost implementer, the overall workflow’s unit cost drops while judgment quality is preserved. The arrangement “call the conductor sparingly and cheaply, call the implementer often but not expensively” falls into place naturally.

The second effect is cross-verification. The fact that the implementer and the reviewer are models from different vendors produces an interesting side effect. When the same model reviews its own code, it tends to overlook the same mistakes it made in the first place, but when a model from a different lineage reviews the diff, there is more room for it to catch the other’s blind spots. The conductor-worker split becomes more than a simple division of labor; it functions as a kind of mutual verification mechanism.

The third effect is reduced latency through parallelization. When independent specs are implemented at the same time, total working time converges not to the sequential sum but to the length of the single longest chain. The better the conductor breaks work down, the larger this benefit becomes.

Generalizing the Conductor-Worker Pattern

If we look at fable-advisor not as an individual plugin but as a design pattern, a broader context comes into view. The essence of this pattern is “the main session only conducts, and heavy work gets delegated.” Crossing vendors is just one variant of this pattern; it also holds within a single vendor. For example, a setup where Claude Code uses Fable 5 as the conductor, routes exploration to Haiku, implementation to Sonnet, and complex reasoning to an Opus subagent is already widely used. What fable-advisor did was extend the target models of this delegation beyond the vendor boundary.

Seen from this angle, the selection criteria for the conductor model become clear. Since the conductor is responsible for judgment, branching, and aggregation, accuracy and reasoning quality matter, but call frequency is relatively low. The implementer, by contrast, cares about throughput and unit cost. Good orchestration, then, is not “put the most expensive model in the conductor seat and route everything through it,” but rather “place at each layer the model whose characteristics that layer actually requires.” The v3 evolution that moved fable-advisor’s implementation lane to a low-cost subscription model is exactly the result of following this principle.

One thing worth watching is that this pattern only works if the boundaries of delegation are clear. If the conductor hands off an ambiguous spec, the implementer fills in the gaps by guessing, and the resulting review burden actually grows. The gains of delegation are realized only when the spec is sufficiently concrete. This is no different from division of labor in human organizations. The clearer the specification, the better delegation works.

Implications for ThakiCloud’s Products

This design overlaps strikingly with how ThakiCloud operates its own agents.

It is most directly relevant from a Paxis perspective. Paxis is ThakiCloud’s Agent-Native Cloud control plane, and it treats DAG-shaped multi-agent execution as a core capability. The “spec writing to distributed implementation to cross review” structure that fable-advisor demonstrates shares the same skeleton as Paxis’s skill harness, which breaks work into subtasks, runs them in parallel inside isolated sandboxes, and closes the loop with a verification stage. In particular, the principle that the conductor focuses on judgment and contract definition rather than writing code directly matches exactly with our own design philosophy of drawing capability from surrounding contract structures rather than model tier. The flow where the conductor reviews results produced by a different model also lines up with our own operating principle of closing multi-agent fan-out with a verification stage, so that hallucinations do not accumulate unchecked.

It also holds up from an ai-platform perspective, particularly around cost structure. ThakiCloud’s ai-platform schedules GPU workloads on K8s and Kueue, serving the inference and training workloads of its customers. The idea behind fable-advisor of delegating the implementation lane to a low-cost model to bring down overall workflow unit cost is a pattern that GPU cloud customers can apply directly when designing their own workloads. When the small number of judgment steps that need heavy inference and the larger number of execution steps that need throughput are placed on resource tiers matched to each, the same result can be obtained at lower cost. Since low-cost serving is what makes agent economics work in the first place, ai-platform’s cost efficiency and Paxis’s agent orchestration complement each other.

Limitations and Counterarguments

This design comes with clear trade-offs. The first is operational complexity. Weaving two vendors’ models into a single workflow means managing two authentication systems, two pricing plans, and two points of failure. If one vendor’s CLI changes or its authentication expires, the entire workflow can stop. This is a trade against the simplicity of a single-vendor workflow, and whether the benefit justifies the complexity may differ from team to team.

The second is the risk of delegating quality. Delegating implementation to a low-cost model means that if the conductor’s spec and review are not tight enough, low-quality implementation can pass through unchecked. The quality of this workflow ultimately depends on how strict the conductor’s review gate is. If the review is a formality, the cross-verification benefit of cross-vendor division of labor disappears, and what remains is a low-quality pipeline that merely saved on cost.

The third is the constraint of subscription-based authentication. The fact that the Grok CLI runs on subscription-based OAuth is a cost advantage for individuals or small teams, but for large-scale automation or unattended pipelines, subscription limits and authentication renewal can become bottlenecks. The advantage of having no usage-based billing is, flipped around, also a statement that scaling stops the moment usage exceeds the plan’s limit.

Even so, the message fable-advisor sends is clear. The future of coding agents lies not in one all-purpose model but in orchestration that combines the model best suited to each layer. This points to exactly the same direction as ThakiCloud’s approach of treating multi-agent systems and model routing as first-class resources.

Sources

• fable-advisor (GitHub)
• Grok CLI (x.ai/cli)

Overview

The common approach to an agent’s memory problem is a vector database: embed conversations and documents, store them, and retrieve them via semantic search when needed. It is powerful, but the operational burden is significant. You have to manage an embedding pipeline, a vector index, and a reindexing schedule, which is a lot of infrastructure for an individual to bolt onto their own workflow.

personal-monorepo-template takes the opposite direction. It reframes memory not as a search problem but as a file-structure problem. People live in a people/ folder, projects live as project packets, and recurring ways of working live as skills inside the repository itself. The agent loads this entire structure persistently through AGENTS.md every time a session starts. Instead of the approximate matching of vector search, memory is accessed through the exact address of a folder path.

The background of the person who built this adds weight to the design. jxnl is the creator of Instructor, a structured-output library downloaded millions of times a month, reportedly cited by OpenAI as an inspiration for its own structured output feature. He currently works as a Developer Experience engineer on the OpenAI Codex team, which makes this a tool built by someone who runs coding agents in daily production use to solve their own problem, giving it real reference value.

What This Technology Is

The core idea is simple. Represent an agent’s memory as plain folders and markdown inside a monorepo, and load it automatically every session. It breaks down into three parts.

The first is a record of people and projects. The repository scans Slack, email, calendar, and GitHub to generate people files and project packets, and proposes updates to the persistently loaded AGENTS.md. Mention a particular colleague’s name, and the agent reads that person’s file and instantly restores the context. Without any vector database, it locates “who this person is” through an exact folder path.

The second is repository-local skills. Recurring ways of working are placed as skills inside the repository, loaded automatically every session so the agent follows those procedures. A notable example is the built-in write-like-me skill, which learns from a user’s sent emails and Slack messages to write in that person’s own voice. The user’s past output becomes the training data for the skill itself.

The third is automatic check-ins. The repository is designed to run automatic check-ins at 9am and 4pm every day, summarizing that day’s project status and people-related context and proposing updates. Rather than waiting for a manual invocation, this is a loop where the agent refreshes its own memory on a fixed schedule.

The overall flow looks like this in diagram form.

flowchart TB
    SRC[Slack, Email, Calendar, GitHub] -->|scan| SCAN[Check-in script]
    SCAN --> PEOPLE[Propose people files]
    SCAN --> PKT[Propose project packets]
    SCAN --> AGD[Propose AGENTS.md updates]
    AGD -.loaded persistently at session start.-> AGENT[Coding agent]
    PEOPLE -.looked up by folder path.-> AGENT
    SKILL[Repository-local skills<br/>including write-like-me] -.loaded automatically.-> AGENT
    CRON[Automatic check-in at 9am and 4pm daily] --> SCAN

This design is interesting precisely because it connects to the “Codex-maxxing” philosophy the repo’s author laid out in a separate post. Rather than bolting a better model onto the agent, the direction is to build up the surrounding structure so the agent never starts from a blank slate.

Installation and Integration

This repository is exactly what its name says: a template. You integrate it by cloning it into your own GitHub account and configuring your coding agent (Codex or a similar CLI) to use the repository root as its working directory. The core entry point is AGENTS.md at the repository root, which the agent reads at the start of every session to understand the folder structure, the people and project context, and the list of skills it should load.

The key integration point here is that AGENTS.md is not a plain document but a persistently loaded contract. Because this file lands at the front of the context every session, what you write in it defines the agent’s default behavior. Since the folder structure is fixed, the agent accesses memory deterministically, in the sense of “if I need context on colleague A, I read people/A.md.” Unlike the probabilistic approximation of vector search, a file path always points to the same place.

Automatic check-ins are integrated by hooking the check-in script to a scheduler (a cron-style job) so it runs at a fixed time every day. This mechanism keeps the agent’s memory current without requiring a human to invoke it each time, and it is also an important design decision from a cost standpoint. Because it runs a finite number of times a day rather than polling continuously, it does not burn tokens in an infinite loop.

How This Design Actually Plays Out

This repository is not a tool that leads with benchmark numbers; it is a workflow pattern, so here we examine the structural effects it produces in practice. The repository does not offer reproducible performance figures, and the author himself points to improvements in day-to-day workflow rather than quantitative metrics as the justification. So this post does not invent numbers either and sticks to the structural advantages.

The biggest effect is eliminating the cost of context restoration. A vector database lookup runs an embedding computation and a similarity search on every query, while a folder-path lookup is a single file read. When a person says “that project from last time,” the agent reads the corresponding project packet directly and restores the exact context, with no false positives from approximate search. The precision of memory now depends on the quality of the folder design rather than the quality of retrieval.

The second effect is auditability. Because all memory is stored as human-readable markdown, a developer can open it directly to check, and correct, what the agent knows. Vector embeddings are hard for a human to verify by eye, but people/A.md is just a text file. Being able to fix the agent’s memory on the spot when it is wrong makes a real difference in practice.

The third effect is portability. Because it isn’t tied to any specific vector database vendor or embedding model, the repository itself is a complete, self-contained memory. Move it to a different machine or a different agent and the folders and markdown still work as-is. This lack of infrastructure lock-in connects directly to the on-premise and sovereign-cloud angle discussed below.

Implications for ThakiCloud Products

This design touches both of the axes on which ThakiCloud operates agents.

The most direct connection is to Paxis. Paxis is ThakiCloud’s Agent-Native Cloud control plane, which treats Skills, Tools, Policies, and Audit Logs as first-class resources. The pattern personal-monorepo-template demonstrates, “repository-local skills plus a persistently loaded contract (AGENTS.md),” maps precisely onto the direction of Paxis’s skill-harness design. Paxis already selects among many skills via BM25 and runs them in an isolated sandbox, and this repository’s approach answers a step upstream of that, “what knowledge should sit persistently in the session context,” with a clean answer expressed as folder structure. In particular, keeping memory as human-readable files with every update auditable is the same philosophy as Paxis’s principle of routing every agent action through a policy gate and an audit log. The very idea of drawing an agent’s capability from its surrounding structure rather than its model tier is isomorphic to our own design of treating skills as first-class resources.

From the ai-platform angle, the infrastructure-burden perspective is what stands out. ThakiCloud’s ai-platform is K8s-based AI/ML infrastructure that serves workloads for on-premise and sovereign-AI customers. For these customers, a memory architecture that requires running a vector database at all times represents extra infrastructure surface and management cost. A memory expressed as folders and markdown, by contrast, runs on the filesystem alone with no separate state store, which is a much lighter operational burden in regulated environments or air-gapped networks. The angle of “minimizing memory infrastructure while still giving the agent persistence” could be a genuine selling point for customers who require sovereign AI.

Limitations and Counterarguments

This design is not a silver bullet. The clearest limitation is scale. Folder-path access is powerful when the person or the agent already knows the address of the memory. But when you need to find information “you don’t know the location of” among tens of thousands of documents, semantic vector search is still superior. This repository assumes a relatively small, clearly structured memory space consisting of one person’s people, projects, and experiences. Scale it up to a team’s entire, sprawling knowledge base, and folder structure alone starts to hit its limits.

The second counterargument is the privacy of the scanning process. Scanning Slack, email, and calendar to build people files also means that sensitive conversations get stored as plain-text markdown. That’s convenient for personal use, but bringing it into an organization requires access control and retention policy without question. Auditability is a strength, but with no control over who can access those files, it becomes a liability just as easily.

The third is the reliability of automatic updates. If a twice-daily automatic check-in writes a wrong summary into a person file, that error keeps getting injected into every subsequent session. This is exactly why the repository frames updates as “proposals” that assume a human will confirm them. Push all the way to full automation and memory can quietly get corrupted, so leaving a human review gate in place is the safer approach.

Finally, this approach is pitched as “a free alternative to a human assistant’s salary,” but actually sustaining this level of workflow requires substantial engineering skill to design and refine the repository structure yourself. The tool being free and the cost of operating it well being free are two different things.

Even so, the core message this repository sends is clear. An agent’s memory does not have to be heavy infrastructure, and a good folder structure paired with a persistently loaded contract can deliver a surprising amount of persistence. That points in exactly the same direction as ThakiCloud’s own approach of treating skills and knowledge as first-class resources.

Sources

• jxnl/personal-monorepo-template (GitHub)
• Codex-maxxing (jxnl.co)