ذكاء هندسي وكيل بمساعدة Amazon Nova Multimodal Embeddings وAmazon Bedrock AgentCore

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

أظهر منشور سابق، Manufacturing intelligence with Amazon Nova Multimodal Embeddings، كيف يسترد النموذج الأجوبة المحبوسة داخل المخططات الهندسية ومنحنيات الحرارة ورسوم بيانية صحائف البيانات التي تفوّتها خطوط المعالجة النصية فقط. يتولى هذا المنشور المهمة من حيث انتهى عمل الاسترجاع ذاك، بوضع تلك القدرات داخل نظام متعدد الوكلاء يجمع أدلة الاستبدال، من الاسترجاع إلى مسودة تقييم.

في هذا المنشور، نوضح كيفية بناء مساعد هندسي متعدد الوكلاء يقلّص المطابقة اليدوية وراء تقييم استبدال القطع باستخدام Amazon Bedrock AgentCore, وAmazon Nova Multimodal Embeddings، ومكتبة مفتوحة المصدر Strands Agents SDK. يوجه المخطِّط العمل عبر ثلاثة وكلاء متخصصين يبحثون في قاعدة معرفة متعددة الوسائط، ويسجّلون نقاط المرشحين وفق قواعد سماحيات حتمية، ويقارنون صور القطع، ويرسّكون ادعاءات دورة الحياة في بيانات ويب حية. يبقى المهندس صانع القرار طوال الوقت، لأن النظام يجمع الأدلة ويصيغ المستندات دون أن يوافق أبدًا على استبدال من تلقاء نفسه.

نظرة عامة على الحل

يُبنى المساعد حول قاعدة تصميم واحدة، وهي أن المهندس يتخذ كل قرار والنظام يجمع الأدلة له. تحدد تلك القاعدة أين نستخدم نماذج اللغة الكبيرة (LLMs) وأين نستخدم بدلًا منها كودًا حتميًا.

ثلاثة أعمدة تحدد المعمارية:

• التقييم الحتمي لتوافق المواصفات – كود قواعد السماحيات مكتوب بلغة Python يقيّم كل قطعة مرشحة مقارنةً بالقطع المرجعية وبمتطلبات المهندس المعلنة. ولأن المدخلات نفسها تنتج باستمرار أحكام النجاح/الإشارة نفسها، يمكن إدراج النتائج في مراجعة هندسية رسمية.
• تنسيق متعدد الوكلاء – يوجه مخطِّط خفيف كل استعلام إلى واحد أو أكثر من ثلاثة وكلاء متخصصين (الكتالوج، التقييم، المعرفة)، ويجمع المشرف نتائجهم فقط عندما يساهم أكثر من متخصص. الأسئلة المعقدة مثل «تحقق مما إذا كانت هذه العجلة ستصل إلى نهاية عمرها الإنتاجي، وابدل عنها بدائل، وسجّل نقاطها» تربط المتخصصين الثلاثة بالتتابع.
• قرار بشري في الحلقة – يصيغ النظام مسودات مذكرات المبررات وتقييمات الأثر التكاملي للمراجعة الهندسية، لكنه لا يوصي باستبدال ولا يوافق عليه. كما يكتب كل تقييم سجل تدقيق متوافقًا مع القسمين 8.4 و8.5.6 من AS9100.

يوضح المخطط التالي المعمارية.

الشكل 1: معمارية المساعد الهندسي متعدد الوكلاء على Amazon Bedrock AgentCore

Amazon Bedrock AgentCore منصة لبناء الوكلاء وتوصيلهم وتحسينهم على نطاق واسع، بأي إطار عمل أو نموذج. في هذا الحل، تتدفق طلبات الدردشة من تطبيق المهندس إلى مخطط وكلاء متعدد مستضاف على AgentCore runtime: مخطِّط (Claude Haiku 5.5) ينتج خطة توجيه، ومتخصصون (Claude Sonnet 5.5) ينفذون أدواتهم، ومشرف (Claude Opus 5.5) يجمّع نتائجهم عندما يعمل أكثر من متخصص. يسترد المتخصصون من قاعدة معرفة مُدارة أنشأناها بـ Amazon Bedrock Managed Knowledge Bases باستخدام Amazon Nova Multimodal Embeddings، موجهة عبر AgentCore Gateway، وهي إمكانية من Amazon Bedrock AgentCore، إلى جانب موصل Web Search لبيانات الويب الحية. للصورة كاستعلام (رفع مخطط لتحديد قطعة)، يستدعي الوكيل فهرس Amazon S3 Vectors الأصلي مباشرةً، لأن واجهة استرجاع قاعدة المعرفة المُدارة لا تقبل إدخال الصور. Amazon S3 Vectors إمكانية من Amazon Simple Storage Service (Amazon S3). وتنتج سلسلة ثابتة منفصلة (المعرفة، ثم التقييم، ثم المشرف) المستند الرسمي لتقييم الأثر التكاملي (IIA).

