استعارة بصرية تقابل بين رقاقة سيليكون ورموز البرهان الرياضي، خاصة بمجال التحقق من أشباه الموصلات.
Artificial IntelligenceSemiconductorHardware

الخطأ البرمجي بـ10 ملايين دولار الذي كتبه الذكاء الاصطناعي — ولماذا أسّست شركة للقضاء عليه

Ashutosh SinghalAshutosh Singhal2 مارس 202616 min

أتذكر اللحظة الدقيقة التي قررت فيها تأسيس Veriprajna.

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

كان السبب الجذري حالة تسابق. عدم تطابق وحيد ودقيق بين الإسنادات الحاجبة وغير الحاجبة في RTL — من النوع الذي يُحاكى بشكل مثالي، ويجتاز التدقيق دون همسة، ويجتاز كل اختبار انحدار تلقيه عليه، ثم يخونك في السيليكون حيث لا فرص ثانية.

كلّفت مجموعة الأقنعة لتلك الرقاقة بحجم 5 نانومتر نحو 10 ملايين دولار. ذهبت هباءً. لكن الضرر الحقيقي لم يكن الأقنعة. بل الأشهر الستة اللازمة للتشخيص والإصلاح وإعادة التحقق وإعادة التصنيع. في سوق مسرّعات الذكاء الاصطناعي، حيث تدوم أجيال المنتجات نحو 18 شهرًا، يمكن لتأخّر مدته ستة أشهر أن يقضم 50% من إجمالي الربح الإجمالي للمنتج طوال دورة حياته. بالنسبة لشركة تستهدف 100 مليون دولار من الإيرادات، لم تكلّف حالة التسابق تلك 10 ملايين دولار. بل كلّفت 50 مليون دولار.

وهذا هو الجزء الذي أرّقني ليلًا: الشيفرة التي تسببت فيها ولّدها نموذج لغة كبير.

حُمّى الذهب التي لا يشكّك فيها أحد

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

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

لكنني بعد ذلك بدأت أنظر بعناية أكبر إلى ما تعنيه «الصحة النحوية» فعليًا حين تكتب عتادًا بدلًا من برمجيات. وأدركت أن الصناعة كانت تبني على أساس من رمل.

الأدوات التي تغرق السوق الآن هي ما أسميه «المُغلِّفات». تأخذ نموذج لغة كبيرًا عام الغرض — GPT-4 أو Claude أو Llama — وتغلّفه في واجهة محادثة مع بعض مطالبات النظام ذات النكهة الفيريلوغية، وتبيعه بوصفه «مساعدًا طيّارًا لتصميم الرقاقات». بعضها عروض توضيحية مبهرة حقًا. تبدو الشيفرة نظيفة. وتُترجَم. بل وتُحاكى أيضًا.

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

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

ذلك اللاتماثل هو السبب الكامل لوجود Veriprajna.

لماذا يكتب الذكاء الاصطناعي شيفرة عتاد سيئة؟

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

هذا هو السؤال الذي يُطرح عليّ أكثر من غيره، عادةً من مهندسي برمجيات رأوا نماذج اللغة الكبيرة تكتب Python وظيفية تمامًا ولا يستطيعون فهم لماذا يختلف Verilog. الجواب أعمق من «العتاد أصعب». إنه عدم تطابق جوهري بين طريقة تفكير نماذج اللغة الكبيرة وطريقة عمل العتاد.

تُدرَّب نماذج اللغة الكبيرة بشكل ساحق على البرمجيات — Python وJava وC++ وJavaScript. هذه لغات أمرية تسلسلية. يُنفَّذ السطر A، ثم يليه السطر B. تُحدَّد حالة النظام بترتيب العمليات. لقد استوعبت نماذج اللغة الكبيرة هذا النموذج بعمق شديد حتى بات لغتها الأم عمليًا.

Verilog وVHDL تعريفيتان ومتزامنتان. في وحدة عتاد، كل كتلة always، وكل تعليمة assign، وكل تجسيد لوحدة، يُنفَّذ بشكل متزامن ومستمر. غالبًا ما لا يكون لترتيب الأسطر في الشيفرة المصدرية أي أثر على ترتيب التنفيذ في السيليكون.

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

حدّقت إحدى مهندساتي، بريا (Priya)، في المُخرَج لدقيقة ثم قالت: «إنه يكتب C مع فواصل منقوطة في الأماكن الخاطئة.» كانت محقّة تمامًا. كان نموذج اللغة الكبير يعاني من انحياز تسلسلي — إذ كان يتعامل مع Verilog كأنها لغة برمجة بينما هي في الحقيقة لغة وصف. الفرق دقيق نحويًا وكارثي فيزيائيًا.

