مخطِّط السفر بالذكاء الاصطناعي يكذب عليك — ولن تكتشف ذلك حتى تعلق بلا مأوى

راسلَتنا امرأة العام الماضي بلقطة شاشة. كانت قد استخدمت مخطِّط سفر بالذكاء الاصطناعي شائعًا لحجز رحلة عائلية إلى كوستاريكا. أوصى الذكاء الاصطناعي بمكان اسمه شيء مثل "Tabacon Springs Eco-Lodge" — أوصاف غنّاء، وسعر أقل من 200 دولار لليلة، وصور بدت مطابقة. حجزت تذاكر طيران لأربعة أشخاص. استأجرت سيارة. أخبرت أطفالها أنهم ذاهبون لمشاهدة القرود من بيت على شجرة.

لم يكن النُّزُل موجودًا.

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

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

لماذا يخترع الذكاء الاصطناعي لديك فنادق غير موجودة؟

إليك ما لا يفهمه معظم الناس عن النماذج اللغوية الكبيرة — GPT-4 وClaude وGemini، جميعها. إنها لا "تعرف" الأشياء كما تعرفها قاعدة بيانات. نظام حجز فندقي يعرف أن الغرفة 412 في فندق JW Marriott محجوزة من 3 مارس إلى 7 مارس. تلك حقيقة، مخزّنة في صفٍّ، وقابلة للاستعلام.

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

في الكتابة الإبداعية، يُسمّى هذا المزج خيالًا. في السفر، يُسمّى هلوسة. والنموذج لا يملك أي وسيلة للتمييز بين الاثنين.

النموذج يُحسِّن من أجل التماسك، لا الصحّة. إنه مصمَّم لإنتاج ردٍّ يبدو كإجابة صحيحة، لا ردٍّ هو إجابة صحيحة مُتحقَّق منها مقابل المخزون الآني.

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

الليلة التي أدركتُ فيها أن الطلاقة هي المشكلة

ثمة لحظة أعود إليها مرارًا. كنّا نختبر نموذجًا أوليًّا مبكرًا — لا منتجًا أطلقناه، بل تجربة داخلية لفهم كيفية تعامل النماذج اللغوية الكبيرة مع استعلامات السفر. طلبتُ منه أن يجد لي فندقًا قرب سنترال بارك بأقل من 250 دولارًا لليلة خلال أسبوع الموضة في نيويورك.

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

ثم أجرى أحد مهندسيَّ — رجل هادئ، منهجي للغاية — الاستعلام نفسه مقابل واجهة برمجة تطبيقات Amadeus Hotel Search. اثنان من الفنادق الثلاثة كانا موجودَين لكن دون توافر خلال أسبوع الموضة. اسم الفندق الثالث كان قريبًا من عقار حقيقي لكنه لم يطابق أي معرّف فندق في النظام. أما البار على السطح؟ فكان يخصّ فندقًا مختلفًا تمامًا يبعد ستة مربّعات سكنية.

كانت تلك الليلة التي أدركتُ فيها أن الخطر ليس ذكاءً اصطناعيًا يفشل بشكل واضح. روبوت محادثة يقول "لا أفهم سؤالك" مُحبِط لكنه غير ضار. الخطر هو ذكاء اصطناعي يفهم سؤالك فهمًا تامًّا ويردّ بمعلومات بليغة ومقنعة وخاطئة واقعيًّا. بدأنا نسمّي هذا"الوادي الغريب" للموثوقية — ذكاء النظام اللفظي عالٍ إلى حدٍّ يجعل المستخدمين يُسقِطون حذرهم في التحقّق من الوقائع.

قضية روبوت محادثة Air Canada جعلت هذا ملموسًا بالمعنى القانوني. اختلق روبوت محادثة سياسة استرداد. قضت المحكمة بأن شركة الطيران مسؤولة — لا مورّد الذكاء الاصطناعي، ولا روبوت المحادثة بوصفه "أداة تجريبية". الشركة التي نشرت الوكيل كانت مسؤولة عن تصريحات الوكيل. إن وعد ذكاؤك الاصطناعي بجناح بإطلالة على البحر مقابل 200 دولار، ولم يكن لدى نظام التوزيع العالمي سوى غرفة عادية بـ400 دولار، فقد تكون مُلزَمًا بدفع الفرق. أو الأسوأ، بتعويض الرحلة المُفسَدة.

ماذا يحدث حين تعامل النموذج اللغوي الكبير بوصفه الدماغ بدلًا من الفم؟

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

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

لذا اتخذنا قرارًا غيّر كل ما بنيناه بعده: النموذج اللغوي الكبير لن يكون أبدًا مصدر معلومات السفر. سيكون موجّه القصد.

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

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

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