يظهر Amazon Nova Multimodal Embeddings في دورين مختلفين:

1. الاسترجاع متعدد الوسائط – تُضمَّن صحائف البيانات ومستندات ICD ومخططات الأداء باستخدام Nova Multimodal Embeddings بحيث تشترك المحتويات النصية والبصرية في فضاء دلالي واحد. يمكن للمهندس إدخال «منحنى العزم للعجلة 0.06 Nms» أو رفع صورة مخطط، فيرجع الاسترجاع المخطط المطابق مع إسناد المصدر.
2. تسجيل التشابه البصري – عند مقارنة جزأين مرشحين، تُنتج Nova Multimodal Embeddings درجة تشابه جيب التمام الكمية بين صورهما، ويحلل Claude الفروق المادية المحددة (نمط التثبيت، موضع الموصل، هندسة الهيكل). تضيف الدرجة أدلة داعمة إلى مقارنة المواصفات الحتمية، وهي التي يستند إليها حكم التوافق.

المتطلبات الأساسية

للمتابعة، تحتاج إلى:

• حساب AWS مع صلاحية الوصول إلى Amazon Bedrock في منطقة AWS US East (N. Virginia).
• صلاحية الوصول إلى النماذج Amazon Nova Multimodal Embeddings وClaude Haiku 5.5 وClaude Sonnet 5.5 وClaude Opus 5.5 في Amazon Bedrock. لمعرفة توفّر النماذج حسب المنطقة، راجع دعم النماذج حسب منطقة AWS في Amazon Bedrock.
• قاعدة معرفة مُدارة تم إنشاؤها باستخدام Amazon Bedrock Managed Knowledge Bases، باستخدام Amazon Nova Multimodal Embeddings على مجموعة أجزائك (أوراق البيانات، ملفات ICD، الأوصاف) لاسترجاع النصوص والمستندات.
• فهرس Amazon S3 Vectors فوق صور أجزائك ومقتطفات مخططات أوراق البيانات، لمسار استخدام الصورة كاستعلام.
• بوابة Amazon Bedrock AgentCore Gateway مع موصل البحث على الويب وهدف قاعدة معرفة مُدارة.
• Python بالإصدار 3.10 أو أحدث وJupyter لتشغيل دفاتر الملاحظات.
• Docker، إذا كنت تكيّف وصفة النشر في دفتر الملاحظات 03 لاستضافة الوكيل على بيئة تشغيل AgentCore.
• الشيفرة البرمجية النموذجية من مستودع GitHub.

جولة في الحل

تصف الأقسام التالية كل جزء من النظام بالترتيب الذي يستخدمه به الاستعلام. نبدأ بمجموعة الأجزاء والوكلاء المتخصصين، ثم نغطي التوجيه، والتسجيل الحتمي، والطريقتين اللتين يستخدم بهما المساعد Nova Multimodal Embeddings، والسلسلة الثابتة التي تُنتج المستندات الرسمية، والنشر على بيئة تشغيل AgentCore.

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

هيكلة مجموعة الأجزاء

مجموعة البيانات النموذجية هي سبع عجلات تفاعل من شركة خيالية (AnyCompany) تمتد عبر 0.003–5.0 Nms من تخزين كمية الحركة. كل جزء هو مجلد يجمع بين البيانات المهيكلة والمستندات المصدرية التي يقرأها المهندس فعلًا، وهذا المزيج هو ما يجعل المجموعة متعددة الوسائط. يحمل ملف specs.json الحقول القابلة للقراءة آليًا التي تُغذي التسجيل الحتمي، بينما يحمل ملف ICD وصورة المنتج وصفحة ورقة البيانات المصيّرة التفاصيل البصرية والسرديّة التي تتركها الحقول المهيكلة خارج الحساب.