ويزداد الأمر سوءًا. يعتمد تصميم العتاد على بروتوكولات واجهة صارمة — AXI وAHB وPCIe وTileLink — ذات قواعد زمنية معقدة. «يجب ألا تنتظر Ready إشارة Valid.» «يجب تفعيل Grant خلال 5 دورات.» يمكن لنماذج اللغة الكبيرة أن تولّد شيفرة تحترم هذه القواعد في 90% من الحالات، وهو ما يبدو رائعًا حتى تدرك أن الـ10% التي تخطئ فيها هي بالضبط الحالات الحدّية التي تقتل الرقاقات. جهازٌ رئيسي AXI يفعّل WVALID قبل AWREADY في انتهاك لبند فرعي محدد لن يُطلق خطأً نحويًا. بل سيُترجَم، ويُحاكى، ثم يتعلّق حين يُوصَل بوحدة تحكم ذاكرة متوافقة في السيليكون.

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

القاعدة التي تُطارد كل مصمم رقاقات

رسم معلوماتي يوضّح «قاعدة العشرة» — التصاعد الأُسّي لتكلفة إصلاح العيوب عبر خمس مراحل تصميمية، مع مبالغ مالية محددة مأخوذة من المقال.

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

تزداد تكلفة إصلاح العيب بمقدار 10 أضعاف في كل مرحلة لاحقة من دورة حياة التصميم. العيب الذي يُلتقط أثناء تصميم RTL تبلغ تكلفة إصلاحه نحو 100 دولار — يعدّل أحدهم ملفًا ويعيد تشغيل فحص. العيب نفسه إذا التُقط أثناء التحقق على مستوى الكتلة يكلّف 1000 دولار. وعند التحقق على مستوى النظام، 10٬000 دولار. وإذا أفلت إلى التحقق بعد التصنيع — حين تصحّح أخطاء رقاقات فعلية في المختبر — فأنت أمام 10 ملايين دولار أو أكثر لإعادة التصنيع. وإذا وصل إلى العملاء في الميدان؟ فتلك منطقة الـ100 مليون دولار. عمليات سحب، ودعاوى قضائية، وتدمير للعلامة التجارية. اسأل Intel عن خطأ Pentium FDIV.

تعمل أدوات الذكاء الاصطناعي «المُغلِّفة» حصريًا تقريبًا في مرحلة تصميم RTL. فهي تساعد المهندسين على كتابة الشيفرة بسرعة أكبر. لكن لأنها تفتقر إلى أي قدرة تحقق تتجاوز «هل تُترجَم؟»، فإنها تحقن عيوبًا تعبر التحقق على مستوى الكتلة والنظام، لتنفجر بعد ذلك في السيليكون.

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

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

شرحت هذا لأحد المستثمرين ذات مرة، في بدايات جولة تمويلنا. أنصت بصبر، ثم قال: «ألا يمكنك ببساطة استخدام GPT-4 مع مطالبات أفضل؟»

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

لم يسأل عن مطالبات أفضل مرة أخرى.

ماذا لو استطعت إثبات صحة الشيفرة بدلًا من مجرد اختبارها؟

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

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

التحقق الشكلي لا يشغّل التصميم على الإطلاق. بل يحوّل التصميم بأكمله إلى صيغة رياضية، ويستخدم حَلّالات «قابلية الإرضاء بحسب النظريات» (SMT) — أدوات مثل Z3 من Microsoft — ليثبت بشكل شامل أن خاصية ما تصمد في ظل كل تركيبة مدخلات ممكنة وكل حالة داخلية ممكنة. كل واحدة منها دون استثناء. ليست عيّنة. ليست تقريبًا إحصائيًا. بل برهان رياضي.

تسأل المحاكاة: «هل يعمل هذا في الحالات التي اختبرتها؟» أما التحقق الشكلي فيسأل: «هل توجد أي حالة ممكنة يفشل فيها هذا؟» الفرق هو الفرق بين الأمل والبرهان.

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

التحقق الشكلي موجود منذ عقود. والسبب في أنه لم يكتسح الصناعة هو أن كتابة الخصائص الشكلية — تأكيدات SystemVerilog، أو SVA — صعبة بشكل سيّئ السمعة. فهي تتطلب مجموعة مهارات متخصصة لا تمتلكها معظم فرق التصميم. التأكيدات هي «العقد» الخاص بالعتاد: «إذا ارتفع الطلب، فيجب أن يتبعه المنح خلال N دورات.» «البيانات المقروءة من العنوان X يجب أن تطابق آخر بيانات كُتبت إلى العنوان X.» «يجب ألا يتوقف خط الأنابيب أبدًا في حالة جمود.» كتابة هذه التأكيدات بشكل صحيح فنٌّ بحد ذاته، ولا يوجد ما يكفي من الممارسين لتغطية الحاجة.

