ما الذي يبنيه هذا الشرح العملي فعليًا؟

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

هذا التمييز مهم. يذكر البحث المتحقق منه حول المساعدين المتكاملين للمهام والمعرفة أن أنظمة استدعاء الدوال المعتمدة على GPT-٤ تستجيب أحيانًا كما لو أن الإجراء اكتمل، رغم عدم استخدام دالة الإرسال. كما يذكر استدعاء API قبل الأوان، وعدم جمع جميع الحقول المطلوبة، وتوليد ردود وهمية في سيناريوهات إرسال التذاكر. لذلك يجب التعامل مع رد النموذج على أنه توصية إلى أن يتحقق التطبيق من نتيجة أداة حقيقية.

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

المتطلبات المسبقة وحدود الأدلة

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

يسمي البحث المتحقق منه GPT-٤ وClaude وLLaMA ٣ أمثلة على نماذج التوليد. لكنه لا يتحقق من GPT-٤o تحديدًا، أو نقطة نهاية API بعينها، أو ميزة محددة للمخرجات المنظمة. ولهذا يصف هذا الشرح حدّ النموذج بصورة عامة على أنه خدمة توليد معتمدة من فئة GPT-٤. وقبل التنفيذ، يجب على فريقك الهندسي تأكيد API الدقيق للمزود، وطريقة المصادقة، وعقد الاستجابة، وشروط معالجة البيانات.

ينطبق حد الأدلة نفسه على الأداء. استخدمت التجربة المذكورة نحو ١٫٢ مليون تذكرة وطلب سحب، ووجدت أن HNSW خفّض متوسط زمن الاستعلام بنسبة ٧٣٪ مقارنةً بفهرس Flat، مع انخفاض بنسبة ٢٪ في الاستدعاء. ويمثل ذلك سياقًا بحثيًا مفيدًا، لا وعدًا يناسب مجموعة بياناتك أو بنيتك التحتية أو مزيج لغاتك أو عبء العمل لديك.

الخطوة ١: حدّد قرار التوجيه قبل استدعاء النموذج

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

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

حدّد الحقول المطلوبة أيضًا. فقد يتطلب سير عمل إرسال التذكرة عنوانًا، ووصفًا، ومعرّف العميل، والأثر، والبيئة، وحالة التأكيد. ويحذّر البحث من أن مساعدي استدعاء الدوال المعتمدين على GPT-٤ قد يحذفون حقولًا مطلوبة وينتجون استدعاءات API غير مكتملة. لذلك ينبغي لتطبيقك رفض الطلبات الناقصة قبل التفكير في أي إجراء لاحق.

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

الخطوة ٢: أنشئ مجموعة بيانات الاسترجاع

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

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

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

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

الخطوة ٣: استرجع الأدلة وأعد ترتيبها

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

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

اختيار الفهرس عملية موازنة. قد يوفر فهرس Flat مقارنات دقيقة، لكنه قد لا يكون عمليًا على نطاق واسع. ويذكر البحث أن IVF يتوسع بكفاءة مع التضحية بجزء من دقة الاسترجاع، وأن HNSW حقق توازنًا بين زمن الاستجابة والاستدعاء في التجربة المذكورة. اختر الفهرس بعد قياسه على حالات ممثلة لبيئتك. ولا تعرض نتيجة خفض زمن الاستجابة بنسبة ٧٣٪ باعتبارها معيارًا مضمونًا لـ Next.js أو لبيئة الإنتاج.

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

الخطوة ٤: أنشئ Prompt للتوليد المستند إلى الأدلة

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

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

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

الخطوة ٥: اجعل Next.js حدّ التطبيق

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

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

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

الخطوة ٦: اختبر الهلوسة وفشل الاسترجاع

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

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

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

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

الخطوة ٧: أطلق النظام على مراحل

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

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

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

أهم الخلاصات

• استخدم embeddings لربط التذكرة الجديدة بالتذاكر السابقة وطلبات السحب والتعليقات.
• استرجع المرشحين، ثم أعد ترتيبهم باستخدام التشابه الدلالي والتداخل السياقي.
• تعامل مع النموذج من فئة GPT-٤ على أنه طبقة توصية تستند إلى الأدلة المسترجعة.
• تحقق من الحقول المطلوبة، ولا تفسر الادعاءات الواردة في اللغة الطبيعية على أنها دليل على تنفيذ أداة.
• استخدم HNSW أو IVF أو Flat فقط بعد قياس موازنة الاسترجاع على مجموعة بياناتك الخاصة.
• قيّم الاسترجاع والتوليد والإجراءات اللاحقة باعتبارها إمكانات منفصلة للنظام.
• أطلق النظام عبر الاختبار غير المتصل، ووضع الظل، والموافقة البشرية، والأتمتة محدودة النطاق.

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