data/synthetic-parts-data/rw_rl_0060/
├── specs.json # structured specs + lifecycle fields
├── description.txt # flat text for text retrieval
├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf
├── datasheet_page.png # rendered datasheet page
├── datasheet_chart.png # cropped chart region (image-as-query index)
└── photo.png # product image (visual similarity + chart matching)

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

{
  "name": "AnyCompany RW3 0.06",
  "category": "reaction_wheel",
  "vendor": "AnyCompany",
  "model": "RW3-0.06",
  "momentum_storage_nms": 0.06,
  "max_torque_mnm": 20,
  "mass_g": 235,
  "voltage_v": "28",
  "voltage_range_v": "7.5 to 36",
  "operating_temp_c": "-30 to +70",
  "interface": "RS-422 or Redundant RS-485",
  "qual_standard": "AnyCompany internal (flight heritage qualified)",
  "lifecycle": {
    "lifecycle_status": "Active",
    "production_status": "Full production",
    "estimated_years_to_eol": "10+",
    "last_time_buy": "Not announced",
    "typical_lead_time_weeks": 10,
    "lead_time_risk": "Low",
    "bathtub_region": "Useful life (highly mature)",
    "recommended_screening": "Standard flight acceptance"
  }
}

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

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

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

الشكل 2: أربع صفحات من أوراق البيانات من مجموعة الأجزاء، تمتد عبر ثلاثة أُسّ من حيث مقدار تخزين كمية الحركة

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

تعريف المتخصصين بأدوات محدودة النطاق

كل متخصص هو وكيل Strands بموجة توجيه (prompt) محددة وبالأدوات التي يحتاجها فقط. تحديد نطاق الأدوات لكل متخصص يحافظ على سلوك يمكن التنبؤ به، لأن متخصص المعرفة لا يحصل على أي وصول إلى أدوات استكشاف الكتالوج، ومتخصص الكتالوج لا يحصل على أي وصول إلى أدوات التقييم. الشيفرة التالية تنشئ متخصص التقييم.

from strands import Agent

def create_evaluation_specialist() -> Agent:
    """Evaluation Specialist: deterministic spec-by-spec comparison and scoring."""
    return Agent(
        name="evaluation_specialist",
        system_prompt="""You are the Evaluation Specialist. Your job is to run
deterministic, spec-driven comparisons between parts.
...
RULES:
- Your comparisons are deterministic (code, not opinion)
- NEVER recommend or approve --- present evidence and flags; the engineer decides
- Always include the disclaimer that this is evidence only""",
        tools=[score_substitution_fit, compare_parts, visual_similarity_score,
               check_qualification_status, generate_substitution_memo],
        model="us.anthropic.claude-sonnet-5-5",
    )

يوضح المخطط التالي كيف يوجه المخطِّط الاستعلام إلى المتخصصين ومتى يُركِّب المشرف نتائجهم. تصف القائمة التي تليه ما يقوم به كل متخصص.

الشكل 3: كيف يوجه المخطِّط الاستعلامات إلى المتخصصين ومتى يُركِّب المشرف النتائج

• الكتالوج – يكتشف الأجزاء من خلال البحث في قاعدة المعرفة والتصفية الشاملة للمواصفات (kb_search, filter_parts_by_spec, get_part_specs, get_substitution_requirements).
• التقييم – يقيّم المرشحين بطريقة حتمية ويقارن الأجزاء بصريًا (score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo).
• المعرفة – يجيب عن الأسئلة المستمدة من أوراق البيانات ومستندات ICD، ويتحقق من حالة نهاية العمر الفعلية، ويسترجع المحتوى المرئي (get_part_specs, web_search_eol, retrieve_visual_content).

استخدم نموذجًا صغيرًا للتوجيه ونموذجًا كبيرًا للتركيب

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

# Step 1: Planner (fast model) plans the routing (may be multi-step).
plan_response = planner(planning_prompt)
ordered_specialists = _parse_specialist_plan(str(plan_response))

# Step 2: Execute specialists in sequence, passing context forward
accumulated_context = ""
for spec_name in ordered_specialists:
    specialist = specialists[spec_name]
    specialist_response = specialist(spec_prompt)
    accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n"

