في إدارة الجودة للصناعات الخاضعة للتنظيم، الذاكرة المؤسسية التي تحل مشكلة ما تكون مدفونة في الغالب في مكان ما ضمن تاريخ أحد العملاء. عيب مماثل تمت دراسته العام الماضي، إجراء تصحيحي ووقائي (CAPA) عالج السبب الجذري، أو ملاحظة تدقيق أشارت إلى الفجوة نفسها. هذه المعرفة تستقر في مليارات المستندات التي لا يمكن لأي إنسان البحث فيها بالتشابه الدلالي عبر اللغات والتنسيقات، لذا تبدأ كل عملية تحقيق من الصفر. ساعدت Octave Reliance كل مؤسسة في جمع المستندات عبر أنظمة متعددة لمساعدتها على البحث بسهولة أكبر وتتبع كل ما تملكه. لقد Octave رأى فريق Reliance أن إطلاق العنان لهذا التاريخ هو أكبر فرصة لديه لمساعدة العملاء على العمل أسرع والبقاء ممتثلين. وكانت العقبة واضحة بالمثل: سجلات الشكاوى وملاحظات التدقيق والإجراءات التصحيحية تحمل أشد متطلبات العزل صرامة على المنصة، وكانت تلك تحديدًا السجلات التي ستحتاج الذكاء الاصطناعي إلى قراءتها. في منصة تخدم أكثر من 14,000 عميل عبر الأجهزة الطبية والأدوية وتصنيع الأغذية، فإن أي إفصاح غير مقصود واحد من عميل إلى آخر سيحمل عواقب تنظيمية تفوق بكثير أي فائدة من الذكاء الاصطناعي.
تعمل Octave في 180 دولة، وتخدم أكثر من 60% من قائمة Global Fortune 500. ونظامها السحابي الأصلي لإدارة الجودة، Reliance، يدعم أكثر من 650 عميلًا من المؤسسات عبر أكثر من 40 تطبيقًا، من إدارة الشكاوى وتتبع CAPA إلى إدارة التدقيق وجودة الموردين. الجميع يولّد بيانات خاضعة للتنظيم يمكن للذكاء الاصطناعي التفكير فيها. كل عميل هو مستأجر منفصل، ولا يمكن لأي بيانات أن تعبر حدود المستأجر.
في مواجهة ذلك، اتخذ فريق Reliance قرارًا غير معتاد: بدلاً من إطلاق ميزة ذكاء اصطناعي واحدة، أمضى دورته الأولى في بناء أساس ستقوم عليه كل ميزة مستقبلية. وقد خفّض هذا الأساس منذ ذلك الحين زمن النشر لكل حالة استخدام بنسبة 50 بالمئة. إذا كنت تقدّم الذكاء الاصطناعي إلى منصة برمجيات كخدمة (SaaS) حيث تكون البيانات ثمينة لكن العزل غير قابل للتفاوض، فإن هذا التفكير يتجاوز إدارة الجودة. في هذه المقالة، نستعرض التوترات الأربعة التي شكّلت التصميم والأساس ثلاثي الطبقات الذي بنته Octave باستخدام Cohere Embed v4 على Amazon Bedrock. ثم نتابع خط المعالجة الذيضمّن 2 مليار مستند ومساعد فرز الشكاوى الذي أثبت جدواه في الإنتاج.
لماذا أساسًا لا ميزة
كشفت ورش العمل التصورية مع AWS أربع حالات استخدام عالية التأثير: تلخيص الشكاوى وفرزها، ومراقبة الجاهزية للتدقيق، وتوليد روايات الحوادث، والتنبؤية التصنيف الكمي لمخاطر الجودة. كما كشفت أيضًا الرؤية التي شكّلت كل ما تلاها: عشرات التطبيقات، لكل منها أنواع مستندات وسير عمل مختلفة. بناء الذكاء الاصطناعي لواحد منها في عزلة يعني إعادة بناء البنية التحتية للتالي.
لذا عكس الفريق الخطة: بناء المنصة الأفقية أولًا، ثم اقتطاع شرائح الميزات العمودية منها. جاء تلخيص الشكاوى وفرزها أولًا، لإثبات البنية قبل أن تتبعها بقية الحالات.
التوترات الأربعة
قبل اختيار نموذج واحد، أمضى الفريق وقته في أربع مشكلات كانت تسحب في اتجاهات مختلفة. ولا يمكن التنازل عن أي منها.
إتاحة البيانات دون خطر الإفصاح غير المقصود. سجلات الشكاوى وإجراءات CAPA وإجراءات التشغيل القياسية (SOPs) وملاحظات التدقيق تخص مستأجرًا واحدًا ويجب ألا يتمكن مستأجر آخر من الوصول إليها. لا يجوز حتى أن يعبرها استعلام ذكاء اصطناعي خاطئ. كان على مخزن المتجهات ومنطق الاسترجاع وسياق التوليد أن تكون جميعها محدودة النطاق بمستأجر واحد.
تنفيذ الوكلاء في عزلة. كان يجب أن تكون الأذونات التي تحكم أدوات الوكيل ومخازن البيانات ونقاط نهاية النماذج محدودة النطاق بالمستخدم الطالب بدلاً من دور خدمة مشترك، ومتاحة أثناء التنفيذ فقط، ومحترمة لحقوق وصول ذلك المستخدم. مجمّع وكلاء مشترك ببيانات اعتماد ثابتة أخفق في الشرطين الثلاثة جميعًا.
قراءة محتوى لا يمكن الوثوق به. تستوعب الوكلاء هنا شكاوى ومرفقات بريد إلكتروني وملفات PDF ممسوحة ضوئيًا وصورًا من خارج المؤسسة. يذكر OWASP Top 10 لتطبيقات نماذج اللغة الكبيرة (LLM) لعام 2025 التهديدات التي تنطبق مباشرة: حقن التعليمات عبر المحتوى المستوعب (LLM01)، وإفصاح المعلومات الحساسة (LLM02)، والتعامل غير السليم مع المخرجات (LLM05)، والوكالة المفرطة (LLM06). التعليمات المخفية في ملف PDF مرفق ليست افتراضية عند هذا الحجم.
تضمين 2 مليار مستند دون انتظار يمتد لفصل كامل. يستضيف Reliance أكثر من 2 مليار مستند، مع مستأجرين فرديين يخزنون ملايين ملفات Word وملفات PDF والنماذج الممسوحة ضوئيًا وجداول البيانات والصور والبريد الإلكتروني. التزم الفريق بتهيئة حتى أكبر مستأجر خلال يوم عمل واحد. ولأن هذه المستندات تُعلم القرارات التنظيمية، لم يكن يمكن التنازل عن الجودة مقابل سرعة المعالجة. شكوى واحدة مفقودة تؤدي إلى تآكل الثقة في النظام بأكمله.
إلى أين وصلت البنية
الإمساك بأربعة توترات في آنٍ واحد قلّص الخيارات كثيراً. عالجت Amazon Bedrock هذه التوترات كمنصة واحدة: وصول متعدد النماذج عبر واجهة API واحدة، وإقامة AWS Region والحوكمة التي AWS Identity and Access Management (IAM) يفرضها حساب AWS أصلاً، وGuardrails كضوابط محتوى إنتاجية بدلاً من شيء يتعين بناؤه.
تتحقق الأساس في ثلاث طبقات، كما هو موضح في الشكل 1. يُدمج إعداد البيانات المستندات الجيدة باستخدام Cohere Embed v4 on Amazon Bedrock ويكتبها في مخزن متجهات لكل مستأجر على Amazon OpenSearch Service. يمرر التنفيذ الآمن طلب المستخدم عبر AgentCore Gateway، وهي إمكانية من Amazon Bedrock AgentCore، تطبق المصادقة والسياسة قبل تسليمه إلى جلسة microVM معزولة تستدعي نموذج Anthropic Claude على Amazon Bedrock. وبالتفاف حول الاثنين، تطبق حماية المحتوى Amazon Bedrock Guardrails مرتين: ترشيح المدخلات عند الدخول، وترشيح المخرجات قبل وصول أي شيء إلى المعالج. يبقى الاسترجاع والتنفيذ والفرز في مراحل منفصلة، بحيث يمكن فرض كل منها وإثباته بشكل مستقل.
الشكل 1: البنية عالية المستوى لأساس Reliance AI
اختيار كيفية تمثيل البيانات
لم ينجح أي شيء آخر حتى أصبحت المستندات قابلة للاسترجاع. وكان ذلك يعني بدقة، وعبر اللغات والصيغ، وليس عبر حدود مستأجر. قيّم الفريق نماذج التضمين مقابل مجموعة بياناته الخاصة بدلاً من لوحات الصدارة العامة. كانت الأسئلة الحاسمة خاصة بهذه البيانات: ما علاقة صورة غلاف متشقق بالفقرة التي تصفه، وعلاقة شكوى ألمانية بتقرير CAPA بالإنجليزية.
فاز Cohere Embed v4 on Amazon Bedrock بخمسة معايير وكانت هذه المعايير مترابطة فيما بينها. ما تم حسمه أولاً هو مقدار ما أصبح غير ضروري من خط الأنابيب. تحمل السجلات الجيدة صوراً للمنتجات المعيبة ونماذج فحص ممسوحة ضوئياً ومخططات مشروحة إلى جانب النص. يضع Embed v4 كلا النمطين في مساحة متجهات واحدة. صورة غلاف متشقق والفقرة التي تصف هذا العيب قابلان للاسترجاع من استعلام واحد، دون خط أنابيب منفصل لكل نمط. يؤدي الدعم الأصيل لتعدد اللغات العمل نفسه على المحور الآخر: تصل المستندات بلغات متعددة، وغالباً داخل مجموعة مستندات مستأجر واحد، ولا تحتاج إلى معالجة مسبقة للترجمة. خطا أنابيب لم يضطر الفريق أبداً إلى بنائهما، ومكانان أقل لكي تسقط فيهما وثيقة من الاسترجاع.
حسمت المعايير الثلاثة المتبقية أين يمكن أن تعيش المتجهات وكم ستكلف. لا يمكن لبيانات العملاء أن تغادر منطقة AWS Region الخاصة بها، حتى للاستدلال، لذا كان توفر النموذج داخل المنطقة (in-Region) على Amazon Bedrock شرطاً مسبقاً وليس مجرد ترف. يدعم Embed v4 الاستدلال داخل المنطقة في منطقة US East (N. Virginia) (us-east-1) ومنطقة Europe (Ireland) (eu-west-1) ومنطقة Asia Pacific (Tokyo) (ap-northeast-1)، ويغطي ثلاثاً من متطلبات الامتثال الإقليمية لشركة Octave. يختلف توفر النماذج والميزات حسب المنطقة ويتغير بمرور الوقت. للتغطية الحالية، انظر التوفر الإقليمي حسب النماذج في دليل مستخدم Amazon Bedrock. داخل كل منطقة، تتدرج تكاليف Amazon OpenSearch Service خطياً مع عدد الأبعاد. جعل ذلك من أبعاد المخرجات القابلة للتهيئة في Embed v4 والممتدة من 256–1,536 أمراً يستحق الاختبار بدلاً من قبوله افتراضياً. أظهر الاختبار مقابل استعلامات إنتاج ممثلة أن 512 بعداً يحافظ على الدقة المستهدفة مع خفض التخزين بنحو 66 بالمئة مقارنة بالقيمة الافتراضية 1,536. أما نافذة السياق البالغة 128K رمزاً فآتت ثمارها في مكان آخر تماماً: الأجزاء التي يبلغ حجم كل منها نحو 4K رموز تُحزم أعداد كبيرة منها في طلب واحد، ومن هنا جاءت إنتاجية الإعداد الأولي.
إبقاء المستأجرين منفصلين في وقت التشغيل
كان السؤال الأصعب أين تُفرض الفصل بين المستأجرين. كان كود التطبيق سيفي بالغرض، لكنه كان سيعني أن كل فريق ميزات مستقبلي عليه تصحيح الأمر في كل مسار كود، حيث إن فحصاً واحداً منسوباً يعرّض لخطر الكشف غير المقصود عبر المستأجرين. بدلاً من ذلك، دفع الفريق العزل إلى بيئة التشغيل. بيئة تشغيل AgentCore، وهي إمكانية من Amazon Bedrock AgentCore، تفرض الفصل تحت طبقة التطبيق، ولأنها تبقى مستقلة عن الإطار والنموذج، لم يؤثر قرار العزل على إطار الوكيل والنماذج المختارة لمساعد فرز الشكاوى (Complaint Triage Assistant).
تشتغل كل جلسة مستخدم في microVM مخصصة بوحدة CPU وذاكرة ونظام ملفات خاصين بها، وتتوقف وتُعقَّم عند انتهاء الجلسة. هذا فصل على مستوى الأجهزة مصمم ليصمد بغض النظر عن سلوك الوكيل. يحمل AgentCore هوية المستخدم الموثق عبر سلسلة التنفيذ كاملة: خزائن رموز OAuth لكل مستخدم تتحقق من أن الوكيل يعمل نيابة عن ذلك المستخدم المحدد وليس عن هوية خدمة مشتركة، وتُقيَّد بيانات الاعتماد لكل وكيل وتعيش فقط خلال الجلسة. يخوّل AgentCore Gateway على مستوى الأداة والعملية والمعامل. يوفر الاستدلال الآلي تحققاً رسمياً مقابل القواعد المحددة. إنه الانضباط نفسه الكامن وراء IAM و Amazon Simple Storage Service (Amazon S3) في التحقق من السياسات. يتتبع الشكل 2 هذا الفصل عبر مستأجرين.
الشكل 2: فصل جلسات AgentCore بين المستأجرين. تُوقف كل microVM بعد الاستخدام مع تعقيم الذاكرة.
لذلك تصل شكوى مقدَّمة من معالج جودة في المستأجر A إلى خزينة الرموز والأدوات وبيئة الاختبار المعزولة الخاصة بالمستأجر A فقط في AgentCore Code Interpreter، وهي إحدى إمكانات Amazon Bedrock AgentCore. ولا يوجد لأجل المستأجر B أي طريق للوصول إلى أيٍّ منها.
التعامل مع المحتوى المستوعَب باعتباره غير موثوق
لم يكن لهذا التوتر إجابة نظيفة. فمرفق الشكوى هو مُدخل غير موثوق، لكنه في الوقت نفسه هو ما وُجد الوكيل لقراءته، لذا تعذّر رفض المحتوى المشتبه به. استقر الفريق على الدفاع في العمق.
تطبيق Octave Amazon Bedrock Guardrails فوق منطق الوكيل لا داخله، في ثلاث نقاط من سير عمل الشكوى. تقيّم واجهة ApplyGuardrail API النص المستخرج من المرفقات قبل التضمين، والمستندات المسترجعة ومخرجات الأدوات قبل دخولها سياق الوكيل، والمذكِّرة المُصاغة قبل رؤية المعالج لها. يُمرَّر المحتوى المستخرج من المرفقات مع وسم المدخلات، ليشير إلى أنه بيانات وليست تعليمات. هذا ما يجعل حَقنًا مدفونًا في منتصف المستند قابلاً للاكتشاف. وتُقنَّع المعلومات الشخصية القابلة للتحديد (PII) عند الدخول.
لم يكن الاكتشاف وحده كافيًا، فجاءت الوكالة المحدودة تحته. فمهما طُلب من الوكيل فعله، يستمر AgentCore Gateway في تنظيم الأدوات التي يمكنه استدعاؤها، وتشغيل استخراج المستندات في بيئة AgentCore Code Interpreter المعزولة دون أي خروج شبكي ودون أي persistence يتجاوز الجلسة. فالحمولة المخفية في ملف PDF يجب أن تتغلب على كل طبقة، لا على طبقة واحدة.
الأثر: تُتتبَّع معدلات الاكتشاف والتقنيع لكل مستأجر، فما التقطه الفرز أمر يمكن لـ Octave إثباته لا مجرد التأكيد عليه.
إدخال 2 مليار مستند عبر خط المعالجة
كانت المشكلة الأصعب تكمن أمام نموذج التضمين: استخراج محتوى قابل للاستخدام من ملفات Word وجداول البيانات وملفات PDF الرقمية والصفحات الممسوحة ضوئيًا والصور وسلاسل البريد الإلكتروني. وتظهر عدة لغات، أحيانًا داخل سجل واحد. وكان لا بد من أن يعمل بسرعة كافية بحيث يستغرق الإدخال يومًا بدلًا من ربع سنة. يتتبع الشكل 3 خط المعالجة الناتج من بدايته إلى نهايته.
الشكل 3: خط استيعاب البيانات: معالجة مستندات قائمة على الأحداث من منصة التطبيق عبر تنسيق Step Functions وصولاً إلى فهرس OpenSearch الخاص بكل مستأجر.
تتفرع أحداث المستندات عبر Amazon Simple Notification Service (Amazon SNS) وAmazon Simple Queue Service (Amazon SQS) إلى آلة حالات في AWS Step Functions. تنظّم تلك الآلة التحليل والتقسيم والتضمين عبر تنفيذات AWS Lambda متزامنة داخل Amazon Virtual Private Cloud (Amazon VPC) مخصص. ولأن التوازي يأتي من توزيع الدفعات على تنفيذات متعددة بدلًا من توسيع مورد واحد، تنمو الإنتاجية دون إعادة هندسة.
يتولى التحليل التعامل مع التباين: الحفاظ على التسلسل الهرمي الدلالي من ملفات Word وجداول البيانات، وتطبيق التعرف الضوئي على الحروف (OCR) على ملفات PDF الممسوحة التي تفتقر إلى طبقة نصية، ومعالجة الصور المدمجة كمحتوى كامل الأهلية. تحمل كل قطعة بيانات وصفية: المستأجر، ونوع المستند، والتطبيق المصدر، واللغة، وبصمة محتوى. وتلك البيانات الوصفية تقود كلًّا من فلترة الاسترجاع وفرض مساحة الأسماء الخاصة بكل مستأجر.
جاءت الإنتاجية من التعبئة. فتداخل قطع 4K عديدة في طلبات فردية مقابل نافذة سياق 128K في Embed v4 قلّص استدعاءات الـ API لقاعدة بيانات كبيرة بنحو ترتيب مقداره عشرة أضعاف. في اختبارات Octave الداخلية على Amazon Bedrock، قدّم Embed v4 معدل 28 مليون رمز في الدقيقة. وبعد ضبط أحجام الدفعات مع مهندسي حلول Cohere حتى زالت اختناقات الذاكرة، حافظ خط المعالجة على 1.4 مليون مستند كل 24 ساعة لكل عبء عمل مستأجر. هذا ما جعل التزام يوم العمل الواحد حقيقة.
مساعد فرز الشكاوى
يبلّغ مستشفى عن حقن معيبة لشركة مصنّعة للأجهزة الطبية، فيصل السجل مرفقًا معه بريد إلكتروني وصور للوحدات التالفة ووثائق داعمة. وعلى معالج الجودة أن يجمع السياق عبر تلك الصيغ، ويحدد ما إذا كان ما يشبهها قد سُجّل سابقًا، ويجد ما حلّها. عندها فقط يمكن تعيين أولوية، وغالبًا داخل نافذة إبلاغ تُقاس بالأيام.
بُني المساعد باستخدام Strands Agents SDK الذي طوّره AWS كمصدر مفتوح، ويركّب سير العمل الوكيلي كرسوم بيانية، تكون العقد فيها استدعاءات أدوات أو نداءات نموذج، والحروف تبعيات البيانات بينها. يشغّل AgentCore runtime تلك الرسم البياني ويعزلها لكل جلسة، وتنقل خمس مراحل الشكوى من المرفقات الخام إلى مذكِّرة مكتملة.
يأتي استخراج المستندات أولًا. تدخل ملفات PDF والصور ومرفقات البريد والفيديوهات جميعها إلى AgentCore Code Interpreter، الذي يحلل كل مُدخل إلى تمثيل وسيط مُهيكل. ثم يلخّص نموذج Claude على Amazon Bedrock السجل، ويصبح ذلك الملخص، لا المصدر الخام متعدد آلاف الرموز، استعلام الاسترجاع. ويشغّل الاسترجاع الاستعلام مقابل فهرس OpenSearch الخاص بالمستأجر لتضمينات Embed v4، فتظهر شكاوى سابقة مشابهة وخطط CAPA الخاصة بها، مع فرض AgentCore Gateway أن الوصول يقتصر على مساحات الأسماء المصرح بها فقط.
لا يُوثَق بما يعود على أساس التشابه وحده. فنداء نموذج منفصل يقيّم النتائج حسب درجة الثقة ويتخلص من المطابقات التي تتشارك المفردات لكنها تختلف في السبب الجذري. وما ينجو يذهب إلى التركيب، حيث يجمع Anthropic Claude Sonnet على Amazon Bedrock المخرجات: الحقائق الأساسية، والمشاعر، ومؤشرات الإلحاح، وأقرب السجلات التاريخية مع نتائجها، وأولوية فرز موصى بها.
تُخزَّن المذكرات المكتملة مؤقتًا في Amazon DynamoDB مع زمن بقاء (TTL) لكل بيئة، فلا تكلف المشاهدات المتكررة أي شيء إضافي. لم يعد المعالج يبدأ من الصفر، بل من الذاكرة المؤسسية.
يضع الشكل 4 ذلك المحرك خلف حدود API خاصة. يصل طلب البوابة إلى AgentCore runtime عبر Amazon API Gateway خاص ودالة Lambda، ويقرأ الاسترجاع فهرس المستندات عبر وصول قائم على الأدوار مع عناوين URL موقعة مسبقًا بينما تبقى المرفقات في Amazon S3. وتخرج الملخصات المخزنة مؤقتًا وآثار OpenTelemetry إلى جدول التلخيص ولوحة تقييم الأداء.
الشكل 4: محرك التلخيص: سير العمل المدعوم بـ AgentCore الذي يعالج استخراج المستندات والاسترجاع والاستدلال والتجميع داخل حدود API خاصة، مع تخزين مؤقت للاستجابات ورؤية كاملة.
يختزل الشكل 5 المسار نفسه في سطر واحد، مع ترشيح Guardrails عند الطرفين.
الشكل 5: مسار مساعد فرز الشكاوى من الاستيعاب حتى مخرجات معالج الشكوى
إثبات ما فعله الوكيل
الرصد هنا ليس فقط وسيلة فريق الهندسة لتصحيح الأخطاء بل أيضاً طريقة تكامله مع قدرات تدقيق النظام للوفاء بمتطلبات الامتثال. يمكن للمدقق أن يسأل لماذا رُفّعت شكوى معينة بالطريقة التي رُفّعت بها، وعبارة «قرر النموذج ذلك» لن تصمد أمام هذا الحوار.
يلتقط AgentCore آثاراً متوافقة مع OpenTelemetry عبر كل عقدة في الرسم البياني: كل استدعاء نموذج، وكل عملية استرجاع، وكل تشغيل لـ AgentCore Code Interpreter. وبعد شهور، يمكن لـ Octave أن تُظهر أي المستندات المسترجعة وأي التوجيهات (prompts) أنتجت ملخصاً معيناً. ويضيف تسجيل استدعاءات النموذج في Amazon Bedrock سجلاً لكل طلب واستجابة لكل مستأجر، محدد النطاق عبر هوية IAM التي ينشرها AgentCore، مع احتساب التكاليف على المستأجر المُطلق في Amazon CloudWatch.
دون الاتصال، تعيد AgentCore Evals تشغيل سير العمل مقابل الحقيقة المرجعية المُعلَّمة من الخبراء بعد أي تغيير في التوجيهات أو النماذج أو معلمات الاسترجاع، مع تقارير عن دقة التلخيص ودقة الاسترجاع عند K واكتمال المخرجات. التوجيه الذي يبدو أفضل لغوياً لكنه يسترجع بشكل أسوأ يُكتشف قبل أن يراه المستخدمون.
النتائج
يعمل مساعد فرز الشكاوى في بيئة الإنتاج منذ ثلاثة أشهر، والأرقام التالية تعكس تلك الفترة.
معالج الشكاوى الذي كان يفتح تحقيقاً دون أي شيء الآن يفتحه والتاريخ ذو الصلة مجمَّع مسبقاً. الساعات الـ4–6 التي تقيسها Octave لكل تحقيق هي العمل الذي استوعبه المسار: الاستخراج عبر الصيغ المختلفة، والبحث عن السوابق، والقراءة اللازمة للتمييز بين عيب مشابه فعلاً وتطابق في الصياغة.
كما غيّر هذا الأساس سرعة إصدار Octave للميزات. ووفقاً لحساباتها الخاصة، انتقلت دورات تطوير قدرات الذكاء الاصطناعي الجديدة من شهور إلى أسابيع. إعداد البيانات المشترك والتنفيذ الآمن والاسترجاع هي الطبقات الثلاث في الشكل 1. وقد خفّضت زمن النشر لكل حالة استخدام بنسبة 50 في المئة، لأن كل قدرة جديدة ترثها بدلاً من إعادة بنائها. وأدى ذلك إلى إطلاق البحث الدلالي في الربع 2، متقدماً ربعين على الهدف الأصلي في الربع 4.
نظرة استعادية
كان قرار بناء الأساس أولاً هو القرار الذي شكك فيه الفريق أكثر من غيره. فمن الصعب تبرير شهور من العمل في البنية التحتية عندما يريد أصحاب المصلحة ميزة ذكاء اصطناعي ملموسة. وقد أثبتت الجولة التالية من حالات الاستخدام صحة القرار. واختُمل القراران التاليان: عزل مدفوع إلى جلسات microVM ونشر الهوية بدلاً من كود التطبيق، وتقييم نماذج التضمين مقابل مجموعة بيانات Octave نفسها، وهو ما كشف مقايضة الأبعاد الـ512 التي لم يكن أي معيار قياس ليُظهرها.
كما رسم الفريق خطاً اختار عدم تجاوزه. المساعد يعرض السياق والسوابق، ومعالج الجودة هو من يتخذ القرار. في قطاع يحمل هذا القرار فيه وزناً تنظيمياً، شكّل هذا الحد ما أُتمت وما لم يُتم.
ما التالي
توسّع Octave الآن الأساس عبر حزمة Reliance. مراقبة الجاهزية للتدقيق، وتوليد روايات الحوادث، والتنبؤ بدرجات مخاطر الجودة هي التالي، وكل منها يُبنى على البنية التحتية نفسها.
إذا كانت منصتك تواجه توتراً مماثلاً: بيانات قيّمة خلف متطلبات عزل صارمة، فإن تجربة Octave تُظهر أن هذه المقايضات قابلة للمعالجة. لمعرفة المزيد عن الخدمات الكامنة وراء هذه القصة، راجع Amazon Bedrock، و وثائق Amazon Bedrock AgentCore، و Cohere on Amazon Bedrock. وللحصول على إرشادات معمارية ذات صلة، راجع حلول AWS المتجهية: ابنِ ذكاءً اصطناعياً وكيلياً حيث توجد بياناتك و توسيع نطاق الذكاء الاصطناعي الوكيلي: أنماط المؤسسات دون حبس البائع.