بناء عامل ذكي للتجربة التوضيحية وتشغيله لـ 40 مليون مطور هو مشاكل هندسية مختلفة. بدأت Postman في بناء وضع العميل، وهو طريقة بيولوجية للذكاء الاصطناعي للعمل عبر اختبار API، التوثيق، الاكتشاف والتنفيذ. كان الفريق يتوقع أن جودة النموذج وتصميم الطلبات ستكون أكثر المشاكل صعوبة. التحديات الأعمق نشأت من دمج العميل في منتج ناضج مع سنوات من افتراضات واجهة، مساحة واسعة، ومفاهيم متخصصة.
في هذا المقال، يصف Postman وAWS الأنماط الهندسية التي ظهرت أثناء إنشاء منتج ناضج يمكن للذكاء الاصطناعي فهمه. وتشمل هذه الأنماط التحكم في توسع الأدوات، وإظهار القراءات القائمة على الشيفرات، ومعاملتها للمجال السياقي بدلاً من القدرات كالعائق الرئيسي.
نوضح أيضًا كيف يستخدم وضع الوكيل Amazon Bedrock من أجل مرونة النماذج، والاستدلال عبر المناطق المختلفة، والاحتفاظ ببيانات صفرية اعتمادًا على النموذج، وتخزين التحفيز متعدد الطبقات. يمكن لهذه الممارسات معًا مساعدة الفرق على تجاوز النماذج التجريبية في الإنتاج الفعلي.
لماذا بنى Postman وضعية العنصر؟
وضع الوكيل هو بوابة Postman للعمل على المنتج بطريقة تتماشى مع الذكاء الاصطناعي في مجالات الاختبار والتوثيق والاكتشاف والتنفيذ. تطورت Postman خلال 11 عامًا، وتعلم المطورون والمستخدمون كيفية البحث عن المعلومات من خلال واجهة التطبيق من خلال توسيع الأقسام الجانبية والتحقق من التبويبات وفتح الطلبات. تم إعادة تصميم هذا الإدراك لدى الوكيل، مما أدى إلى ظهور افتراضات هيكلية في واجهات برمجة التطبيقات تجربة المستخدم وتوزيع المعرفة المتعلقة بالمنتج. يقوم الوكيل بالتفكير في البيانات بدلاً من التنقل على الشاشة. يوضح الشكل 1 كيف يعمل وضع الوكيل مباشرة ضد التطبيق.
الشكل 1: وضعية العملاق تعمل مباشرة ضد تطبيق Postman. في هذا المثال، يتم فتح طلب تحرير (pull request) ويتم اقتراح الخطوات التالية دون الحاجة إلى أن يقوم المستخدم بالتنقل عبر واجهة التطبيق.
وضع الوكيل يعمل على Amazon Bedrock，الذي يوفر وصولًا مُدارًا إلى النماذج الأساسية خلف الوكيل. دعم مجتمع المطورين العالمي لـ Postman يولد طلبًا متغيرًا حساسًا على التأخير مع زيادات حادة في حركة المرور. باستخدام Amazon Bedrock، يمكن لـ Postman توسيع هذا العبء الإنتاجي دون تشغيل بنية تحتية خاصة بخدمة النماذج، مع الحفاظ على المرونة في اختيار النماذج والتحكم في السرعة والتجهيز الجغرافي والتكلفة. توفر الشكل 2 نظرة عامة عالية المستوى للهيكل الإنتاجي قبل أن تتعمق الأقسام التالية في فحص مكوناته.
الشكل 2: وضع عامل Postman يجمع بين أدوات الجانب العميل، تنظيم العميل، السياق المصمم خصيصًا، وتقدير نموذج Amazon Bedrock. تُحدد أدوات كل مهمة، ويظل موافقة المستخدم جزءًا من الإجراءات التي تعدل حالة التطبيق.
إن الرقابة البشرية جزء من تصميم الإنتاج. يتطلب وضع الوكيل موافقة المستخدم قبل اتخاذ أي إجراء يغير حالة التطبيق. يقوم Postman أيضًا بتحديد الأدوات المتاحة للمهمة، واختيار السياق المخصص للغرض، وتطبيق إعدادات الاحتفاظ بالبيانات المعتمدة على النموذج. تقلل هذه التحكمات من الإجراءات غير المقصودة والإفراز غير الضروري للبيانات، بينما تظل اختبارات الإنتاج ومراقبتها ضرورية. كنظام تحكم للذكاء الاصطناعي مسؤول، يستخدم Postman Amazon Bedrock Guardrails لحظر المعلومات التي يمكن من خلالها التعرف على الشخص قبل وصولها إلى النموذج الكبير لللغة (LLM). يمكن لمديري المؤسسات تفعيل ذلك في إعدادات حواجز الوكيل.
معالجة توسع الأدوات
في وضع الوكيل، تحدد الأدوات كيف يتصرف الوكيل داخل Postman. في البداية، اعتمد الفريق على أدوات صغيرة ودقيقة للغاية: أفعال محددة مثل فتح طلب، تحديث حقل واحد، أو استخراج جزء معين من البيانات الوصفية. لقد ساعد هذا النهج على الدقة والسيطرة في الجولات الأولى، لكنه كشف أيضًا عن عدة مشاكل.
تتطلب العديد من عمليات العمل في العالم الحقيقي سلسلة طويلة من استدعاءات الأدوات. حتى عندما كان كل خطوة سريعة، كانت التجربة الكلية بطيئة، لأن كل عملية كان يجب أن تعود إلى النموذج قبل أن يمكن البدء في الخطوة التالية. يشاهد المستخدمون العميل وهو يقوم بخطوات تجمعها في ذهنهم كعملية واحدة.
في اختبارات بوستمان، زادت أخطاء اختيار الأدوات عندما تجاوز عدد الأدوات الظاهرة حوالي 40 أداة. يمكن للعامل استدعاء أدوات غير موجودة، وتقديم معاملات خاطئة رغم صحة النماذج، أو اختيار أدوات تبدو منطقية من الناحية الدلالية لكنها خاطئة في السياق. ساعدت النماذج الأكبر حجمًا أو الأحدث في تقليل هذا السلوك، لكنها لم تزيله تمامًا.
بعد حجم معين من مجموعة الأدوات، فإن كشف المزيد من الأدوات يمكن أن يقلل من فعالية العميل. تتبع البنية التحتية الحالية اختيار الأدوات بناءً على الحاجة والسياق، وتفصل خيوط التنفيذ الفردية عن بعضها. ينظر النموذج فقط إلى الأدوات المتعلقة بالمهمة الحالية. يوضح الشكل 3 هذه العملية الديناميكية لاختيار الأدوات.
الشكل 3: يستفسر الوكيل الجذري من قاعدة البيانات المتجهة للإدراجات الخاصة بالأدوات، ويقوم بتصفية أكثر من 170 أداة إلى حوالي 15 أداة ذات صلة بالطلب. ثم يسلم تلك الأدوات إلى وكيل فرعي معزول عن السياق، بحيث يرى النموذج فقط الأدوات الضرورية للمهمة.
كانت مشكلة أكثر دقّة تتمثل في أن العديد من واجهات برمجة الأنظمة الخاصة بالعميل كانت مرتبطة ضمنيًا بحالة الواجهة. كانت الأدوات التي تعدل الطلبات بحاجة إلى فتح بعض العناصر، بينما تفتح أدوات أخرى علامات تبويب جديدة كآثار جانبية. كان على العميل فتح علامة تبويب لإرسال الطلب، مما يحاكي التفاعلات في الواجهة بدلًا من التفكير في البيانات. يقوم Postman بتفريق الأدوات عن العلامات التبويب بنشاط، ويتيح ميزة Native Git استخدامًا واسعًا لهذا النهج. على سبيل المثال، يمكن لـ Agent Mode الآن إرسال الطلبات في الخلفية دون فتح علامة تبويب، على الرغم من أن موافقة المستخدم لا تزال مطلوبة.
خلاصة البنّاء: اعتبر فهرس الأدوات الخاص بك جزءًا من ميزانية السياق. قم بتحديد نطاق الأدوات المعروضة على النموذج بشكل ديناميكي حسب المهمة، وافصل "ما يمكن للعنصر القيادي فعله" عن "ما يحتوي الواجهة الأمامية علىه".
كشف القراءة القائمة على النموذج
بالنسبة للمنتجات مثل كتالوج API، قام Postman بتوحيد عدة نوافذ ضيقة إلى أداة استعلام واحدة. تكشف هذه المنتجات عن بيانات منظمة مثل وقت استمرارية الخدمة، نتائج الاختبارات، وزمن استجابة نقاط النهاية في العديد من الخدمات.
بالنظر إلى أشكال البيانات في جداول ClickHouse، يمكن للعامل إنشاء استعلامات معقدة باستخدام شروط الانضمام وشروط WHERE. وهذا يقلل بشكل كبير من عدد الأدوات المختلفة اللازمة لإجابة سؤال التحليل:
SELECT toString(service_id) AS service_id,
countMerge(total_events_state) AS total_requests,
countMerge(error_events_state) AS total_errors,
round(countMerge(error_events_state) * 100.0
/ countMerge(total_events_state), 4) AS error_rate_pct,
avgMerge(avg_latency_state) AS avg_latency_ms,
quantileMerge(0.95)(p95_latency_state) AS p95_latency_ms
FROM http_events_summary_1d
WHERE service_id IN ('...list of service IDs')
AND bucket_1d >= today() - 7
GROUP BY service_id
HAVING p95_latency_ms < 100
AND total_requests > 0
ORDER BY error_rate_pct DESC;بهذه الطريقة، يتحول عمل الهندسة من بناء أداة لكل سؤال إلى نمذجة البيانات بشكل جيد مرة واحدة. وبالتالي يمكن للعنصر الخبيث توليد مجموعة أكبر بكثير من الاستفسارات مقارنة بما يمكن للفريق تقديمه كأدوات فردية.
خلاصة البنائين: عندما يكون لديك بيانات منظمة جيدًا، قم بتزويد الجهاز بالوصول إلى محرك الاستعلام مع وعي بمخططات البيانات بدلاً من استخدام العديد من أدوات القراءة ذات الغرض الواحد. تتم مقايضة عدد الأدوات بـ نمذجة البيانات، مما يولد منحنى توسع أفضل.
كان السياق هو العائق الحقيقي
افترضت Postman في البداية أن عدم وجود الأدوات سيكون العائق الأكبر. في الواقع، تسبب غياب أو عدم اكتمال السياق في أكثر الفشل من عدم وجود القدرات.
السياق هو فهم العميل لوضع المستخدم في Postman، والكيانات النشطة، والحالة التي تم إنشاؤها بالفعل. عندما يكون السياق خاطئًا أو غير موجود، حتى الأدوات الصحيحة تصبح غير فعالة. يميز الشكل 4 بين شكلين من أشكال السياق المقدمة للعميل.
الشكل 4: نوعان من السياقات يغذيان العميل. السياق العام السطحي يتم جمعه تلقائيًا ويُحول إلى بيانات صغيرة لإعطاء التوجيه. السياق العميق المحدد يختاره المستخدم ويتم توجيهه عبر معالج مخصص لكل نوع من الكيانات. يقوم كل معالج بتحويل الكيان إلى المعلومات التي يحتاجها العميل.
كان التحدي هيكليًا. على مدار 11 عامًا، تعلم المطورون والمستخدمون كيفية البحث عن المعلومات من خلال واجهة التطبيق. وكان إعادة تصميم هذه القدرة يتطلب عدة جولات لتمييز ما هو مهم في كل عملية، وما هو ضوضاء. ولم يُنتج تحويل نموذج بيانات الواجهة الحالية إلى صيغة تسلسلية سياقًا مفيدًا، لأن تلك الكائنات كانت مصممة للعرض والنقل البيانات، وليس للتفكير. لذلك، قام Postman ببناء معالجات سياق متخصصة تُحلل كل كيان إلى ما يحتاج الوكيل إلى معرفته.
مع زيادة عدد الكائنات التي تحتوي على معالجات، أصبح تقطيع البيانات المشكلة التالية. تحتوي العديد من الحقول على بيانات مُولدها المستخدم ذات النهاية غير محددة، بما في ذلك وصفات الطلبات وتوصيات OpenAPI وأحمال الطلبات. يمكن أن تزيد هذه البيانات من حجم نافذة السياق. من الضروري إدارة ميزانية السياق بعناية عند النظر إلى الحجم الكبير، وذلك يدعم النهج المعتمد على نظام الملفات الذي تستكشفه الفريق، حيث لا يحتاج كل معالج إلى منطق مخصص لتقطيع وتوسيع البيانات.
خلاصة البناءر: لا تزود النموذج ببيانات التصور الخاصة بك. بنث قواعد سياق ذات هدف، وتعامل مع نافذة السياق كميزانية نادرة يتم إدارتها بشكل فعال. الضوضاء تطغى على الإشارة قبل أن يصل النموذج إلى حدوده.
دمج كل شيء معًا
مع تطور وضع الوكيل، أصبح من الواضح أن النظام يجب أن يجمع ثلاثة مكونات مختلفة، حيث يحل كل منها مشكلة منفصلة.
- أدوات الطرف الخاص تعيش في تطبيق Postman وتمثل الإجراءات النهائية التي يمكن للعامل اتخاذها، مثل فتح الطلبات، تعديل الإعدادات، تشغيل المجموعات، وفحص المصادقة. يستخدم وضع العامل أيضًا أدوات الطرف الخادم لأغراض مثل البحث على الويب وإدارة حلقة العمل، لكن معظم الأدوات تعمل داخل تطبيق Postman.
- تعرّف توجيهات الوكيل العام على السلوك على مستوى النظام، بما في ذلك كيف يجب أن يكون وضع الوكيل الاستباقي، وكيف يتواصل مع عدم اليقين، وما هي المعرفة الأساسية للمنتج التي يحملها.
- تستخدم قاعدة المعرفة نهج التوليد المُعزز بالاسترجاع (RAG). يمتلك Postman مساحة إنتاجية كبيرة تشمل بروتوكولات طلبات متعددة، خوادم محاكاة، أجهزة مراقبة، وثائق، شبكة API، حوكمة منطقة العمل، متغيرات، مساعدات، توليد الكود، إعدادات الطلبات، وعمليات جمع.
لم يكن من الممكن ترميز كل هذا في رسائل ذاتية الثبات، ومعظمها غير ضروري بالنسبة للاستعلام المحدد. لإضافة بيانات أولية، استخدم الفريق مركز التعلم في Postman لإنشاء مقالات مختصرة حسب الخصائص. أثناء التشغيل، يختار وضع الوكيل المقالات المعرفية بناءً على الاستعلام الوارد والسياق المتاح. على سبيل المثال، عندما يختار المستخدم خادم محاكي، يقوم وضع الوكيل بإدخال المقال ذي الصلة تلقائيًا. هذا يحافظ على وزن الوكيل الخفيف بشكل افتراضي، مع توفير عمق عند الحاجة. تتطور قاعدة المعرفة مع التطبيق، بحيث يمكن للفرق إصدار وثائق وضع العميل مع الميزات الجديدة.
تشغيل وضع الوكيل على Amazon Bedrock
تتوافق المكونات الثلاثة المذكورة سابقًا على نفس إجراء التشغيل: استدعاء نموذج أساسي (FM). على حجم Postman، يكون حركة المرور متقلبًا ومرتبطة بالمطورين. تساعد أدوات التوجيه والتخزين المؤقت والمعالجة الجغرافية Postman في التعامل مع تقلبات حركة المرور، وإدارة تكلفة الاستدعاء، والاستجابة لمتطلبات المعالجة المحددة للأعمال. يوفر Amazon Bedrock أربعة قدرات تهم هذا المجال بشكل أساسي.
مرونة النموذج في عائلة Claude
لا يرتبط وضع الوكيل بنموذج واحد. من خلال واجهات إدراك نماذج Amazon Bedrock، يمكن لPostman الوصول إلى نماذج Anthropic Claude المدعومة وتوجيه كل أعمال العمل إلى النموذج المناسب. يمكن للنموذج الأسرع تقديم خدمات للتفاعلات ذات الحجم الكبير والتي تتطلب زمن استجابة منخفض، بينما يمكن للنموذج الأكبر تحمل التفكير المعقد حيث يكون الجودة أكثر أهمية من التكلفة. التحول بين نماذج Claude المدعومة هو في الأساس تغيير في الإعدادات وليس عملية تكامل جديدة. هذه المرونة تدعم مباشرة التحديات المتعلقة بالأدوات المتراكمة والسياق كما تم وصفهما سابقًا. خلال اختبارات Postman، قلّت الأدوية الزائفة الناتجة عن النماذج الجديدة والأكبر حجمًا، ويمكن لPostman اعتماد النماذج المدعومة دون إعادة بناء العملية التكاملية. راجع النماذج المدعومة حسب منطقة AWS في Amazon Bedrock.
استدلال عبر المناطق لزيادة الإنتاجية
حركة المطورين متقلبة، وإن توفير الموارد للطلب الأقصى في منطقة AWS واحدة قد يكون مكلفًا. يستخدم وضع الوكيل استدلال عبر المناطق المختلفة في Amazon Bedrock لتوجيه الطلبات تلقائيًا بين المناطق الوجهة التي تم تعريفها بواسطة ملف الاستدلال. أثناء التشغيل، يمر التطبيق معرف ملف الاستدلال المختار أو اسم الموارد Amazon (ARN) كـ modelId في Converse أو InvokeModel. يجب أن تسمح الملفات، والسياسات الخاصة بإدارة الهوية والوصول في AWS (IAM) والسياسات الخاصة بالخدمات، والحدود بكلها بالمنطقة الوجهة التي قد يختارها Bedrock.
- ملفات الاستدلال الجغرافية تقوم بطلب الطرق فقط بين المناطق المدعومة ضمن نطاق جغرافي محدد، مثل الولايات المتحدة أو الاتحاد الأوروبي. تجمع هذا الخيار بين زيادة الإنتاجية وحدود معالجة جغرافية مُعدة.
- يمكن لملفات الاستدلال العالمية توجيه الطلبات بين المناطق الوجهة المدعومة في جميع أنحاء العالم، مما يوفر معدل تدفق إضافي أثناء زيادة حركة المرور. وينطبق استخدامها فقط عندما لا تتطلب الحملة العمل حدود معالجة محددة جغرافيًا.
يمكن لـ Postman اختيار نموذج الاستدلال حسب حجم العمل: نموذج عالمي لتحقيق أقصى معدل استيعاب، أو نموذج جغرافي عندما يجب أن تظل عمليات المعالجة ضمن المنطقة الجغرافية المحددة بالنموذج. يتم التعبير عن هذا الاختيار بشكل صريح في id النموذج المستخدم لكل طلب استدلال Bedrock.
# Schematic Converse request
response = bedrock_runtime.converse(
modelId="<geographic-inference-profile-id-or-arn>",
messages=messages,
system=system_blocks,
)إقامة البيانات والضوابط المؤسسية
بالنسبة لعملاء الشركات، يمكن أن تكون المناطق المسموح بها للتخطيط مهمة مثل النقل الكلي. تحدد ملفات الاستدلال الجغرافية منطقة توجيه Bedrock إلى المناطق الوجهة التي يدعمها الملف ضمن المنطقة المختارة. هذا لا يعني أن عملية الاستدلال تتم داخل بيئة AWS الخاصة بـ Postman. يقوم Amazon Bedrock بتحليل الطلبات في مناطق AWS المؤهلة لذلك الملف، مع تشفير البيانات أثناء النقل وأثناء الإرجاع. تقول AWS إن Bedrock لا تستخدم الطلبات أو الإكماليات لتدريب نماذج AWS أو توزيعها على الأطراف الثالثة. لقد قام Postman بتكوين عدم الاحتفاظ بالبيانات عندما تم تعيين وضع data_retention_mode إلى none بالنسبة للنماذج التي تدعم وضع Agent Mode. توافر السلوك والعملية يعتمدان على النموذج، لذا يجب التحقق من كل نموذج إنتاجي ضمن الإطار الحالي. وثيقة أمازون Bedrock لحماية البيانات والاحتفاظ بها.
تخزين بيانات الاستدعاء للحفاظ على التكاليف تحت السيطرة
إنسان الإنتاج يعيد إرسال سياق مستقر كبير في كل جولة، يشمل تعليمات النظام، والسلوك العام للإنسان، ومجموعة أدوات أساسية، والمعرفة المختارة، وسياق المحادثة. إعادة معالجة البادئة التي لم تتغير في كل طلب تزيد من التأخير والتكلفة التي يمكن تجنبها.
يستخدم وضع العميل تخزين مؤقت تعليمات Amazon Bedrock لإعادة استخدام بادئات التعليمات الثابتة. الجوهر الذي لا يتغير تقريبًا، بما في ذلك تعليمات النظام وتعليمات العميل وتعريفات الأدوات الأساسية، يستخدم نقطة توقف تخزين تستمر ساعة واحدة. أما السياقات المتغيرة أكثر فإنها تستخدم نقطة توقف تستمر خمس دقائق وتُجدد عند حدوث نجاح في التخزين. يتطلب Bedrock أن تظهر نقطة التوقف التي تستمر أطول قبل نقطة التوقف التي تستمر أقل. المستوى الأقل يصلح للجلسات التفاعلية لأن السياق الخامل ينتهي، بينما يمكن للمستوى الذي يستمر ساعة واحدة أن يخفف من تكلفة كتابة التخزين العالية عبر العديد من القراءات. فوائد التخزين والمواعيد الزمنية الممكنة تعتمد على النموذج المختار. يمكن للفرق التحقق من السلوك من خلال حقول استخدام كلمات المدخلات التي تُقرأ في التخزين وكلمات المدخلات التي يُكتب فيها في التخزين، وقياس الوقت حتى الوصول إلى أول كلمة لعملياتهم الخاصة.
# Schematic cache checkpoints in Converse content blocks
{"cachePoint": {"type": "default", "ttl": "1h"}} # stable core
{"cachePoint": {"type": "default", "ttl": "5m"}} # variable layerخلاصة البنائين: اعتبر التفكير الاستدلالي مشكلة توجيه وتخزين، وليس مجرد قرار اختيار نموذج. اختر نموذج Claude وفقًا لحجم العمل، واختر الملف الشخصي المناسب للاستدلال عبر المناطق، وخزن البادئة الثابتة للتوجيه مع TTLات تتناسب مع تكرار تغيير كل طبقة.
أفضل الممارسات لتوسيع الوحدات في الإنتاج
مُحلَّل من رحلة بوستمان، لصناع البناء الذين يعملون على أمازون بيدروك:
- أدوات الميزانية بنفس الدقة التي تُستخدم في التصنيفات. اختر الأدوات بشكل ديناميكي حسب المهمة المطلوبة. في اختبار Postman، زادت أخطاء اختيار الأدوات مع توسع مجموعة الأدوات الظاهرة.
- يفضل استخدام القراءات التي تدرك النموذج بدلاً من إنتاج العديد من الأدوات. قم بتصميم بياناتك بشكل جيد ودعالأداة تستفسر عنها.
- فصل أفعال العامل عن حالة الواجهة. إذا كان الأداة تتطلب فتح تبويب، فإن العامل يتحرك في واجهة بدلاً من التفكير مباشرة في البيانات.
- قم بتهيئة السياق الهندسي عمدًا. معالجو السياق المصمم خصيصًا يتفوق دائمًا على تجميع نموذج التصور بشكل تسلسلي.
- تنظيم نافذة السياق كمورد نادر. استراتيجية التقريب والتوسيع هي مشكلة تصميم من الدرجة الأولى، وليست شيئًا تُفكر فيه لاحقًا.
- شحن الوثائق مع الميزات. لا تظل قاعدة بيانات المعرفة RAG مفيدة إلا إذا تطورت بالتوازي مع المنتج.
- الطريق والمتصفح في Bedrock. قم بمطابقة كل عبء عمل مع النموذج المناسب لـ Claude، واختر الاستدلال عبر المناطق المختلفة بناءً على معدل التدفق والاحتياجات الجغرافية، وطبق التخزين المؤقت المتدرج على البادئات الثابتة.
الخلاصة
تتطلب وضع وكيل البناء استخدام Postman للتعامل مع الفجوة بين قدرات النموذج اللغوي الكبير وبنية المنتجات المتقدمة: افتراضات الواجهة، العملاء المتعددون، كتالوج الأدوات الواسع، والمعرفة الموزعة على الوثائق والفرق. ظهر اختيار الأدوات الديناميكي، القراءة القائمة على الشيفرة، والهندسة المتعمدة للسياق كأنماط قابلة للتكرار على مستوى مجتمع المطورين في Postman. يوفر Amazon Bedrock الوصول إلى النموذج المُدار، الاستدلال عبر المناطق، ضوابط الاحتفاظ بالبيانات المعتمدة على النموذج، وتخزين التحفيز التي تدعم البنية الإنتاجية.
سواء كنت تبني وكيلك الأول أو توسع وكيل موجود، فإن هذه الأنماط يمكن أن تساعد الفرق على تجنب التحديات الشائعة في دمج الوكيل والتوسيع.
للمزيد من المعلومات، يرجى الاطلاع على وثيقة Amazon Bedrock، والتي تشمل إرشادات حول الاستدلال عبر المناطق، تخزين الأوامر، وحماية البيانات والاحتفاظ بها. للحصول على إرشادات ذات صلة بشأن التنفيذ، يرجى قراءة استخدام تخزين الأوامر على Amazon Bedrock بفعالية، وAmazon Bedrock تعلن عن الاستدلال عبر المناطق العالمي للزيادة من الكفاءة في بلاگ AWS Machine Learning. لاستكشاف المنتج، يرجى الاطلاع على وثيقة Postman Agent Mode.
تنفيذ Produktion لشركة Postman هو حصري ولا يتوفر كمخزن نموذج عام.