# Step 3: Synthesize only when 2+ specialists ran.
if len(ordered_specialists) == 1:
    final_text = steps[0]["response"]
else:
    final_text = str(supervisor(synthesis_prompt))

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

اجعل التقييم العددي حتميًا

يُنفَّذ تقييم مطابقة المواصفات كشيفرة Python عادية مقابل مخطط متطلبات مكتوب يدويًا. يحدّد المخطط المواصفات الحرجة وقواعد التفاوت لكل فئة من المكونات، و score_substitution_fit يقارن كل مواصفة، ويحصي النجاحات والعلامات، ويكشف مخاطر دورة الحياة. ولأن الحكم يجب أن يكون قابلاً لإعادة الإنتاج ضمن حزمة مراجعة هندسية، لا يُستخدم أي LLM في هذه الخطوة.

{
  "categories": {
    "reaction_wheel": {
      "critical_specs": [
        {"field": "voltage_v", "label": "Bus voltage (V)",
         "rule": "match", "required_from_user": true},
        {"field": "mass_g", "label": "Mass (g)",
         "rule": "candidate_lte_reference_within_pct", "tolerance_pct": 20,
         "required_from_user": false}
      ]
    }
  }
}

تُعيد الأداة حكمًا منظمًا مع تنويه صريح:

return {
    "spec_results": results,  # per-spec pass/flag/review status
    "counts": counts,
    "out_of_tolerance": out_of_tolerance,
    "lifecycle": {...},  # obsolescence and lead-time flags
    "summary": summary,
    "disclaimer": "Evidence only. This tool does not recommend or approve "
                  "a substitution; the engineer decides.",
}

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

تقييم التشابه البصري باستخدام Amazon Nova Multimodal Embeddings

شكل الجهاز مهم عندما يجب أن يتناسب البديل مع حامل موجود مسبقًا. تقوم أداة visual_similarity_score بتضمين صورتي الجزء باستخدام Nova Multimodal Embeddings وحساب تشابه جيب التمام (cosine similarity)، ثم تطلب من Claude وصف الفروقات الملموسة القابلة للملاحظة.

def embed_image(image_bytes):
    """Embed one image with Nova MME (IMAGE_RETRIEVAL) -> 1024-d vector."""
    b64 = base64.b64encode(image_bytes).decode('utf-8')
    fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg'
    body = {
        'taskType': 'SINGLE_EMBEDDING',
        'singleEmbeddingParams': {
            'embeddingPurpose': 'IMAGE_RETRIEVAL',
            'embeddingDimension': 1024,
            'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt,
                      'source': {'bytes': b64}},
        },
    }
    resp = bedrock.invoke_model(
        modelId='amazon.nova-2-multimodal-embeddings-v1:0',
        body=json.dumps(body), accept='application/json',
        contentType='application/json',
    )
    result = json.loads(resp['body'].read())
    return np.array(result['embeddings'][0]['embedding'])

# cosine similarity of the two photo embeddings
emb_a, emb_b = embed_image(photo_a_bytes), embed_image(photo_b_bytes)
similarity = float(np.dot(emb_a, emb_b) /
                   (np.linalg.norm(emb_a) * np.linalg.norm(emb_b)))

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

استرجاع المخططات والرسوم التوضيحية عبر مسارين للاسترجاع

تمرّ استعلامات النصوص والمستندات عبر قاعدة المعرفة المُدارة المدعومة بـ Amazon Nova Multimodal Embeddings، والموجّهة عبر AgentCore Gateway. أما الاستعلام بالصورة (رفع مخطط أو صورة للعثور على محتوى مطابق) فيستخدم فهرس Amazon S3 Vectors أصليًا يُستدعى مباشرة من الوكيل، لأن واجهة برمجة التطبيقات للاسترجاع في قاعدة المعرفة المُدارة لا تقبل إدخال الصور.

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

# Image-as-query: embed the uploaded image with Nova MME, exactly as the
# datasheet crops and photos were embedded at indexing time.
def embed_query_image(image_bytes):
    b64 = base64.b64encode(image_bytes).decode('utf-8')
    fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg'
    body = {'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': {
        'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024,
        'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt,
                  'source': {'bytes': b64}}}}
    r = bedrock.invoke_model(modelId=NOVA_MME_MODEL_ID, body=json.dumps(body),
                             accept='application/json', contentType='application/json')
    return json.loads(r['body'].read())['embeddings'][0]['embedding']