نمط المنسِّق-العامل: لماذا لا يكفي وكيل واحد

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

لذا بنينا ما نسمّيهنمط المنسِّق-العامل. تخيّله كمستشار سفر كبير لا يلمس لوحة مفاتيح قط، يدير فريقًا من المتخصّصين يؤدي كلٌّ منهم أمرًا واحدًا ببراعة فائقة.

المنسِّق نموذج عالي الاستدلال — GPT-4o أو Claude 3.5 Sonnet — يتحدّث إلى المستخدم، ويحتفظ بسجلّ المحادثة، ويقرّر ما يجب أن يحدث. إنه لا يلمس نظام التوزيع العالمي مباشرةً. وتحته يجلس عمّال متخصّصون: عامل رحلات يتحدّث بواجهات Amadeus Air ويفهم رموز IATA، وعامل فنادق يتحدّث بخدمات محتوى Sabre للإقامة ويعرف الفرق بين العربون والضمان، وعامل سياسات يتحقّق من قواعد سفر الشركات قبل عرض أي شيء.

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

كانت الفكرة الجوهرية هي فصلالتفكير عنالفعل. المنسِّق يفكّر. العمّال يفعلون. ولا يتظاهر أحدهما بأنه الآخر.

لماذا كادت "200 OK" تخدعنا

إليك قصة لا تزال تُشعِرني بالانقباض. كنّا منغمسين في اختبار التكامل مع واجهات حجز Sabre. كان عامل الفنادق لدينا يرسل طلب حجز، ويتلقّى استجابة HTTP 200 — التي تعني في تطوير الويب "نجاح" — ويمرّرها إلى المنسِّق. فيخبر المنسِّق المستخدم: "تمّ حجزك!"

إلا أنه لم يكن كذلك. ليس دائمًا.

استغرقنا وقتًا طويلًا بشكل محرِج لكي نتنبّه لهذا. كانت استجابة HTTP هي 200 لأنالرسالة سُلّمت بنجاح. لكن داخل جسم الاستجابة، كان رمز حالة قطاع نظام التوزيع العالميUC — تعذّر التأكيد. كان الفندق قد رفض الطلب، عادةً لأن التوافر المخزَّن مؤقتًا كان قديمًا. كانت الغرفة قد بِيعت في المللي ثوانٍ بين البحث ومحاولة الحجز.

الانفصال بين طبقة النقل وطبقة التطبيق فخّ كلاسيكي، وقد وقعنا فيه تمامًا. قالت 200 OK على مستوى HTTP "وصلت رسالتك". وقالتUC على مستوى نظام التوزيع العالمي "فشل حجزك". كان نظامنا يقرأ المظروف ويتجاهل الرسالة بداخله.

عندئذٍ نفّذنا ما أعتبره الآن أهمّ جزء في بنيتنا المعمارية:حلقة التحقّق. تمرّ كل استجابة حجز عبر خطوة تحقّق منفصلة — إما فحص رمز حتمي أو مطالبة متخصّصة تعمل كمُدقِّق جودة — قبل أن يصل أي تأكيد إلى المستخدم. القاعدة قاطعة:

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

HK تعني أن المخزون مؤمَّن. UC تعني أن الفندق رفضك. NN تعني أن الطلب معلّق — لا تَعِد بشيء بعد. NO تعني أنه لم يُتَّخَذ أي إجراء. هذه الرموز هي الفرق بين غرفة محجوزة ومسافر عالق، ومعظم أنظمة السفر بالذكاء الاصطناعي لا تحلّلها أصلًا.

للاطّلاع على التفصيل التقني الكامل لمعالجتنا لرموز الحالة وبنية التحقّق، انظرورقتنا البحثية.

كيف يتعامل وكيل الذكاء الاصطناعي مع "الغرفة بيعت للتو"؟

هنا تُثبِت الأنظمة الوكيلية جدواها. تفاوت "البحث مقابل الحجز" (Look-to-Book) متوطّن في السفر — تبحث، وترى التوافر، وتنقر للحجز، فإذا بالغرفة قد اختفت. يحدث هذا باستمرار خلال مواسم الذروة. الذكاء الاصطناعي القائم على الغلاف لا يملك مفردات لهذا الموقف. فإما يقول "لقد حجزتها!" (خطأ) أو "فشل الأمر" (غير مفيد). لا يستطيع أن يقول "كانت موجودة قبل لحظة، لكن شخصًا آخر اختطفها — وإليك خيارك الأفضل التالي".

