كيف تُثري وكلاء QA قاعدة المعرفة بأنفسهم وتختصر البحث عن سبب الخلل من ساعتين إلى 10 دقائق

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

فريق الاختبار في «تيخفيل» حلّ هذه المشكلة بمنصة مستقلة هي MKP (Multi knowledge platform). نشرح أدناه كيف تعمل وما الذي يمكن الاستفادة منه.

ما هي MKP وكيف تبحث

MKP منصة داخلية تضم قواعد معرفة وبحثًا ذكيًا. هناك نوعان من القواعد: evawiki المدمجة التي تحوي وثائق الشركة (عبر MKP يمكن القراءة منها فقط)، وقواعد markdown الخاصة بالفرق حيث يمكن إنشاء الوثائق وتحديثها وحذفها والبحث فيها بحسب المعنى. يمكن العمل عبر واجهة الويب وREST API وخادم MCP للوكلاء في Cursor وClaude Code وCodex. في MCP خمس أدوات فقط: قائمة القواعد، استعلام دلالي، جلب وثيقة برقمها، إنشاء أو تحديث، حذف ناعم.

تحت الغطاء يوجد RAG، لكنه ليس الأبسط. فـ Hybrid dense/sparse retrieval يجمع بين البحث الدلالي والبحث بالكلمات المفتاحية. وهذا حاسم في QA: فالمعرّفات مثل GetExists وis_pickup وCMA-14699 يميل البحث المتجهي الصرف إلى فقدانها. بعد ذلك يأتي multi-query (يعيد النموذج صياغة السؤال) وreranking وparent-child retrieve: نبحث في مقاطع صغيرة، ونقدّم سياق القسم كله. وفي الإجابة دائمًا النص، والمصادر مع score وsnippet، إضافة إلى trace_id للتشخيص.

الوكيل يكتب في القاعدة بنفسه

الفكرة الرئيسية أن أحدًا لا يضع الوثائق يدويًا، وإلا فبعد نصف عام سنحصل على ويكي مهجورة أخرى. بدلًا من ذلك دُمجت MKP في QA-kit، وهو مستودع قواعد وskills لـ Cursor وClaude Code. يعمل الوكيل كمحرر: ينتقي من الجلسة المعرفة المتحقق منها، ولا يصبّ الحوار كله في القاعدة.

لكل مجال (الكتالوج، البحث، التوصيات وغيرها) أُنشئت أربع قواعد:

• wiki — معارف ثابتة: البنية، البيئات، المحاكيات، «كيف نتحقق بشكل صحيح»؛
• outputs — النصوص الكاملة لخطط الاختبار ونتائجه وتعليقاته في Tracker؛
• daily — سجلات يومية وفهرس index؛
• artifacts — أدلة خام: curl وSQL وJSON والمحاكيات.

قبل عرض خطة الاختبار يلزم الوكيل بإجراء أربع عمليات بحث: هل أُجري اختبار إعادة بأرقام الوثائق الدقيقة، وما الذي رُصد في حالات مشابهة في outputs، وماذا يعرف الفريق عن الخدمة في wiki، وماذا يقول المنتج في eva-wiki. وبعد الاختبار يسجّل الخطة والنتيجة والتعليق في outputs، واليوم في daily، والحقيقة الثابتة الجديدة في wiki.

ما الذي يعطيه ذلك عمليًا

الواجهة الفارغة: صار السؤال الموجّه إلى catalog-wiki يعيد قائمة تحقق من تسع نقاط خلال 24 ثانية. فيها ذاكرة التوافر، والطلبات المسبقة، وأولوية المحاكي في WireMock، ورمز 403 من وكيل البحث. يجتازها مختبر QA في عشر دقائق بدلًا من ساعتين. لم يكتب أحد هذه القائمة كمقالة: فقد جُمعت من تحليلات المهام التي أضاف إليها الوكيل الحقائق واحدة تلو الأخرى.

مهمة بدائل المنتجات: يستخرج الوكيل مسبقًا نتائج تشغيلين سابقين. يعرف مختبر QA الجديد أي fixtures يجب تحضيرها، ولا يفتح DEFECT زائفًا على مسار legacy لا يمكن بلوغه (فقد وسمه زميل بـ QUESTION)، ويضيف فورًا فحصًا لمعرفة هل ما زال في البيئة شيفرة قديمة بلا مرشّح. ويرى القائد من فهرس daily ما فعله الفريق دون اجتماع حالة منفصل.

الصلاحيات والانضباط

الوصول منظَّم بصرامة. هناك دوران: admin وuser، وتُمنح صلاحيتا read وwrite لكل قاعدة على حدة. يُنشأ لكل وكيل مستخدم منفصل بأدنى الصلاحيات، ويمكن حرمان المستخدم التقني من الدخول إلى الواجهة. يقرأ الوكيل قواعد مجاله وeva-wiki، ويكتب في قواعده الأربع فقط. يُحدَّد مؤلف الوثيقة بمفتاح API، ويظهر الفريق في البيانات الوصفية. وسجل الصلاحيات محفوظ في git.

القيود والخلاصة

لا يتضمن المقال تقييمًا لجودة السجلات ولا كيفية استبعاد المعرفة الخاطئة التي تصل إلى wiki، مع أن الوكيل يكتب فيها بنفسه. وأرقام توفير الوقت داخلية وتُعرض على أمثلة منفردة. كما أن الوثيقة الجديدة لا يمكن البحث عنها فورًا: فهي تمر أولًا بحالة processing.

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