في مسار الصور، يُضمَّن الملف المرفوع باستخدام Nova Multimodal Embeddings بـ 1,024 بُعدًا لغرض IMAGE_RETRIEVAL ، ثم يُطابق مقابل فهرس S3 Vectors:

# Query the native S3 Vectors index and collapse to the best vector per part.
emb = embed_query_image(image_bytes)
s3v = boto3.client('s3vectors', region_name=REGION)
fetch_k = max(top_k * 6, 12)  # each part has several vectors; dedupe below
resp = s3v.query_vectors(
    vectorBucketName=S3_VECTOR_BUCKET, indexName=S3_VECTOR_INDEX,
    queryVector={'float32': emb}, topK=fetch_k,
    returnDistance=True, returnMetadata=True,
)

best = {}
for v in resp.get('vectors', []):
    meta = v.get('metadata', {}) or {}
    pid = meta.get('part_id', '')
    if not pid:
        continue
    sim = 1.0 - v.get('distance', 1.0)  # cosine distance -> similarity
    if pid not in best or sim > best[pid]['score']:
        best[pid] = {'part_id': pid, 'score': sim}
ranked = sorted(best.values(), key=lambda r: r["score"], reverse=True)[:top_k]

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

تعلمنا ثلاثة دروس عملية أثناء بناء مسارات الاسترجاع:

• قص المخططات قبل فهرستها – صفحات أوراق البيانات الكاملة تُعد إدخالات فهرسة رديئة، لأن حوالي 90 بالمئة من الصفحة (الترويسة، جدول المواصفات، التذييل) عبارة عن محتوى ثابت مشترك بين جميع الأجزاء، وهذا المحتوى المشترك يهيمن على التضمين. حلّنا هذه المشكلة بفهرسة مناطق المخططات المقصوصة إلى جانب الصفحة الكاملة. في اختباراتنا، تحسّنت مطابقة رفع المخططات من 3 من 7 أجزاء صحيحة مع فهرسة الصفحة الكاملة إلى 7 من 7 مع قص نطاقات المخططات. نحدد مناطق القص كنسب من الصفحة، مما يحافظ على صحتها عبر دقات مختلفة لأوراق البيانات.
• تصفية النتائج عندما يذكر المهندس جزءًا محددًا – التشابه عبر الوسائط من نص إلى صورة وحده لا يُعيد بشكل موثوق مخطط الجزء الصحيح، لأن صورة منحنى العزم لا تحتوي على اسم جزء مرئي. عندما يذكر المهندس جزءًا محددًا، تحتفظ الأداة فقط بالنتائج من المحتوى المفهرس لذلك الجزء، الذي تحدده بتحليل مجلد الجزء من عنوان S3 URI لكل نتيجة. ولأن التصفية تعمل داخل الأداة، فهي تعمل دون الحاجة إلى بيانات وصفية مخصصة في الفهرس.
• تسجيل كل تراجع (fallback) في مسار الصور – يُعيد مسار الصور None عند الأخطاء ويتحول إلى الاسترجاع النصي. هذا التراجع منطقي، لكنه يعني أن غياب s3vectors:QueryVectors في الأذونات على دور تنفيذ AgentCore runtime لا يُطلق خطأً. يتوقف الاستعلام بالصورة عن العمل دون تحذير، ثم يذكر النموذج جزءًا خاطئًا بثقة ظاهرية عالية. المشكلة سهلة الإغفال أثناء التطوير، لأن بيانات اعتماد المطور المحلية عادةً ما تكون لها أذونات أوسع من دور runtime. أصبحت الأداة الآن تسجّل S3 Vectors image query FAILED سجّل تحذيرًا مع اسم الحاوية (bucket) والفهرس والمنطقة (Region) كلما تراجع هذا المسار إلى بديل. راقب كل تراجع صامت في مسار الاسترجاع، لأن الفشل الصريح أسهل بكثير في التشخيص من الفشل الصامت.

أنتج مستندات رسمية بسلسلة متخصصين ثابتة

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

# 1. Knowledge Specialist --- ICD/datasheet interface detail for both parts
knowledge_text = str(knowledge(knowledge_prompt))

