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

نشر إيليا باراموشين، المهندس الأول في MTS Web Services، على 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 المؤسسية: من روبوت دردشة محدود فوق الوثائق إلى بنية تحتية تجمع بين البحث وبيانات التشغيل وأتمتة العمليات الروتينية المرتبطة بتذاكر الدعم. وتوثّق المقالات الثلاث في سلسلة Habr، من معمارية البحث إلى وكيل الذكاء الاصطناعي ثم إلى الوصول عبر MCP والسجلات، كيف تتغير متطلبات مساعدي الذكاء الاصطناعي المؤسسيين مع استخدام المهندسين لهم لا لقراءة الوثائق فحسب، بل للتحقيق في الحوادث أيضًا.