في الأيام الأولى للنماذج اللغوية الكبيرة (LLMs)، كان التفاعل مع الذكاء الاصطناعي يتم بشكل أساسي عبر المحادثات. كنت تطرح سؤالاً، ويقدم النموذج استجابة نصية. وعلى الرغم من قوة هذا الأسلوب في العصف الذهني أو الكتابة الإبداعية، إلا أنه يفتقر إلى الكافية في بيئات الإنتاج. عند بناء تطبيقات تتطلب استخراج بيانات دقيق، أو تكاملات مع واجهات برمجة التطبيقات (API)، أو تحديثات لقواعد البيانات، فإن العشوائية تعد عبئاً وليست ميزة.
هنا تصبح المخرجات المهيكلة حاسمة. من خلال تقييد النموذج على إرجاع البيانات بتنسيق محدد - عادةً JSON - يمكن للمطورين بناء سير عمل قوي وحتمي. في هذا المنشور، سنستكشف كيفية إنفاذ الهيكلية باستخدام مخططات JSON، ولماذا يهم ذلك للتوسع، وكيفية تنفيذه بفعالية.
التحول من النص الحر إلى التفاعل القائم على المخطط
تقليدياً، كان استخراج البيانات من النماذج اللغوية الكبيرة يتطلب خطوات معالجة لاحقة. قد تطلب من النموذج وصف ملف تعريف المستخدم، ثم تستخدم التعبيرات النمطية (Regular Expressions) أو معالجة السلاسل النصية لاستخراج الاسم والبريد الإلكتروني والعمر. هذا النهج هش. إذا غيّر النموذج مخرجاته قليلاً (على سبيل المثال، باستخدام "العمر:" بدلاً من "العمر هو:")، فإن برنامج التحليل الخاص بك سيفشل.
تحل المخرجات المهيكلة هذه المشكلة من خلال تحديد الشكل المتوقع للاستجابة قبل أن يبدأ النموذج حتى في توليدها. فكّر في الأمر وكأنه توقيع دالة ذات أنواع قوية في البرمجة. بدلاً من نوع إرجاع عام string، تحدد كائناً يحتوي على حقول وأنواع محددة. تدعم معظم مزودي النماذج اللغوية الكبيرة الحديثة الآن إنفاذ مخطط JSON الأصلي، مما يعني أن النموذج مقيد رياضياً بالالتزام بالهيكلية التي تقدمها.
تنفيذ قيود مخطط JSON
للاستفادة من المخرجات المهيكلة، يجب عليك تعريف مخطط JSON يصف المخرجات المطلوبة. يعمل هذا المخطط كعقد بين تطبيقك ونموذج الذكاء الاصطناعي. فيما يلي مثال عملي لكيفية تعريف مخطط لنظام تحليل تذاكر دعم العملاء.
{
"type": "object",
"properties": {
"sentiment": {
"type": "string",
"enum": ["positive", "neutral", "negative"]
},
"priority_score": {
"type": "integer",
"minimum": 1,
"maximum": 10
},
"summary": {
"type": "string",
"maxLength": 280
},
"tags": {
"type": "array",
"items": {
"type": "string"
}
}
},
"required": ["sentiment", "priority_score", "summary", "tags"],
"additionalProperties": false
}
لاحظ التعريفات الصارمة. نستخدم enum للمشاعر لمنع النموذج من إرجاع "جيد"، "لطيف"، أو "إيجابي". نضع قيود minimum و maximum لدرجة الأولوية لضمان سلامة البيانات. توجيه additionalProperties: false بالغ الأهمية؛ فهو يخبر النموذج بعدم تضمين أي حقول إضافية لم يتم تعريفها في المخطط، مما يحافظ على نظافة الاستجابة وقابلية التنبؤ بها.
التنفيذ العملي في الكود
عند دمج ذلك في تطبيقك، تتغير مكالمة API قليلاً. تمرر المخطط كمعامل جنباً إلى جنب مع الأمر (Prompt). فيما يلي مثال برمجي توضيحي يبين كيف يبدو ذلك في تنفيذ SDK نموذجي.
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-3-sonnet-20240229",
max_tokens=1024,
messages=[
{"role": "user", "content": "Analyze this ticket: 'My internet has been down for 3 days and I am furious.'"}
],
# Pass the schema directly to the API
response_format={
"type": "json_schema",
"json_schema": {
"name": "ticket_analysis",
"schema": { ... # Insert schema from above ... }
}
}
)
# The output is guaranteed to be valid JSON matching the schema
parsed_response = json.loads(message.content[0].text)
print(parsed_response['priority_score'])
من خلال إنفاذ هذه الهيكلية على مستوى API، تقضي على الحاجة إلى حلقات معالجة أخطاء معقدة. إذا فشل النموذج في الامتثال، ترمي API خطأ تحقق، مما يتيح لتطبيقك معالجة الاستثناء بسلاسة بدلاً من الانهيار أثناء المعالجة اللاحقة.
الخاتمة
لم تعد المخرجات المهيكلة رفاهية؛ بل أصبحت ضرورة لأي مطور جاد بشأن دمج الذكاء الاصطناعي في تطبيقات الإنتاج. من خلال الابتعاد عن النصوص الحرة والاعتماد على التفاعلات القائمة على المخطط، تكسب الموثوقية، وسهولة تصحيح الأخطاء، وتكاملاً سلساً مع أنظمة الخلفية. مع تطور النظام البيئي، من المرجح أن نرى قيود أنواع أكثر تعقيداً ومخرجات مهيكلة متعددة الوسائط، مما يسد الفجوة بشكل أكبر بين الذكاء الاصطناعي التفاعلي ونماذج هندسة البرمجيات التقليدية.