إنتاج البحث الدلالي: كيف قمنا ببناء وتوسيع نطاق البنية التحتية للمتجهات في Airtable

نُشرت هذه التدوينة في الأصل على قناة Airtable Medium وأعيد نشرها هنا بإذن.

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

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

الخلفية

هدفنا في Airtable هو مساعدة العملاء على العمل مع بياناتهم بطرق قوية وبديهية. ومع ظهور آليات البحث الدلالي القوية والدقيقة على نحو متزايد، أصبحت الميزات التي تستفيد من المعنى الدلالي لبياناتك جوهر منتجنا.

كيف نستخدم البحث الدلالي

أومني (دردشة الذكاء الاصطناعي من Airtable) للإجابة على أسئلة حقيقية من مجموعات البيانات الكبيرة

تخيل طرح سؤال بلغة طبيعية على قاعدتك (قاعدة بياناتك) التي تحتوي على نصف مليون صف، والحصول على إجابة صحيحة غنية بالسياق. على سبيل المثال:

"ما الذي يقوله العملاء عن عمر البطارية في الآونة الأخيرة؟

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

• فهم القصد الدلالي للاستعلام
• استرجاع الصفوف الأكثر صلة من خلال البحث عن التشابه المتجهي
• تزويد تلك الصفوف كسياق ل LLM

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

توصيات السجل المرتبط: المعنى على التطابقات التامة

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

ويتطلب تقديم هذه الاقتراحات عند الطلب استرجاع دلالي عالي الجودة مع زمن انتقال ثابت ومتوقع.

أولويات التصميم لدينا

لدعم هذه الميزات وأكثر من ذلك، قمنا بترسيخ النظام حول 4 أهداف:

• استعلامات منخفضة الكمون (500 مللي ثانية في الدقيقة 99): الأداء المتوقع أمر بالغ الأهمية لثقة المستخدم
• عمليات الكتابة عالية الإنتاجية: تتغير القواعد باستمرار، ويجب أن تظل التضمينات متزامنة
• قابلية التوسع الأفقي: يجب أن يدعم النظام ملايين القواعد المستقلة.
• الاستضافة الذاتية: يجب أن تظل جميع بيانات العميل داخل البنية التحتية التي تتحكم فيها Airtable

شكّلت هذه الأهداف كل قرار معماري تم اتخاذه بعد ذلك.

تقييم بائع قاعدة بيانات المتجهات

في أواخر عام 2024، قمنا بتقييم العديد من خيارات قواعد البيانات المتجهة واخترنا في النهاية Milvus بناءً على ثلاثة متطلبات رئيسية.

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

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

تصميم البنية

بعد اختيار التقنية، كان علينا بعد ذلك تحديد بنية لتمثيل شكل بيانات Airtable الفريد من نوعه: ملايين "القواعد" المتميزة المملوكة لعملاء مختلفين.

تحدي التقسيم

قمنا بتقييم استراتيجيتين أساسيتين لتقسيم البيانات:

الخيار 1: الأقسام المشتركة

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

الخيار 2: قاعدة واحدة لكل قسم

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

الاستراتيجية النهائية

اخترنا الخيار 2 لبساطته وعزله القوي. ومع ذلك، أظهرت الاختبارات المبكرة أن إنشاء 100 ألف قسم في مجموعة Milvus واحدة تسبب في تدهور الأداء بشكل كبير:

• زاد زمن إنشاء القسم من 20 مللي ثانية تقريبًا إلى 250 مللي ثانية تقريبًا
• تجاوزت أوقات تحميل الأقسام 30 ثانية

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

الفهرسة والاستدعاء

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

• IVF-SQ8: يقدم بصمة ذاكرة صغيرة ولكن استدعاء أقل.
• HNSW: يوفر أفضل استرجاع (99%-100%) ولكنه متعطش للذاكرة.
• DiskANN: يوفر استرجاعًا مشابهًا ل HNSW ولكن مع زمن استعلام أعلى

في النهاية، اخترنا HNSW لخصائصه المتفوقة في الاستدعاء والأداء.

طبقة التطبيق

على مستوى عالٍ، يتضمن خط أنابيب البحث الدلالي في Airtable تدفقين أساسيين:

1. تدفق الاستيعاب: تحويل صفوف Airtable إلى تضمينات وتخزينها في Milvus
2. تدفق الاستعلام: تضمين استعلامات المستخدم، واسترداد معرّفات الصفوف ذات الصلة، وتوفير السياق إلى LLM

يجب أن يعمل كلا التدفقين بشكل مستمر وموثوق به على نطاق واسع، وسنستعرض كل منهما أدناه. نستعرض كل منهما أدناه.

تدفق الاستيعاب: الحفاظ على مزامنة ميلفوس مع Airtable

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

تدفق الاستعلام: كيف نستخدم البيانات

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

التحديات التشغيلية وكيف قمنا بحلها

بناء بنية بحث دلالي هو أحد التحديات؛ وتشغيلها بشكل موثوق لمئات الآلاف من القواعد هو تحدٍ آخر. فيما يلي بعض الدروس التشغيلية الرئيسية التي تعلمناها على طول الطريق.

النشر

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

في الإصدار 2.5، تتكون مجموعة Milvus من هذه المكونات الأساسية:

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

من خلال الأتمتة التي تعتمد على CRD وخط أنابيب اختبار صارم، يمكننا طرح التحديثات بسرعة وأمان.

إمكانية المراقبة: فهم صحة النظام من البداية إلى النهاية

نراقب النظام على مستويين لضمان بقاء البحث الدلالي سريعاً وقابلاً للتنبؤ.

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

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

تدوير العقدة

لأسباب تتعلق بالأمان والامتثال، نقوم بتدوير عقد Kubernetes بانتظام. في مجموعة البحث المتجه، هذا أمر غير تافه:

• عندما يتم تدوير عقد الاستعلام، سيعيد المنسق موازنة البيانات داخل الذاكرة بين عقد الاستعلام
• يخزن كافكا و Etcd معلومات الحالة ويتطلبان نصابًا وتوافرًا مستمرًا

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

تفريغ القسم البارد

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

استعادة البيانات

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

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

ماذا بعد

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

نشكر جميع العاملين السابقين والحاليين في Airtablets في البنية التحتية للبيانات وعبر المؤسسة الذين ساهموا في هذا المشروع: أليكس سوروكين، وأندرو وانغ، وآريا ملكاني، وكول ديرمون-مور، ونبيل فاروقي، وويل باولسون، وشياو بينغ شيا.

نبذة عن Airtable

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