وكلاؤنا يستطيعون. حين يعود حجز بـUC، يُطلِق النظام تلقائيًّا بحثًا جديدًا عن التوافر للفندق نفسه. إن توفّرت غرفة أو تعرفة مختلفة، يعرض الخيار: "التعرفة السابقة نفدت، لكنني وجدتُ غرفة مماثلة مقابل 10 دولارات إضافية." وإن لم يتوفّر شيء، يسحب الفندق الأفضل التالي من نتائج البحث الأصلية ويعرضه بدلًا منه. يتطلّب هذا من الوكيل أن يحتفظ بـحالة — ذاكرة لما بحث عنه بالفعل، وما رفضه المستخدم بالفعل، وما كانت البدائل. الأغلفة عديمة الحالة. لا تستطيع فعل هذا. تبدأ من الصفر في كل مرة، أو تهلوس الاستمرارية.

مشكلة التوحيد التي لا يتحدّث عنها أحد

أمر واحد فاجأني — فاجأني حقًّا — هو مدى اختلاف بنى البيانات بين Amadeus وSabre. يُرجِع Amadeus الأسعار مقسَّمة إلى أساسية وإجمالية وضرائب في JSON متداخل صارم. أما Sabre فيدمج الضريبة أحيانًا، ولا يدمجها أحيانًا، بحسب خطة التعرفة. أسماء الحقول تختلف. amount في نظام هوtotalPrice في آخر.

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

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

"استخدم GPT فحسب" — وأشياء أخرى يقولها المستثمرون

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

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

التوليد المعزَّز بالاسترجاع يساعد في المعرفة الثابتة — "ما سياسة التأشيرة لتايلاند؟" — لكنه لا يستطيع أن يخبرك إن كانت الرحلة AA123 بها مقاعد متاحةالآن. الضبط الدقيق يساعد في النبرة ومفردات المجال، لكنه لا يربط النموذج بالمخزون الحيّ. مطالبة نظام أفضل تساعد في التنسيق، لكنها لا تمنع النموذج من توليد اسم فندق غير موجود في أي نظام توزيع عالمي.

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

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

ماذا عن الجزء البطيء؟

لن أتظاهر بأن الأنظمة الوكيلية سريعة. طلب مستخدم واحد قد يُطلِق أربع استدعاءات أدوات — بحث، وفحص سعر، وفحص سياسة، وتركيب استجابة. قد يستغرق ذلك 10–15 ثانية. في التجارة الإلكترونية، تلك أبدية.

نتعامل مع هذا بثلاث طرق. أولًا، نبثّ استدلال الوكيل للمستخدم مباشرةً: "جارٍ البحث في Amadeus عن رحلات…" "جارٍ التحقّق من سياسة سفر الشركة…" إظهار العمل يقلّل من زمن الاستجابة المُدرَك بشكل كبير. ثانيًا، نُشغِّل العمّال بالتوازي — عامل الرحلات وعامل الفنادق يبحثان في آنٍ واحد بدلًا من التتابع، ما يقلّص إجمالي زمن الانتظار إلى النصف تقريبًا. ثالثًا، نخزّن نتائج التوافر مؤقتًا لمدة 15 دقيقة في Redis. إن قال المستخدم "أرِني ذلك الفندق الثاني مجددًا"، فإننا لا نطرق نظام التوزيع العالمي مرة أخرى. بل نسحب من الذاكرة المؤقتة.

هل هو بسرعة غلاف يختلق إجابة في ثانيتين؟ لا. هل هو بالسرعة التي يحتاجها مستخدم يريد إجابةحقيقية؟ نعم.

الجزء الذي أعترف فيه بما لا نستطيع فعله بعد

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

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

إلى أين يمضي هذا بعدئذٍ

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

لا شيء من ذلك ممكن على غلاف. ولا شيء منه يعمل إن كان النظام يهلوس. كل قدرة من تلك القدرات تتطلّب البنية المعمارية ذات الحالة والمتحقَّق منها والمؤرَّضة بالأدوات التي ما فتئنا نبنيها.

صناعة السفر عند نقطة تحوّل. الموجة الأولى من تبنّي الذكاء الاصطناعي — الأغلفة، وروبوتات المحادثة، وتجارب "أضِف GPT فحسب" — أنتجت شيئًا مُغريًا وخطيرًا: أنظمة تبدو كأفضل وكيل سفر التقيتَه على الإطلاق لكنها لا تستطيع فعليًّا حجز غرفة. الموجة التالية ستتحدّد بسؤال أصعب وأقلّ بريقًا: ليس "هل يستطيع الذكاء الاصطناعي كتابة مسار سفر جميل؟" بل "هل يستطيع الذكاء الاصطناعي أن يؤكّد أن كل عنصر في ذلك المسار موجود فعلًا، الآن، بالسعر الذي اقتبسه؟"

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