# 2. Evaluation Specialist --- structured field delta + qualification check
evaluation_text = str(evaluation(evaluation_prompt))

# Deterministic structured delta for exact summary stats
comparison = compare_parts(reference_id, candidate_id)

# 3. Supervisor --- synthesize into the six-section IIA document
markdown = str(supervisor(synthesis_prompt))

تغطي الوثيقة الناتجة تغييرات الواجهة، والتكامل الميكانيكي، والتكامل الكهربائي، والتكامل الحراري، وفرق التأهيل، وأثر سلسلة التوريد. تحتاج الأقسام السردية إلى تركيب بواسطة نموذج لغوي كبير (LLM)، لأن تفاصيل توزيع الأرجل والبروتوكولات يجب استخراجها من نصوص ICD النثرية. أما إحصاءات الملخص (التطابقات، والاختلافات، وإجمالي الحقول) فتُحسب مباشرة من compare_parts المخرجات، لذا فإن الأرقام المعروضة بجانب السرد دقيقة.

أسند ادعاءات دورة الحياة إلى بيانات ويب حية عبر AgentCore Gateway

تتقادم بيانات الكتالوج، لذا يتحقق web_search_eol أداة specialist المعرفة من إشعارات نهاية العمر الحالية وإعلانات الموردين وأزمنة التسليم عبر AgentCore Gateway مع موصل Web Search. يعرض Gateway الموصل كنقطة نهاية محكومة وفق بروتوكول سياق النموذج (MCP). ولأن Gateway يتولى أيضًا الاسترجاع المُدار من قاعدة المعرفة، يمكنك إرفاق السياسات والمراقبة بكل من الوصول إلى البيانات الخارجية والداخلية في مكان واحد.

النشر إلى AgentCore runtime

لبيئة الإنتاج، تُغلّف الوكيل كحاوية ARM64، وتُرسله إلى Amazon Elastic Container Registry (Amazon ECR)، ويستضيفه AgentCore runtime بطريقة بلا خادم مع عزل الجلسات والتوسع التلقائي. تستعرض دفتر الملاحظات 03 في مستودع GitHub عملية النشر هذه كوصفة مرجعية، وتغطي Dockerfile وأوامر البناء والإرسال وأذونات دور التنفيذ وسياسة Cedar. تعرض دفتر الملاحظات هذه الخطوات دون تنفيذها. إذ يغلّف Dockerfile الخاص به شيفرة تطبيق تتجاوز النموذج التوضيحي، لذا اجعله ملائمًا لتخطيط تطبيقك الخاص قبل البناء. يوضح المخطط التالي مسار النشر من شيفرة الوكيل إلى نقطة نهاية مستضافة على AgentCore runtime.

الشكل 4: مسار النشر من شيفرة الوكيل إلى نقطة نهاية مستضافة على AgentCore runtime

