MTS: من RAG إلى الوكلاء — تحليل تذاكر Jira عبر MCP والسجلات

نشر الرئيس الرئيسي للمهندسين في خدمات MTS الويب، إلياس باراموشين، على Habr المقالة الثالثة من سلسلة حول تطوير مساعد RAG لدعم تقني — هذه المرة عن الانتقال من البحث عن المستندات إلى منصة مع وصول MCP إلى السجلات وقواعد البيانات والتحليل التلقائي لتذاكر Jira.

ثلاثة مقالات في سلسلة واحدة

تستمر المادة سلسلة من منشورين سابقين للمؤلف نفسه على Habr. كانت المقالة الأولى مكرسة لعمارة مساعد RAG (Retrieval-Augmented Generation — توليد الاستجابة بناءً على المستندات المسترجعة) لدعم تقني: فهرسة Confluence و Jira، والبحث الهجين، وتوليد الاستجابة مع الاستشهادات، وتقييم جودة البحث. المنشور الثاني، الأخير، قال كيف بنى MTS Web Services وكيل ذكاء اصطناعي لتحليل التذاكر التلقائي.

• المؤلف — إلياس باراموشين، الرئيس الرئيسي للمهندسين في MTS Web Services
• المقالة الأولى من السلسلة — هندسة مساعد RAG لدعم تقني (فهرسة Confluence و Jira، والبحث الهجين، وتقييم الجودة)
• المقالة الثانية — وكيل ذكاء اصطناعي لتحليل التذاكر التلقائي
• المقالة الثالثة (النقاش هنا) — MCP، والسجلات ومسار التذكرة من الإنشاء إلى التعليق

لماذا كان RAG بحاجة إلى السجلات و MCP؟

بعد تنفيذ مساعد RAG، بدأ المهندسون في الشركة يجدون الإرشادات واللوائح المطلوبة بشكل أسرع — هذا تأثير مباشر لأول نسخة من النظام، والتي يلاحظها باراموشين. ومع ذلك، كان التحقيق من الحوادث يتطلب العمل مع السجلات وقواعس البيانات و Jira نفسه، وليس فقط النصوص الموثقة في Confluence. لهذا السبب قررت الفريق توسيع النظام خارج البحث بدلاً من حصر أنفسهم في تحديثات قاعدة المعرفة.

كيف تم تنظيم المنصة الجديدة

لم يعيد مهندسو MTS Web Services كتابة نظام RAG من الصفر، بل طوروه كمنصة حول ثلاث مهام.

"لم نعد كتابة RAG، بل بدأنا في تطويره كمنصة حول ثلاث مهام: واجهة موحدة، والوصول إلى البيانات التشغيلية، والتحليل الآلي للتذاكر", — إلياس باراموشين، الرئيس الرئيسي للمهندسين في MTS

Web Services، في مقالة على Habr.

بقي البحث في قلب المنصة، لكن ظهرت خدمات منفصلة حوله: بعضها للعمل التفاعلي للمهندس أثناء التحقيق، وبعضها لتحليل التذاكر في الخلفية بدون مشاركة بشرية. من بين الثلاث مهام التي تم بناء المنصة حولها، الأولى هي واجهة موحدة يمكن من خلالها للمهندس الوصول إلى البحث عن المستندات والخدمات الأخرى. الثانية هي الوصول إلى البيانات التشغيلية: السجلات وقواعس البيانات و Jira نفسه، والمطبق، كما يحكم من عنوان المقالة، من خلال بروتوكول MCP (Model Context Protocol) — معيار مفتوح يوفر للوكلاء الذكاء الاصطناعي وصولاً منظماً إلى مصادر البيانات الخارجية بدلاً من التكامل منفصل لكل خدمة. المهمة الثالثة هي تلقائية تحليل التذاكر، أي نقل جزء من العمل الروتيني للمهندس إلى خدمات الخلفية.

وفقاً للمؤلف، تناقش المقالة أيضاً هندسة الحل نفسه، والأسباب التي أدت إلى فصل مكونات معينة من نظام RAG إلى خدمات مستقلة، ومسار التذكرة — من الإنشاء إلى تعليق Jira الذي تم إنشاؤه تلقائياً. تحمل المادة عنوان "الحياة بعد RAG: MCP والسجلات والتحليل التلقائي لتذاكر Jira" — يشير العنوان مباشرة إلى تحول التركيز: من البحث البحت عن قاعدة المعرفة إلى العمل مع البيانات التشغيلية المباشرة.

ما يعنيه هذا

يظهر حالة MTS Web Services مسارًا نموذجيًا لتطور نظام RAG الذي يتعلق بالشركات: من chatbot واحد فقط على التوثيق — إلى بنية أساسية تجمع البحث والبيانات التشغيلية والأتمتة لعمليات تذاكر الدعم الروتينية. ثلاث مقالات في سلسلة واحدة على Habr — من هندسة البحث إلى وكيل الذكاء الاصطناعي ثم إلى وصول MCP والسجلات — تلتقط كيف تتغير متطلبات مساعدات الذكاء الاصطناعي في الشركات عندما يستخدمها المهندسون ليس فقط لقراءة التوثيق، بل لتحقيق الحوادث.

الأسئلة الشائعة

ما هو MCP ولماذا هو ضروري؟

MCP (Model Context Protocol) هو معيار مفتوح يوفر للوكلاء الذكاء الاصطناعي وصولاً منظماً إلى مصادر البيانات الخارجية — السجلات وقواعس البيانات وأنظمة التذاكر — بدلاً من الحاجة إلى تكامل منفصل لكل خدمة.

لماذا خدمات منفصلة بدلاً من نظام RAG موحد؟

فصل المكونات يسمح للمنصة بتحسين كل مهمة بشكل مستقل: البحث التفاعلي عن التوثيق، والتحليل في الخلفية للسجلات، والتوجيه الآلي للتذاكر — لكل منها متطلباتها و SLAs الخاصة.

كيف يختلف هذا عن أنظمة RAG الأخرى للشركات؟

تبقى معظم تطبيقات RAG الخاصة بالشركات مركزة فقط على البحث. تطورت MTS الخاصة بها لتشمل تكامل البيانات التشغيلية والأتمتة — مما يجعل المنصة مناسبة للتحقيق من الحوادث، وليس فقط البحث عن التوثيق.