DSPy: من تعديل البرومبتات يدويًا إلى تحسينها بالبرمجة

جرى التحقق من المعلومات في 15 أكتوبر 2026 بالرجوع إلى وثائق DSPy الحالية وPyPI وأسعار نماذج Google. يسرد PyPI الإصدار DSPy 3.4.1، الصادر في 12 أكتوبر 2026، ويتطلب Python 3.10 أو أحدث، على أن يكون أقل من 3.16. اسم الحزمة المطلوب تثبيتها هو dspy. بيانات الحزمة على PyPI.

ما هو DSPy، وماذا تعني فيه عملية Compile؟

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

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

التوقيع يحدد المهمة المطلوبة

يحدد توقيع المهمة المدخلات والمخرجات والتعليمات. فالتوقيع "ticket -> category" يعني أن تذكرة دعم تدخل إلى البرنامج وتخرج منها فئة تصنيف. ويمكن للتوقيع المعرّف بصنف أن يضيف حقولًا محددة الأنواع وسلسلة توثيق تشرح المهمة. ويظل اختيار الحقول مسؤوليتك: لا تستطيع أداة التحسين معالجة غموض تعريف «عاجل» في سياق عملك. وثائق التوقيعات.

وحدات DSPy تحدد طريقة التنفيذ

تنفّذ الوحدة استراتيجية لإنجاز المهمة. تُعد dspy.Predict اللبنة الأساسية للتنبؤ. وتضيف dspy.ChainOfThought حقلًا للاستدلال قبل الإجابة، بينما تدعم dspy.ReAct حلقة تجمع بين الاستدلال واستخدام الأدوات. ويمكنك تركيب الوحدات معًا في Python حين لا تكفي خطوة واحدة من النموذج. وثائق الوحدات.

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

Compile عملية تحسين للبرنامج

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

شرح DSPy عمليًا: أبسط مثال في الوثائق الحالية

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

ثبّت الإصدار الذي جرى التحقق منه في بيئة Python لديك:

python -m pip install 'dspy[litellm]==3.4.1'

اضبط متغير البيئة GEMINI_API_KEY على مفتاح صالح لواجهة Google Gemini API. احفظ الشيفرة التالية باسم first_dspy.py، ثم شغّل python first_dspy.py:

import os
import dspy

lm = dspy.LM(
    "gemini/gemini-2.5-flash-lite",
    api_key=os.environ["GEMINI_API_KEY"],
    engine="litellm",
)
dspy.configure(lm=lm)

haiku_signature = "subject -> haiku"
haiku_generator = dspy.Predict(haiku_signature)
result = haiku_generator(subject="computer science")
print(result.haiku)

الأسطر الأربعة الأخيرة هي البرنامج الأول في الوثائق الحالية. ويتبع الإعداد طريقة تهيئة النموذج في DSPy، مع استخدام Google Gemini 2.5 Flash-Lite بدلًا من النموذج الوارد هناك، حتى تعتمد التجربة أدناه على نموذج واحد منخفض التكلفة. وتتبع سلسلة تعريف المزوّد تكامل Gemini في LiteLLM؛ كما تدعم واجهة DSPy LM API تحديد الخلفية صراحةً.

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

تحسين البرومبت في DSPy يبدأ بمعيار تقييم

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

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

للتجربة الأولية، استخدم 60 مثالًا مختلفًا، موزعة عمدًا إلى 20 للتدريب و20 للتحقق و20 للاختبار النهائي. هذه أحجام مقترحة للتجربة، وليست متطلبات يفرضها DSPy أو دليلًا على موثوقية النظام في الإنتاج.

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

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

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

أدوات تحسين DSPy الواردة في الوثائق الحالية

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

يسرد فهرس واجهات أدوات التحسين الحالي الأسماء التالية كما هي: BetterTogether، BootstrapFewShot، BootstrapFewShotWithRandomSearch، BootstrapFinetune، BootstrapRS، COPRO، Ensemble، GEPA، InferRules، KNN، KNNFewShot، LabeledFewShot، MIPROv2 وSIMBA.

ليست كل هذه الأسماء خوارزميات بحث مستقلة. فـBootstrapRS اسم بديل لـBootstrapFewShotWithRandomSearch، وKNN أداة مساعدة للاسترجاع تستخدمها KNNFewShot. ويذكر دليل الاختيار الحالي أيضًا AvatarOptimizer للبرامج التي تعمل بأسلوب الوكلاء، مع أنه غير موجود في فهرس الواجهات المذكور. تفاصيل عائلة الأدوات، دليل الاختيار.

تقترح MIPROv2 تعليمات، ثم تستخدم التحسين البايزي، وهو أسلوب بحث يسترشد بالدرجات السابقة، لاستكشاف توليفات من التعليمات والأمثلة التوضيحية. أما SIMBA فتعمل على دفعات مصغّرة وتقترح قواعد أو أمثلة توضيحية. هذان نهجان مختلفان، وليسا نسختين من BootstrapFewShot بأسماء جديدة. واجهة MIPROv2، واجهة SIMBA.

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

ضع حدودًا واضحة لتجربة التحسين الأولى

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

DSPy BootstrapFewShot: تجربة صغيرة عن قصد