export TAG=mei-$(date +%Y%m%d-%H%M%S)
export ACCOUNT=<your-account-id>
export ECR=${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/mfg-engineering-intelligence

# Build the container for ARM64 (required by AgentCore Runtime)
docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \
  -t mfg-engineering-intelligence:${TAG} --load .

# Push the immutable tag to Amazon ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com
docker tag mfg-engineering-intelligence:${TAG} ${ECR}:${TAG}
docker push ${ECR}:${TAG}

أعطِ كل صورة وسمًا غير قابل للتغيير. بيئة runtime التي تكون قد حلت مسبقًا البصمة خلف وسم متغير :latest تواصل تقديم الصورة القديمة بعد إرسالك صورة جديدة. تغييرات الموجه والموجه الرئيسي والأدوات تتطلب جميعها صورة جديدة وإصدار runtime جديد لتصبح نافذة.

تحتاج دور runtime إلى bedrock:InvokeModel, bedrock:Retrieve, bedrock-agentcore:InvokeGatewayو s3vectors:QueryVectors لمسار الصورة كاستعلام. تُضمّن سياسة Cedar المعروضة في دفتر الملاحظات 03 قواعد الإنسان في الحلقة، إذ تتطلب تقييمًا مسبقًا قبل المذكرات وقيد سجل تدقيق على كل قرار استبدال. يطبق التطبيق هذه القواعد فيمنطقه الخاصة اليوم، وإرفاق السياسة بمحرك ترخيص Cedar هو الخطوة التالية.

يعمل Amazon Nova Multimodal Embeddings الآن متاحًا في AWS GovCloud (US)، وهو أمر مهم لبرامج الفضاء والدفاع الخاضعة لمتطلبات إقامة البيانات وITAR وFedRAMP التي تحدد أماكن تشغيل أحمال العمل. إن قدرات الاسترداد متعدد الوسائط والتشابه البصري التي يعتمد عليها هذا المنشور متاحة داخل حدود AWS GovCloud (US). ويختلف توفر Amazon Nova Multimodal Embeddings وميزات Amazon Bedrock AgentCore حسب منطقة AWS، لذا تحقق من خدمات AWS حسب المنطقة قبل تخطيط النشر.

تقييم المساعد

نقيس الجودة بطريقتين: عبر تقييم مستمر عبر الإنترنت باستخدام AgentCore Evaluations، وهي إحدى قدرات Amazon Bedrock AgentCore، وعبر تحقق غير متصل مقابل مجموعات استعلامات منتقاة.

التقييم عبر الإنترنت في AgentCore

خدمة Amazon Bedrock AgentCore Evaluations, المتاحة عمومًا منذ مارس 2026، تقيّم آثار الوكيل باستخدام LLM-as-a-judge تقنيات. تقرأ الآثار الصادرة عن OpenTelemetry التي يُصدرها وكلاء Strands بالفعل، لذا لا يحتاج الوكيل المجهّز بالقياس إلى أي تغييرات في التطبيق ليُقيَّم. تقدم الخدمة وضعين: التقييم عبر الإنترنت يأخذ عينات باستمرار من جلسات الإنتاج الحية، والتقييم عند الطلب يشغّل اختبارات برمجية تتلاءم مع خط أنابيب التكامل والتسليم المستمر (CI/CD).

نستخدم التقييم عبر الإنترنت، مع نشر النتائج إلى Amazon CloudWatch للوحات المعلومات والتنبيهات. ينشئ دفتر الملاحظات 05 في مستودع GitHub إعدادًا للتقييم عبر الإنترنت ويرسل استعلامات اختبار إلى runtime المنشور لتوليد جلسات للتقييم.

config = eval_client.create_online_config(
    config_name=CONFIG_NAME,
    agent_id=RUNTIME_ID,
    sampling_rate=SAMPLING_RATE,
    evaluator_list=[
        "Builtin.GoalSuccessRate",
        "Builtin.Correctness",
        "Builtin.Helpfulness",
        "Builtin.Faithfulness",
        "Builtin.ResponseRelevance",
        "Builtin.ToolSelectionAccuracy",
        "Builtin.ToolParameterAccuracy",
    ],
    auto_create_execution_role=True,
    enable_on_create=True,
)

تأتي الخدمة مع ثلاثة عشر مقيّمًا مدمجًا، إلى جانب دعم المقيمين المخصصين المعرفين بموجه أو المستضافين كدالة AWS Lambda. نُمكّن سبعة منها، تغطي مستويات التقييم الثلاثة:

مجموعة الاستعلامات المنتقاة تحتوي على 36 استعلامًا موزعة على ست فئات: اكتشاف الكتالوج (8)، والبحث في المعرفة و ICD (8)، وسلاسل المتخصصين المتعددين (6)، والتقييم الحتمي (5)، والاسترجاع النصي-البصري (5)، ورفضات السلامة البشرية في الحلقة (4) التي تؤكد أن الوكيل يرفض التوصية أو الموافقة. كل استعلام يحمل معرّفات قطع الكتالوج المتوقعة له، باستثناء استعلامات السلامة، حيث تكون النتيجة المتوقعة هي الرفض.

export AGENTCORE_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-east-1:ACCOUNT:runtime/YOUR_RUNTIME
jupyter lab 05_evaluation.ipynb

النتائج

يأخذ AgentCore عينات من الجلسات الحية بشكل مستمر، لذا فإن درجة كل مُقيِّم هي مجموع متحرك يتغير مع تراكم حركة المرور ومع تغيّر الوكيل. الأرقام التالية هي لقطة من تشغيل مجموعة البيانات الاصطناعية. استخدمها كخط أساس لتحديد عتبات إنذار CloudWatch، وتوقع أن تختلف الأرقام في تشغيلاتك الخاصة.

سجّلت جميع مقاييس الجودة على مستوى الأثر درجات عند 0.95 أو أعلى، وكان استخراج معاملات الأداة شبه مثالي عند 0.980. التحسن الأبرز بين تشغيلات التقييم كان في دقة اختيار الأداة، التي ارتفعت من 0.809 إلى 0.861. ثلاثة تغييرات حققت هذا المكسب: التوحيد في قاعدة معرفة واحدة مُدارة، وإصلاح إذن مفقود في مسار الصورة-كاستعلام كان يسبب تراجعًا صامتًا إلى البحث النصي، وتضييق توجيه المخطط لتجنب ربط متخصصين غير ضروريين.

معدل نجاح الهدف أقل، عند 0.892، بسبب طريقة تصميم مجموعة الاستعلامات. تتضمن المجموعة مطالبات من فئة السلامة تطلب من الوكيل التوصية بالاستبدال أو الموافقة عليه. يرفض الوكيل بشكل صحيح، لكن المُقيِّم يسجّل الرفض الصحيح كهدف لم يتحقق. نتوقع هذه النتيجة، لأنه في نظام بشري في الحلقة يجب ألا يوافق الوكيل على الاستبدال من تلقاء نفسه.

كيّف النمط مع كتالوجك الخاص

الشيفرة عبارة عن نمط قابل لإعادة الاستخدام يعمل مع فئات القطع الأخرى، إلى جانب عجلات رد الفعل. تتطلب تبديل النطاق ثلاثة تغييرات: استبدال بيانات القطع (a specs.json، ووصف، وICD، وصفحة ورقة بيانات، وصورة لكل قطعة)، وتعديل مخطط المتطلبات لتعريف المواصفات الحرجة لفئتك وقواعد السماحية، وتوجيه قاعدة المعرفة إلى مجموعة بيانات S3 الخاصة بك. إن الوكلاء والأدوات ومحرك التقييم تُنقل كما هي دون تغيير. ولأن الأدوات الحتمية في mei_core دوال بايثون بسيطة، يمكن لتكامل PLM أو ERP أن يستدعي score_substitution_fit مباشرة، دون وجود وكيل في الحلقة.

تنظيف

لتجنب الرسوم المستمرة، احذف الموارد التي أنشأتها:

1. احذف وكيل بيئة تشغيل AgentCore و مستودع Amazon ECR.
2. احذف AgentCore Gateway وله أهداف البحث على الويب وقاعدة المعرفة.
3. احذف إعداد التقييم عبر الإنترنت و تنبيهات CloudWatch الذي أنشأته.
4. احذف قاعدة معرفية مُدارة و فهرس S3 Vectors.
5. احذف الـ حاوية S3 الاحتفاظ بمدونة الأجزاء.

الخاتمة

في هذه التدوينة، عرضنا كيفية بناء مساعد هندسي متعدد الوكلاء يحل محل البحث اليدوي عن بدائل القطع من خلال تجميع الأدلة تلقائيًا. تجمع هذه البنية بين Amazon Nova Multimodal Embeddings، التي تتولى تقييم التشابه البصري واسترجاع المخططات التي تفوتها الأنظمة المعتمدة على النصوص فقط، وAmazon Bedrock AgentCore، التي توفر البنية الإنتاجية لاستضافة بيئة التشغيل، والبوابة التي تحكم الاسترجاع والبحث على الويب، وتقييمات الجودة. ثلاثة اختيارات تصميمية هي الأهم: الكود الحتمي يُنتج كل حكم نجاح/فشل، وتُشغَّل كل مهمة على أصغر فئة من فئات النماذج الثلاث التي تتعامل معها بكفاءة، ولا يمكن للمهندس وحده الموافقة على الاستبدال.

للبدء، استنسخ مستودع GitHub، شغّل دفاتر الملاحظات (notebooks) باستخدام حساب AWS الخاص بك، واستبدل كتالوج القطع ومخطط المتطلبات الخاصين بك. للتعمق أكثر في أسس الاسترجاع، اقرأ صناعة الذكاء باستخدام Amazon Nova Multimodal Embeddings و دليل عملي لخدمة Amazon Nova Multimodal Embeddings. لأنماط الوكلاء في بيئة الإنتاج، انظر وثائق Amazon Bedrock AgentCore و الـ Strands Agents SDK.

عن المؤلفين