لقد أنشأنا مخطط GOAP في فترة ما بعد الظهر. إنه ينتج خطة نظيفة من تسع خطوات لأهداف هندسية في صفر مللي ثانية. لن نسمح له بالاقتراب من طلب رفض الدعوى. إليك السبب - والبوابات الأربع التي سنغلقها قبل أن نفعل ذلك.
العرض والحكم
تخطيط العمل الموجه نحو الهدف (GOAP) هو البنية التي تستخدمها محركات الشطرنج: احتفظ بشجرة من الاحتمالات المستقبلية، ابحث عن المسار الأقل تكلفة من حيث أنت إلى حيث تريد أن تكون، واقطع البقية. إنه يتناسب بشكل أفضل بكثير مع التقاضي مقارنة بالنماذج التي تعتمد على الدردشة. الطلبات، الاستكشاف، المحاكمات - كلها سلاسل من التحركات تحت قيود. تنتج النماذج التي تعتمد على الدردشة الجملة المعقولة التالية. يلتزم المخططون بهدف ويعملون بشكل عكسي.
حقائق أساسية
- مخطط A* GOAP عامل هو 517 سطرًا من جافاسكريبت العادية بدون أي تبعيات - تم نقله في فترة ما بعد الظهر من واجهة المستخدم (goal_ui) لـ ruflo claude-flow.
- مخطط GOAP لـ ruflo claude-flow لا ينفذ إعادة التخطيط التكيفي: دالة plan() تشغل A* مرة واحدة بالضبط عند تقديم الهدف - تم التحقق من ذلك في مواقع الاستدعاء في Index.tsx و ResearchReportModal.tsx (مرجع خارجي: مصدر ruflo claude-flow، قراءة مباشرة).
- تقديم طلب جوهري بموجب القاعدة 12(ب)(6) قبل الاحتكام إلى التحكيم يمكن أن يسقط الحق في التحكيم بموجب قضية Morgan v. Sundance (2022) - يمشي مخطط أقصر مسار مباشرة فيه.
لذا قمنا ببناء واحد. 517 سطرًا من جافاسكريبت العادية، بدون أي تبعيات، تم نقله في فترة ما بعد الظهر من مخطط GOAP A* الذي يأتي مدمجًا في تطبيق React `goal_ui` الخاص بـ ruflo. إنه يعمل على الأهداف الهندسية مثل 'شحن إعادة هيكلة المصادقة مع الاختبارات وطلب سحب (PR)' في صفر مللي ثانية وينتج خطة نظيفة من تسع خطوات.
لن نسمح له بلمس طلب حقيقي. ليس بعد. هذه المقالة تتناول السبب، وما الذي يجب أن يتغير قبل أن نفعل ذلك. إذا جئت إلى هنا للحصول على تأييد مدهش لتقنية Legal AI القادمة للمحامين، فإن مغزى هذه المقالة هو العكس: إليك معيار الصرامة الذي نضعه قبل توجيه هدف تقاضي من خلال أي مخطط - خاص بنا، أو بـ ruflo، أو بأي شخص آخر - والفجوة بين مخطط اليوم وهذا المعيار.
ما هو GOAP في الواقع
يتطلب GOAP ثلاثة مدخلات: حالة الهدف (الحقائق التي تريد أن تكون صحيحة - 'PR مفتوح'، 'CI أخضر'، 'تم النشر'), حالة بدئية (ما هو صحيح الآن), ومكتبة أفعال (كل حركة يمكنك القيام بها، كل منها بشروط مسبقة وتأثيرات - '`open_pr` يتطلب `pushed=true` و `diff_reviewed=true`؛ ويضبط `pr_open=true`'). ثم يقوم بتشغيل بحث A* - وهو نفس الخوارزمية التي يستخدمها نظام تحديد المواقع العالمي (GPS) لتجاوز حركة المرور - عبر مساحة تسلسلات الأفعال ويعيد المسار الصالح الأقل تكلفة من البداية إلى الهدف. إذا فشلت خطوة أثناء التنفيذ، فمن المفترض أن يعيد التخطيط من الحالة الجديدة.
بالنسبة للمحامين، أقرب تشبيه هو الشطرنج. لا يفكر الأستاذ الكبير في خطوة واحدة في كل مرة؛ بل يحمل شجرة من الاحتمالات المستقبلية ويقوم بالتقليم مع تطور اللعبة. GOAP هو ذلك، لكنه ميكانيكي. إنه ليس توليديًا؛ إنه بحث.
يتوافق التصميم مع التقاضي بشكل جيد للغاية. يتضمن طلب إجبار على التحكيم شروطًا مسبقة صارمة (وجود بند تحكيم، تم تقديم شكوى، لم يتم تقديم أي طلب موضوعي بعد) وتأثيرات صارمة (استبعاد مخاطر التنازل، يجب على المحكمة أن تحكم في قابلية التحكيم). للكشف نظام ترتيب صارم (المكتوبات قبل الإفادات، الفصل قبل الموضوع، اللقاء والتشاور قبل طلبات الإجبار). الحكم المستعجل لديه معيار نجاح/فشل. شكل العمل مشابه لـ GOAP.
ما قمنا ببنائه
أربعة ملفات: `planner.js` (165 سطرًا من التعليمات البرمجية، A* + كومة ثنائية صغيرة)، `actions.js` (134 سطرًا من التعليمات البرمجية، اثنا عشر إجراءً هندسيًا)، `parse.js` (58 سطرًا من التعليمات البرمجية، جدول عبارات يحول الإنجليزية إلى حالة هدف)، `cli.js` (160 سطرًا من التعليمات البرمجية، مشغل). إجمالي 517 سطرًا من التعليمات البرمجية. لا توجد تبعيات npm. يمكن قراءته في عشرين دقيقة.
قمنا بتشغيله مقابل الهدف 'شحن إعادة هيكلة المصادقة مع الاختبارات وطلب سحب (PR)':
goal predicates: {"pr_open":true,"ci_green":true,"deployed":true}
1. understand_code (cost 2) -> /zoom-out
2. write_tests (cost 3) -> /tdd
3. run_tests (cost 1) -> bash:test
4. review_diff (cost 1) -> /review
5. commit (cost 1) -> git:commit
6. push_branch (cost 1) -> git:push
7. open_pr (cost 1) -> /ship
8. wait_ci (cost 5) -> bash:ci-wait
9. merge_and_deploy (cost 2) -> /land-and-deploy
total cost: 17
expansions: 13 time: 0 ms found: trueتسع خطوات، بتكلفة 17، وثلاثة عشر توسيعًا للعقدة، وصفر ميلي ثانية. كل خطوة تتوافق مع مهارة gstack أو أمر shell، لذا فإن الخطة قابلة للتنفيذ - وليست مجرد تزيين. كما اختبرنا هدفًا أصغر ("اختبار وحدة تسجيل الدخول" - 3 خطوات، بتكلفة 6) وهدفًا غير قابل للتحقيق (شرط لا تحدده أي إجراءات - أعاد `found: false` مع أقرب خطة جزئية بدلاً من التعطل أو التكرار). جميع السلوكيات الثلاثة تتوافق مع المواصفات.
استغرق هذا فترة ما بعد الظهر. ليس هذا هو الجزء الصعب.
لماذا نقلنا هذا من ruflo
يشحن Ruflo (نظام `claude-flow` البيئي) مخطط GOAP داخل تطبيق React الخاص به `goal_ui` - `goapPlanner.ts`، ملف واحد، 180 سطرًا. التصميم سليم. قمنا باستخراجه.
بينما كنا نعمل هناك، قرأنا الكود المصدري بعناية. ادعاء واحد لا يصمد عند مراجعته: المخطط لا ينفذ إعادة التخطيط التكيفي. تقوم طريقة `plan()` بتشغيل A* مرة واحدة بالضبط عند تقديم الهدف وتُرجع `Step[]` التي تُشغّل رسومًا متحركة لواجهة المستخدم. لا توجد حلقة إعادة تخطيط، ولا إلغاء للخطة، ولا استرداد من الفشل في الملف. لقد تحققنا من مواقع الاستدعاء في `Index.tsx` و `ResearchReportModal.tsx`. نفس القصة.
نذكر هذا ليس للانتقاص من ruflo - فنواة المخطط هي شفرة جيدة - ولكن لأنه يهم بقية هذه المقالة. إعادة التخطيط التكيفي هي الميزة الوحيدة التي قد ترغب فيها أكثر قبل السماح لمخطط بالتعامل مع مسألة قانونية حقيقية، والتطبيق مفتوح المصدر الأكثر بروزًا والمجاور للقانون لا يمتلكها. ونحن لا نمتلكها أيضًا، حتى الآن. ولا يمتلكها أي شخص آخر نظرنا إليه.
أهداف التقاضي الثلاثة التي لم ننفذها
كانت الخطة الأصلية هي تنفيذ ثلاثة أهداف تقاضي حقيقية من خلال المخطط والحصول على تقييم للمخرجات من قبل محامٍ متقاضٍ رفيع المستوى. لم نفعل ذلك. لسببين. أولاً، توجيه استراتيجية التقاضي عبر عنوان URL عام لجهة خارجية - حتى لو كانت استراتيجية اصطناعية على نمط وقائع افتراضية - له تداعيات على السرية المهنية لم نرغب في التعامل معها من أجل تدوينة. إذا لم نكن لنفعل ذلك لعميل، فلا ينبغي أن نفعله لأنفسنا. ثانيًا، تحتوي مكتبة الإجراءات لدينا على اثني عشر إدخالًا وهي جميعها إجراءات هندسية: `understand_code`، `write_tests`، `commit`، `push_branch`، `open_pr`، `wait_ci`، `merge_and_deploy`. توجيهها نحو طلب رد دعوى سينتج عنه خطة تخبر المحامي بثقة أن `git commit` إجابته.
لكن حالات الاختبار الثلاث التي كتبناها لا تزال مفيدة - ليس كمعايير نجح فيها المخطط، ولكن كعامل محفز لما يجب أن تتعامل معه النسخة التالية.
الحالة 1 - طلب رد الدعوى بدفاع بند التحكيم. المطالبة: 'الفوز بطلب وفقًا للقاعدة 12(b)(6) في نزاع تعاقدي حيث يزعم المدعي خرقًا ولكن العقد يحتوي على بند تحكيم واضح.' الفخ: القاعدة 12(b)(6) هي الآلية الخاطئة. يتم إنفاذ التحكيم بموجب قانون التحكيم الفيدرالي §§ 3-4 بطلب إجبار. تقديم طلب موضوعي بموجب القاعدة 12(b)(6) قبل الاحتكام إلى التحكيم يمكن أن يؤدي إلى التنازل عن الحق في التحكيم بموجب Morgan v. Sundance (2022). المخطط الذي يصيغ طلب 12(b)(6) يضع العميل في منطقة سوء الممارسة المهنية.
الحالة 2 - استراتيجية الكشف لدعوى جماعية للأجور والساعات لـ 10 موظفين (كاليفورنيا). المطالبة: 'بناء خطة كشف، مع إعطاء الأولوية للطلبات منخفضة التكلفة وعالية التأثير.' سيفترح محامٍ مبتدئ إفادات 30(b)(6) على الفور. الخطة الصحيحة تضع المذكرات المكتوبة قبل الإفادات، وتفصل شهادة الفئة عن الموضوع، وتشغل إشعار الانسحاب Belaire-West قبل الاتصال بأي عضو طبقة مفترض، وتستدعي بائع كشوف المرتبات من طرف ثالث (بيانات أنظف، أسرع، بدون تكلفة إنتاج من جانب الدفاع). التسلسل يهم أكثر من الجوهر.
الحالة 3 - حكم موجز بشأن عدم المنافسة في كاليفورنيا. فخّان. الفخ الأول: المطالبة تستشهد بـ 'Labor Code § 16600' - وهو استشهاد غير موجود. الاستشهاد الصحيح هو Business & Professions Code § 16600. الفخ الثاني: حتى مع تصحيح الاستشهاد، يخسر صاحب العمل بكل تأكيد تقريبًا. فقد وسع القانونان SB 699 و AB 1076 (النافذان اعتبارًا من 1 يناير 2024) المادة § 16600 وأضافا حقًا خاصًا في الدعوى مع أتعاب المحاماة. الخطوة الصحيحة هي نصح العميل بالتخلي عن إنفاذ اتفاق عدم المنافسة بالكامل والتحول إلى نظرية الأسرار التجارية بموجب CUTSA، إذا كانت الحقائق تدعم ذلك. المخطط الذي يجد أقصر مسار A* للفوز 'بشأن عدم المنافسة' يجد مسارًا إلى إيداع قابل للعقوبة.
تشترك هذه الحالات الثلاث في ميزة هيكلية: المخرجات الأكثر قيمة ليست خطة نحو الهدف المعلن للمستخدم. بل هي 'هدفك خاطئ؛ إليك الهدف الصحيح.'
هذا ليس ما يفعله A. A يجد أقصر مسار. سيجد أقصر المسارات لاستراتيجيات خاسرة.
جرّب HAQQ AI مجاناً
اختبر الصياغة والبحث القانوني بالذكاء الاصطناعي
أربع بوابات قبل أن نثق بهذا في التقاضي
إليكم ما يجب أن يتغير. لا شيء من هذا نظري - هذه هي البنود الأربعة على رأس خطة الإصدار 0.2.
1. يجب إعادة تصميم مكتبة الإجراءات من الألف إلى الياء. الإجراءات الهندسية لها بُعد تكلفة واحد (وقت المطور) وشروط مسبقة واضحة. الإجراءات القانونية لها شروط مسبقة خاصة بالاختصاص القضائي (ينطبق قانون FAA، المحكمة في كاليفورنيا، بند التحكيم يبقى ساري المفعول بموجب المادة 16600)، وشروط مسبقة قانونية، وشروط مسبقة خاصة بالجدول الزمني (الموعد النهائي للرد على المرافعة هو 21 يومًا)، وشروط مسبقة تخاصمية (لم يتقدم المحامي الخصم بعد بطلب X). كما أن بُعد التكلفة مختلف: التكلفة النقدية، ساعات الشركاء، خطر العقوبات، مخاطر تغيير الأتعاب. من المرجح أن تحتوي مكتبة الإجراءات القانونية الجادة على 200-500 إجراء مع مسندات مُعَلمَة - وهي أنطولوجيا حقيقية، كتبها المحامون المترافعون، ومحددة النطاق لكل مجال ممارسة.
2. يجب على محلل الأهداف التعامل مع اللغة الإنجليزية القانونية الحقيقية. `parse.js` عبارة عن جدول عبارات بخمسة مدخلات. يقوم بربط 'ship the auth refactor' بـ `{pr_open, ci_green, deployed}` عن طريق مطابقة السلسلة الفرعية. لا يمكنه تحليل 'win a Rule 12(b)(6) motion in a contract dispute where the contract has a clear arbitration clause.' الإصلاح صغير - Haiku في وضع JSON، مقيد بالنمط إلى المسندات المعروفة. حوالي نصف يوم. الأصغر من البوابات الأربع، وسخيف بدون الثلاثة الأخرى.
3. يجب أن يكون المخطط مستضافًا ذاتيًا. لا شيء يتعلق بمسائل العميل الحقيقية يقترب من `goal.ruv.io` أو أي عنوان URL لطرف ثالث. بصرف النظر عن مخاوف الامتياز، لا يمكنك تدقيق مخطط لا تقوم بتشغيله. مستضاف ذاتيًا، على بنية تحتية تحت سيطرة المحامي، مع سجلات يمتلكها المحامي. غير قابل للتفاوض بالنسبة لـ HAQQ.
4. يجب أن يعرف المخطط متى يرفض الهدف. الأصعب. مخطط A البحت الذي يجد دائمًا أقصر مسار سينفذ استراتيجيات خاسرة ببراعة. الإصلاح ليس مجرد إعادة تخطيط تكيفي (إعادة تشغيل A عند فشل إجراء). الإصلاح هو نقد الهدف: خطوة من Legal AI تعمل قبل التخطيط، تتحقق من الهدف مقابل المشهد العقائدي (المادة 16600 + مشروع قانون مجلس الشيوخ 699 + مشروع قانون الجمعية 1076 - 'إجراء الإنفاذ هذا خاسر')، وتظهر هدفًا بديلًا ('التحول إلى CUTSA'). إعادة التخطيط تعالج إخفاقات التنفيذ. نقد الهدف يعالج وضع الفشل الأعمق - الالتزام الكامل بهدف خاطئ. كلاهما مطلوب؛ ولم يتم تنفيذ أي منهما اليوم.
ما يعلمنا إياه الذكاء الاصطناعي في العمل القانوني
معظم منتجات الذكاء الاصطناعي تسعى لتحقيق 'أعطني إجابة واثقة'. هذا ليس الشكل الصحيح للتقاضي، حيث تتمثل المهمة في التشكيك في السؤال، وتحديد ما يعتقد العميل أنه يريده مقابل ما يحتاجه بالفعل، وإيجاد الخطوة التي كان الزميل المبتدئ سيفوتها.
GOAP أقرب إلى هذا الشكل من المحادثة. إنه صادق من الناحية الهيكلية: يخبرك عندما لا يتمكن من تحقيق الهدف. يظهر التسلسل، وليس فقط الاستنتاج. يمكن فحصه، تدقيقه، وإعادة تشغيله.
لكن 'أقرب من المحادثة' ليس 'جيدًا بما يكفي للعمل القانوني'. المعيار ليس 'ينتج خطة'. المعيار هو 'ينتج خطة يوافق عليها الشريك'. GOAP اليوم، بما في ذلك نظامنا، عند المستوى الأول. يجب أن يصل الإصدار التالي إلى المستوى الثاني. لا نعتقد أن أي شخص يبيع لك مخططًا اليوم - بما في ذلك نظامنا - يجب الوثوق به في مسألة حقيقية دون إغلاق وعرض البوابات الأربع المذكورة أعلاه.
إلى أين نتجه من هنا
- خطوة نقد الهدف (الإصدار 0.2). نمط JSON الخاص بـ Haiku 'فحص هذا الهدف مقابل المذهب؛ اقتراح بديل إذا كان محكومًا عليه بالفشل' تمرير قبل تشغيل المخطط.
- محلل أهداف Legal AI (الإصدار 0.2). استبدال جدول العبارات.
- إعادة التخطيط التكيفي (الإصدار 0.2). تضمين `plan()` في حلقة تنفيذ تعيد البحث عندما يفشل إجراء. حوالي 50 سطرًا.
- مكتبة الإجراءات القانونية (الإصدار 0.3). محددة النطاق حسب مجال الممارسة، مكتوبة بمراجعة من المحامين المتخصصين في التقاضي، مسندات معلمة. شهور من العمل، والمنتج الفعلي.
عندما تكون هذه الأربعة حقيقية ومختبرة، سوف نقوم بتشغيل حالات التقاضي الثلاث المذكورة أعلاه وننشر النتائج - بما في ذلك الإخفاقات، بما في ذلك نقد المحامي المتخصص في التقاضي. حتى ذلك الحين، المخرجات الصادقة الوحيدة هي هذه: مخطط هندسي يعمل، مخطط قانوني لا وجود له بعد، وملاحظات التصميم لما يجب أن يبدو عليه الثاني.