جهّز الملفات train.jsonl وvalidation.jsonl وtest.jsonl، بحيث يحتوي كل منها على 20 تذكرة مختلفة مصنّفة بشريًا. كل سطر كائن JSON يحتوي على text وlabel؛ والتصنيفات المسموح بها هي billing وtechnical وaccount وother. على سبيل المثال، يمكن تصنيف طلب تغيير عنوان الفاتورة ضمن billing. يجب أن تكون هذه أمثلتك أنت، وليست مخرجات قصيدة الهايكو.

احفظ هذا البرنامج المنفصل باسم optimize_tickets.py وشغّله بعد ضبط مفتاح API نفسه:

import json
import os
from typing import Literal
import dspy

lm = dspy.LM(
    "gemini/gemini-2.5-flash-lite",
    api_key=os.environ["GEMINI_API_KEY"],
    engine="litellm",
    cache=False,
)
dspy.configure(lm=lm)

class RouteTicket(dspy.Signature):
    """Choose the support queue responsible for the ticket's main request."""
    text: str = dspy.InputField()
    label: Literal["billing", "technical", "account", "other"] = (
        dspy.OutputField()
    )

def load_examples(path):
    with open(path, encoding="utf-8") as source:
        rows = [json.loads(line) for line in source if line.strip()]
    assert len(rows) == 20
    return [dspy.Example(**row).with_inputs("text") for row in rows]

train = load_examples("train.jsonl")
validation = load_examples("validation.jsonl")
test = load_examples("test.jsonl")
assert len({e.text for e in train + validation + test}) == 60

def correct_label(example, prediction, trace=None):
    return prediction.label == example.label

program = dspy.Predict(RouteTicket)
evaluate = dspy.Evaluate(
    devset=validation, metric=correct_label, num_threads=1
)
print("Baseline validation:", evaluate(program).score)

optimizer = dspy.BootstrapFewShot(
    metric=correct_label,
    max_bootstrapped_demos=4,
    max_labeled_demos=0,
    max_rounds=1,
)
optimized = optimizer.compile(program, trainset=train)
print("Optimized validation:", evaluate(optimized).score)

# Freeze this candidate before opening the final test results.
final_test = dspy.Evaluate(
    devset=test, metric=correct_label, num_threads=1
)
print("Baseline final test:", final_test(program).score)
print("Optimized final test:", final_test(optimized).score)
optimized.save("candidate_ticket_router.json")

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

تُحسب عمليات التنفيذ في هذا التصميم كما يلي:

• خط الأساس على مجموعة التحقق: 20 عملية تنفيذ للبرنامج.
• التوليد من مجموعة التدريب: ما يصل إلى 20 عملية تنفيذ للنموذج المعلّم، وقد يقل العدد عند نجاح عدد كافٍ من الأمثلة التوضيحية.
• البرنامج المحسّن على مجموعة التحقق: 20 عملية تنفيذ للبرنامج.
• النسختان على مجموعة الاختبار النهائي: 40 عملية تنفيذ للبرنامج.

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

وفق أسعار Google المعلنة للنصوص ضمن الفئة المدفوعة Standard لنموذج Gemini 2.5 Flash-Lite، البالغة $0.10 لكل مليون توكن إدخال و$0.40 لكل مليون توكن إخراج، تبلغ تكلفة 100 استدعاء، بافتراض متوسط 1,000 توكن إدخال و100 توكن إخراج لكل استدعاء، $0.014: 100,000 ÷ 1,000,000 × $0.10 + 10,000 ÷ 1,000,000 × $0.40. أسعار Google.

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

DSPy أم البرومبتات اليدوية أم الضبط الدقيق للنموذج؟

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

يمكن الجمع بين هذه التقنيات. يتضمن DSPy أداة BootstrapFinetune، وتجمع BetterTogether بين تحسين البرومبتات والأوزان. والفارق العملي هو ما تغيّره وما تتولى صيانته، وليس أي تسمية تبدو أكثر تطورًا. تحسين البرومبتات والأوزان.

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

متى تبدأ باستخدامه، ومتى تنتظر أو تتجاوزه؟

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

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

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

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

ما الذي تبالغ الوعود المحيطة بـDSPy في تصويره؟

عبارة «البرمجة بدلًا من كتابة البرومبتات» لا تعني اختفاء البرومبتات. ينشئها DSPy ويديرها، لكن البشر يظلون مسؤولين عن تعريف المهمة والحكم على الإخفاقات وتحديد ما إذا كانت النتيجة مقبولة.

ولا تعني «Compile» أن النموذج تعلّم بصورة دائمة. مع أدوات تحسين البرومبتات، تتمثل حصيلة التعلّم في تعليمات أو أمثلة توضيحية. وما زلت تستدعي نموذجًا عند الاستدلال، كما تشغل الأمثلة التوضيحية مساحة داخل البرومبت. ويمكنك حفظ الحالة المتعلّمة بصيغة JSON وتحميلها في برنامج جديد. الحفظ والتحميل.

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

كذلك، استدعاءات معيار التقييم ليست استدعاءات المزوّد. يحدد max_metric_calls في GEPA ميزانية استدعاءات احتساب الدرجات؛ لكن المراجعة تستدعي نموذجًا أيضًا، وقد يرسل البرنامج الخاضع للتقييم عدة طلبات بنفسه. ولا تعني إعدادات auto وجود فاتورة موحّدة لكل الحالات. ضبط ميزانية GEPA.

أسئلة المهندسين الشائعة عن DSPy

ما الخطوة التالية؟

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

اشترك في النشرة لتصلك شروحات عملية في هندسة الذكاء الاصطناعي.