وهذا بالضبط حيث يصبح الذكاء الاصطناعي مفيدًا — ليس لكتابة شيفرة العتاد، بل لكتابة البرهان.

«الشطيرة الشكلية» — كيف بنينا هذا فعليًا

رسم معماري لحلقة «الشطيرة الشكلية» يوضّح كيف تتدفق المواصفات إلى توليد قطعتين مزدوجتين (RTL + التأكيدات)، ثم التحقق عبر الحَلّال الشكلي، وحلقة التغذية الراجعة بالمثال المضاد رجوعًا إلى نموذج اللغة الكبير.

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

استقر بنا الأمر على ما نسميه «الشطيرة الشكلية» — بنية عصبية-رمزية يكون فيها نموذج اللغة الكبير هو المحرّك الإبداعي، وحَلّال التحقق الشكلي هو الناقد الذي لا يلين. لا يعمل أيٌّ منهما بمفرده. ومعًا، يفعلان شيئًا لا يستطيع أيٌّ منهما فعله بمفرده.

إليك كيف يعمل هذا عمليًا. يقدّم المصمم مواصفة — «صمّم جسرًا من APB إلى AXI» أو حتى لقطة شاشة لمخطط توقيت. يفكّك وكيلنا «محلّل المواصفات» هذا إلى متطلبات وظيفية. ثم يأتي الابتكار الجوهري: بدلًا من توليد الشيفرة فقط، يولّد نموذج اللغة الكبير مُخرَجَين اثنين في آنٍ واحد.

المُخرَج A هو تطبيق RTL — شيفرة Verilog نفسها. المُخرَج B هو المواصفة الشكلية — مجموعة من خصائص SVA مشتقة من المتطلبات نفسها. إذا قالت المواصفة «يجب أن يتبع المنحُ الطلبَ»، يولّد نموذج اللغة الكبير آلة الحالة والتأكيد الذي يثبت أن آلة الحالة تفعل ما تدّعيه.

ثم نطلق العنان للحَلّال. يأخذ المُخرَج A ويحاول كسره باستخدام المُخرَج B. أولًا، فحص خواء — للتأكد من أن التأكيدات ليست صحيحة بشكل تافه (توليد «كسول» لا يتحقق فيه شرط التحفيز أبدًا). ثم فحص النموذج المحدود، مستكشفًا فضاءات حالة عميقة — بعمق 50 و100 دورة — بحثًا عن حالات الجمود، وحالات التسابق، وانتهاكات البروتوكول.

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

يحلّل نموذج اللغة الكبير الأثر، ويحدّد انتقال الحالة المفقود، ويعيد كتابة الشيفرة. ثم يتحقق الحَلّال مجددًا. تتكرر هذه الحلقة تلقائيًا حتى يُثبَت أن التصميم صحيح.

كتبت عن هذه البنية بعمق أكبر بكثير في النسخة التفاعلية من بحثنا، لكن الفكرة الجوهرية بسيطة: نستخدم الذكاء الاصطناعي لكتابة البرهان، والرياضيات للتحقق من الذكاء الاصطناعي. لا يثق أيٌّ منهما بالآخر. وكلاهما يجعل الآخر أفضل.

العيوب التي جعلتني مؤمنًا

أصبحت مؤمنًا حقيقيًا بهذا النهج لا عبر النظرية بل عبر عيوب محددة التقطناها ما كان لأي شيء آخر أن يجدها.

أنتج مجتمع RISC-V مفتوح المصدر أنوية معالجات ممتازة حقًا — Ibex (المستخدمة في رقاقة الأمان OpenTitan من Google)، ومنصة PULP من ETH Zurich. هذه تصاميم خضعت لتدقيق مكثّف وتقف وراءها مواهب هندسية حقيقية. ومع ذلك لا تزال تحتوي على عيوب لا يمكن أن يجدها إلا التحقق الشكلي.

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

في منصة PULP، عُثر على خطأ حيث يمكن للربط البيني AXI أن يجوّع جهازًا رئيسيًا على الناقل إلى ما لا نهاية في ظل نمط «انشغال» محدد من تفاعلات AWVALID وAWREADY. إنه فشل حيوية كلاسيكي — لا ينهار النظام، بل يتوقف فقط عن إحراز أي تقدم. لن تكتب أبدًا اختبارًا موجّهًا لذلك النمط التفاعلي المحدد. فالأنماط الممكنة أكثر من أن تُحصى.

