EDB تدمج طبقة دلالية للوكلاء داخل Postgres وتربطها بـ Bedrock

المشكلة الكلاسيكية في text-to-SQL هي أن الوكيل يرى أسماء الأعمدة، لكنه لا يفهم منطق الأعمال الكامن وراءها. فهو لا يعرف أن «العميل الكبير» لديكم يعني طلبا تتجاوز قيمته 250 دولارا، وأن العمود price يخزن إجمالي قيمة الطلب بالكامل. والنتيجة أرقام تبدو جميلة، لكنها خاطئة. في مقال جديد ضمن سلسلتها عن الطبقات الدلالية، تعرض AWS نهج EDB: عدم إنشاء نظام منفصل للدلالات، بل وضعها داخل Postgres نفسه حيث توجد البيانات.

كيف يعمل النظام

يتضمن EDB Postgres AI امتداد AIDB. وينشئ هذا الامتداد قاعدة معرفة دلالية، SemKB، فوق المخطط. وتضم تعريفات الجداول وطرق العرض والأعمدة إلى جانب النص المأخوذ من COMMENT ON. يتحول كل ذلك إلى تضمينات، فيبحث الوكيل عن الجدول المطلوب بحسب المعنى بدلا من الاسم. كما تتحول المفاتيح الخارجية تلقائيا إلى مسارات لربط الجداول.

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

يوضح مثال المقال تكلفة الخطأ بجلاء. فإذا قرأ الوكيل purchases.price باعتباره سعر الوحدة وضربه في الكمية، فستظهر قيمة أفضل عميل على أنها 502 529 دولارا بدلا من القيمة الحقيقية البالغة 27 991,66 دولارا. ويكفي تعليق واحد على العمود لسد هذه الفجوة.

كيف يصل الوكيل إلى البيانات

تعمل البنية على النحو التالي. يسجل المحلل دخوله عبر Amazon Cognito ويستدعي AgentCore Gateway باستخدام JWT. تتحقق Gateway من الرمز وسياسة Cedar، ثم توجه الطلب إلى بيئة تشغيل الوكيل المبنية على Strands Agents، حيث يضع Claude على Bedrock الخطة. ويستدعي الوكيل أدواته عبر MCP. يدعم خادم edb-endpoints المدمج في AIDB بالفعل بروتوكول MCP عبر HTTP متدفق مع مصادقة Basic، ولذلك تتصل به Gateway مباشرة عبر Application Load Balancer. ولا حاجة إلى وظائف Lambda أو طبقات وسيطة.

يخزن AgentCore Identity كلمة مرور دور Postgres ويدرجها في كل طلب صادر. ولا يرى كود الوكيل كلمة المرور هذه.

Postgres هو من يقرر الصلاحيات، لا الموجه

الجزء الأكثر فائدة في المقال يتعلق بالحوكمة. لا تملك نقطة نهاية MCP نظام أذونات خاصا بها؛ فما هو مسموح تحدده أوامر GRANT العادية. يفتح كل طلب اتصالا منفصلا باستخدام اسم الدخول الوارد في ترويسة Basic، ولذلك تكون قيمة current_user داخل الأداة هي دور الوكيل، وتظهر أيضا في pg_stat_activity.

ينشئ المؤلفون دورين. يرى mcp_agent_full كل شيء، بينما يرى mcp_agent_restricted كل شيء باستثناء customers.ssn. ويظل الموجه وكتالوج الأدوات وكود الوكيل متطابقة. عند طلب «اعرض خمسة عملاء مع أرقام الضمان الاجتماعي الخاصة بهم»، يحصل الدور الأول على البيانات، بينما يتلقى الثاني خطأ permission denied ينقله MCP من دون تعديل. ويمكن أيضا تفعيل الأمان على مستوى الصفوف كي ترى الأدوار المختلفة صفوفا مختلفة.

يبقى التدقيق داخل قاعدة البيانات أيضا. يكتب AIDB آثار OpenTelemetry الخاصة بتنفيذ SQL في المخطط aidb_otel، ويمكن تحليلها باستخدام SQL عادي. أما آثار AgentCore المتعلقة باستدعاءات الأدوات ونماذج LLM والرموز فتذهب إلى CloudWatch.

ما الذي يمكن فعله بهذا النهج

إذا كانت لديكم قاعدة Postgres تشغيلية وتبنون وكيلا للتحليلات أو الدعم، فابدؤوا بالخيار الأقل تكلفة: اكتبوا COMMENT للأعمدة غير الواضحة، وانقلوا مصطلحات الأعمال إلى طرق عرض. فهذا يحسن الدقة حتى من دون AIDB.

هناك قيود أيضا. يدور الحل حول منظومة EDB: ‏AIDB وصورة AMI الخاصة به وخادم MCP. تفهرس SemKB المخطط لا البيانات، ولذلك تعتمد الجودة على الانضباط في كتابة التعليقات. ولا تتوفر نماذج AWS في جميع المناطق. كما أن المثال مبني على مجموعة تجريبية صغيرة من أربعة جداول؛ أما مع مئات الجداول، فسيتعين اختبار جودة البحث الدلالي بصورة مستقلة.

الخلاصة: تزيل فكرة أن «الدلالات والصلاحيات تعيش بجوار البيانات» فئة كاملة من مشكلات مزامنة الكتالوجات، وتتيح الثقة بقيود الوصول أكثر من الثقة بالطلبات المكتوبة في موجه النظام.