حين نوجّه Veriprajna نحو وحدة تحميل-تخزين في RISC-V، فإنها تولّد تلقائيًا تأكيدات للامتثال للواجهة («إذا فُعّلت إشارة valid، فيجب أن تظل مرتفعة حتى ready»)، ولسلامة البيانات («البيانات المقروءة من العنوان X تطابق آخر كتابة إلى العنوان X»)، وللتقدّم الأمامي («يجب أن تُرجع الوحدة استجابة في نهاية المطاف»). هذه ليست أفكارًا لاحقة مُثبّتة على الشيفرة. بل تُولَّد جنبًا إلى جنب مع الشيفرة، من المواصفة نفسها، وتُفرَض قبل أن يغادر سطر واحد من RTL نظامنا.

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

«لكن التحقق الشكلي لا يتوسّع»

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

لقد بذلنا جهدًا كبيرًا في هذا. يستخدم نظامنا تقنيات تجريد آلية لجعل الأساليب الشكلية قابلة للمعالجة على نطاق واسع. الصندقة السوداء تتيح لنا التحقق من منطق الربط مع معاملة الكتل الفرعية الكبيرة مثل ذاكرات RAM أو وحدات ALU المعقدة ككيانات مجردة ذات واجهات محددة. نقاط القطع تفصل مسارات المصافحة valid/ready كي نتمكن من التحقق من التحكم في التدفق باستقلال عن معالجة البيانات. تقليل التماثل يتيح لنا إثبات خاصية لقناة واحدة من موجّه متعدد المنافذ ثم استنتاجها رياضيًا لجميع القنوات الـN.

هل حُلّت المشكلة بالكامل؟ لا. ستطرح الفيزياء التناظرية دائمًا تحديات لا يمكن للأساليب الشكلية أن تمسّها. لكن العيوب المنطقية — حالات التسابق، وحالات الجمود، وانتهاكات البروتوكول — تصبح مستحيلة رياضيًا في الشيفرة المولّدة. وتلك هي العيوب التي تسبب إعادة التصنيع.

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

الحقيقة المزعجة عن «الرقاقات المصمَّمة بالذكاء الاصطناعي»

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

نحن نبني باتجاه سير عمل وكيلي (agentic) تتعاون فيه وكلاء ذكاء اصطناعي مستقلون — وكيل «مهندس معماري» للتقسيم عالي المستوى، و«مبرمج RTL» للتنفيذ، و«مهندس تحقق» لكتابة منصات الاختبار والتأكيدات، و«مدير» لتنسيق التدفق في ظل قيود الطاقة والأداء والمساحة. نستخدم التوليد المعزَّز بالاسترجاع (RAG) ليس للشيفرة فحسب بل للمعرفة — بجلب قواعد بروتوكول محددة، وقيود مجموعة تصميم العملية، ومعايير الترميز الداخلية كي يولّد نموذج اللغة الكبير شيفرة ممتثلة دون هلوسة.

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

مشكلة صناعة أشباه الموصلات ليست أن الذكاء الاصطناعي بطيء جدًا في كتابة شيفرة العتاد. بل أنه سريع جدًا في كتابة شيفرة عتاد خاطئة بشكل خفيّ.

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

القرار قد اتُّخذ بالفعل

لم يعد بوسع صناعة أشباه الموصلات تحمّل نهج «ولّد وادعُ». «قاعدة العشرة» ليست اقتراحًا — إنها الفيزياء والاقتصاد يتآمران لمعاقبة كل من يشحن سيليكونًا غير متحقَّق منه. عند 5 نانومتر وما دونها، مع مجموعات أقنعة تقترب من 20 مليون دولار، انهار هامش الخطأ إلى الصفر.

كل أسبوع، أتحدث إلى فرق تصميم متحمسة لما يمكن لنماذج اللغة الكبيرة أن تفعله لإنتاجيتها ومرعوبة مما قد تفعله بجدول التصنيع النهائي (tape-out). إنها محقّة في الشعور بالأمرين في آنٍ واحد. التقنية تحويلية حقًا. وهي أيضًا خطيرة حقًا دون شبكة أمان.

Veriprajna هي شبكة الأمان تلك. نمنحك سرعة الذكاء الاصطناعي مع يقين الرياضيات. ليس «صحيح على الأرجح». ولا «اجتاز الانحدار». مثبَت الصحة، عبر كل مدخل ممكن، وكل حالة ممكنة، وكل حالة حدّية ممكنة لن تفكّر محاكاةٌ أبدًا في اختبارها.

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

أعرف على أيٍّ منهما سأراهن بـ10 ملايين دولار.

أبحاث ذات صلة

منشور أيضًا على

ابنِ ذكاءك الاصطناعي بثقة.

تعاون مع فريق يمتلك خبرة عميقة في بناء الجيل القادم من الذكاء الاصطناعي للمؤسسات. دعنا نساعدك على تصميم استراتيجية ذكاء اصطناعي جديرة بثقتك وبنائها وتطبيقها.

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