RAG أم Fine-Tuning أم AI Agent؟ افهم المشكلة قبل اختيار التقنية

شركة تقول:

"إحنا عايزين ندرّب AI على بياناتنا."

الجملة دي ممكن تصف مشاكل مختلفة تمامًا.

ممكن الموظفين محتاجين إجابات من Internal Documents.

ممكن Model كل مرة تنتج Output بأسلوب غير المطلوب.

وممكن System محتاجة تحدث CRM بعد ما تفهم طلب العميل.

المشاكل دي مش تلقائيًا لها نفس الحل.

RAG وFine-Tuning وAI Agents كثيرًا ما يتم الكلام عنهم كأنهم تقنيات متنافسة، لكن في الحقيقة كل واحدة بتحل Layer مختلفة من AI System.

بداية مفيدة هي:

إيه اللي ناقص الـModel: معرفة، سلوك، ولا القدرة على التنفيذ؟

السؤال ده ممكن يوفر Engineering كثيرة غير ضرورية.

الخلاصة السريعة

لو Model محتاجة Current أو Private Knowledge، افحص RAG.

لو Model محتاجة Learned Behavior أو Task Pattern والـPrompting وحدها مش بتوفره بثبات، افحص Fine-Tuning.

لو System محتاجة تنفذ Actions باستخدام Tools وWorkflows، افحص AI Agent أو Controlled Agentic Workflow.

ولو المشكلة تتحل بـDeterministic Software، استخدم Software عادية.

والتقنيات دي ممكن تتجمع مع بعض.

RAG بتحل إيه فعلًا؟

RAG اختصار Retrieval-Augmented Generation.

بدل ما تتوقع إن Model تحتوي كل المعرفة المطلوبة داخل Parameters، Application تعمل Retrieval للمعلومات المناسبة وقت الـRuntime وتديها للـModel كContext.

Flow مبسطة:

Question → Search/Retrieval → Relevant Evidence → LLM → Answer

تخيل موظف يسأل:

"إيه سياسة الـRefund الحالية لعملاء Enterprise؟"

الإجابة مكانها Company Documents، مش لازم تعيش بشكل دائم داخل Model.

RAG تقدر تجيب Current Policy وتخلي Model تجاوب من Evidence دي.

استخدم RAG لما المشكلة Knowledge

RAG تستحق الفحص لما المعلومات تكون:

• Private للشركة.
• بتتحدث باستمرار.
• أكبر من إنها تدخل في كل Prompt.
• موزعة بين Documents أو Systems.
• محتاج تربط الإجابة بمصدر.
• عليها Access Permissions.

Use Cases شائعة:

• Internal Knowledge Assistants.
• Customer Support مبني على Company Documentation.
• Product Documentation Assistants.
• Policy Search.
• Research Systems.
• Technical Knowledge Retrieval.

النقطة المهمة إن Model تسترجع Knowledge وقت التشغيل، مش بتتعلم Documents بشكل دائم من خلال RAG العادية.

RAG لا تجعل الإجابات صحيحة تلقائيًا

وضع Documents في Vector Database مش كفاية.

RAG System ممكن تفشل لأن:

• Documents غلط اتعمل لها Index.
• Chunking ضيعت Context مهم.
• Search رجعت Evidence غير مناسبة.
• Metadata مهمة ناقصة.
• Permission Filtering فشلت.
• Model تجاهلت Evidence أو فهمتها غلط.
• Source نفسها قديمة.

لذلك لازم تقيم Retrieval وGeneration بشكل منفصل.

Retrieval Question: هل System جابت Evidence الصح؟

Generation Question: هل Model استخدمت Evidence صح؟

RAG مش Permission System برضه

تخيل Finance وHR Documents في نفس Knowledge Store.

Retrieval مش المفروض تبحث في كل حاجة وتعتمد على Prompt إنها تخفي المعلومات غير المسموح بها.

Pattern أكثر أمانًا:

Identity → Permissions → Allowed Sources → Retrieval → Model

Authorization مكانها Application Architecture.

Fine-Tuning بتحل إيه فعلًا؟

Fine-Tuning تعدل Model بناءً على Training Examples بحيث Behaviors أو Patterns أو Task-specific Responses معينة تصبح أكثر طبيعية أو ثباتًا للـModel.

وده مختلف عن إنك تديها Documents تبحث فيها.

فكر في الفرق كده:

RAG: "دي المعلومات اللي محتاجها دلوقتي."

Fine-Tuning: "دي أمثلة للطريقة اللي المفروض تنفذ بيها المهمة."

التبسيط ده مش وصف كامل لكل Training Method، لكنه Mental Model مفيد للـBusiness.

استخدم Fine-Tuning لما المشكلة Behavior

Fine-Tuning قد تستحق Evaluation لما عندك Task متكررة وDataset قوية من Desired Examples.

مثلًا:

• Specialized Classification Behavior.
• Consistent Transformation من Format إلى Format.
• Domain-specific Response Patterns.
• Output Style متكررة والـPrompting لا تحافظ عليها بثبات.
• Task Behavior يمكن أن تسمح لـSmaller Specialized Model باستبدال General Model أغلى.

الكلمة المهمة هي Examples.

Fine-Tuning تحتاج Training وEvaluation Data مفيدة.

لو مش عارف تعرف Good Output شكلها إيه، Training غالبًا مش هتحل الغموض ده بدلًا منك.

ما تعملش Fine-Tuning لمجرد تعليم Model أحدث Documents

Company Knowledge بتتغير.

Prices بتتغير.

Policies بتتغير.

Products بتتغير.

لو Requirement الأساسية "جاوب بأحدث معلومات عندنا"، Retrieval غالبًا أول Architecture تستحق التجربة لأن Knowledge يمكن تحديثها مستقلًا عن Model Training.

Fine-Tuning قد تتجمع مع RAG لتحسين Behavior، لكن ما تتعاملش معها كDocument Database.

Fine-Tuning مش Magic Prompt Repair

قبل Training، اسأل Base System بتفشل ليه.

أسباب محتملة:

• Instructions غامضة.
• Examples ضعيفة في Prompt.
• Model غير مناسبة للTask.
• Retrieval سيئة.
• Validation ناقصة.
• Source Data غير متناسقة.
• Workflow نفسها لم يتم تعريفها بوضوح.

لو Task نفسها غير واضحة، Training على Examples أكثر ممكن تثبت الـInconsistency بدل ما تصلحها.

AI Agent بتحل إيه فعلًا؟

AI Agent تصبح Relevant لما System تحتاج تتجاوز Generate Answer وتتفاعل مع Tools أو Workflows.

مثلًا عميل يقول:

"انقل حجزي للخميس الجاي بعد الظهر."

Knowledge Assistant ممكن تشرح Booking Policy.

Agentic System قد تحتاج:

1. تحدد Customer.
2. تجيب Booking.
3. تفحص Available Dates.
4. تطبق Business Rules.
5. تطلب Confirmation.
6. تنادي Booking API.
7. تسجل Action.
8. ترجع Updated Status.

دي مش Knowledge Problem بشكل أساسي.

دي Controlled Action Problem.

Agent مش مجرد Chatbot بـPrompt أحسن

Architecture المهمة موجودة حول Model:

• Authentication.
• Tool Definitions.
• Authorization.
• Validation.
• State.
• Retries.
• Idempotency.
• Human Approval.
• Audit Logs.
• Monitoring.

LLM قد تقرر أو تقترح ماذا تفعل، لكن Business Systems تظل تفرض ما هو مسموح.

Prompt ليست Authorization Layer.

استخدم AI Agent لما المشكلة Action

Agents تستحق الفحص لما System تحتاج:

• Query أكثر من System بشكل Dynamic.
• تختار بين Tools.
• تنفذ Multi-step Tasks.
• تحدث Business Records.
• تشغل Workflows.
• تعمل Research وSynthesis قبل التنفيذ.
• تسأل عن Missing Information وتكمل بعدين.

لكن مش كل Automation تحتاج Agent.

لو Sequence ثابتة:

Form Submitted → Validate → Create CRM Record → Send Email

Workflow Automation عادية قد تكون أبسط وأرخص وأكثر Reliability.

استخدم Agentic Behavior لما Dynamic Interpretation أو Planning تضيف قيمة تكفي لتبرير Uncertainty الإضافية.

الاختيار الرابع: Software عادية

الاختيار ده بياخد اهتمام أقل لأنه مش Fashionable.

أحيانًا الحل الصحيح:

if invoice_total > approval_limit:
    require_manager_approval()

مش LLM تقرر هل Approval مطلوبة.

استخدم Deterministic Software لما:

• Rules واضحة.
• Calculations لازم تكون Exact.
• Permissions ثابتة.
• Validation معروفة.
• Workflow Transitions متوقعة.

AI تتعامل مع Uncertainty لما تضيف قيمة، مش تستبدل Certainty أنت عندك أصلًا.

تشخيص عملي

لما حد يقول "إحنا محتاجين AI"، أنا هقسم المشكلة لأربع أسئلة.

1. هل System ناقصها Information؟

مثال:

"مش قادرة تجاوب على أسئلة من Internal Documentation."

افحص RAG.

2. هل Model عندها المعلومات لكن تنفذ Task بشكل غير ثابت؟

مثال:

"عندنا آلاف Examples عالية الجودة لطريقة Classification المطلوبة، لكن Prompting مش Reliable كفاية."

افحص Fine-Tuning بعد إنشاء Baseline وEvaluation Set.

3. هل System محتاجة تعمل حاجة؟

مثال:

"بعد ما تفهم الطلب، لازم تنشئ Support Ticket وتحدث CRM."

افحص Tools أو Workflow Automation أو AI Agent.

4. هل Requirement أصلًا Rule واضحة؟

مثال:

"Orders فوق الرقم ده دائمًا تحتاج Manager Approval."

استخدم Normal Software.

RAG vs Fine-Tuning: مثال

تخيل شركة عندها 5,000 Support Articles وعايزة Assistant.

Articles بتتغير كل أسبوع.

لو المشكلة إن Model لا تعرف Latest Answers، RAG هي Architecture طبيعية للاختبار أولًا.

دلوقتي تخيل Assistant بتجيب Article الصح لكن باستمرار Format تعليمات Troubleshooting بشكل سيئ رغم Prompting جيدة وعندك Dataset كبيرة من Approved Examples.

Fine-Tuning قد تستحق Evaluation للBehavior دي.

الطريقتان تحلان Failure مختلفة.

RAG vs Agent: مثال

عميل يسأل:

"هل أقدر ألغي Subscription؟"

RAG تقدر تجيب Cancellation Policy وتشرحها.

لكن لو العميل قال:

"الغيها دلوقتي."

والـSystem مسموح لها تعمل Action، فأنت الآن محتاج Tool Integration وControlled Workflow.

RAG توفر Knowledge.

Agent أو Workflow تنفذ Action.

ويمكن استخدام الاثنين معًا.

Fine-Tuning vs Agent: مثال

تخيل AI System تحتاج Classify Incoming Request وبعدها Route لواحدة من Tools مختلفة.

Fine-Tuning قد تحسن Classification أو Tool-selection Behavior لو عندك Representative Examples كافية.

لكن Fine-Tuning نفسها لا تنشئ Business Integration.

ما زلت محتاج Tools وPermissions وAPIs وValidation وExecution Logic.

Training تغير Model.

Agent Architecture تربط Model بالعالم.

إمتى تحتاج الثلاثة مع بعض؟

تخيل Technical Support Agent.

قد تستخدم:

RAG لاسترجاع Current Product Documentation.

Fine-Tuning لتحسين Specialized Task أو Behavior لو Evaluation أثبتت إنها تستحق.

Agent Tools لفحص Customer Account أو إنشاء Ticket أو تشغيل Diagnostic Workflow.

وDeterministic Software لفرض Permissions وBusiness Rules.

Production Architecture ممكن تكون:

User → Auth → Agent → RAG → Model → Tool → Validation → Business API → Audit

مفيش تعارض بين التقنيات.

كل واحدة تعمل في Layer مختلفة.

والـMemory؟

Memory مفهوم آخر كثيرًا ما يختلط بنفس النقاش.

RAG تسترجع External Knowledge.

Conversation State تتبع Current Interaction.

Long-term Memory قد تحتفظ بمعلومات مفيدة من Interactions أو Events سابقة.

دي مسؤوليات مختلفة.

مثلًا Agent قد تحتاج تفتكر إن Customer يفضل English Responses في Conversations مستقبلية.

دي مش بالضرورة حاجة تعمل لها Fine-Tuning أو تحطها في Generic Company-document RAG Index.

Memory لازم يكون لها Data Model وPermissions وRetention وUpdate Strategy خاصة بها.

والـPrompts؟

Prompt Engineering غالبًا أرخص Layer للاختبار أولًا لما المشكلة Instruction Following.

قبل إدخال Training Infrastructure، اتأكد:

• Task متعرفة بوضوح.
• Required Context متاحة.
• Examples Representative.
• Output Schema واضحة.
• Validation موجودة عند الحاجة.

Prompting مش هتحل Missing Knowledge أو تنشئ APIs، لكنها قد تكشف هل Fine-Tuning مطلوبة فعلًا.

والـBigger Models؟

أحيانًا أبسط Fix هو استخدام Model أقوى.

قبل بناء Fine-Tuning Pipeline معقدة، قارن Economics:

• Stronger Hosted Model.
• Smaller Model + RAG.
• Fine-tuned Smaller Model.
• Local Model.
• Hybrid Routing.

قيّم Cost per Successful Business Task، مش Model Price منفصلًا.

Model أغلى تنجح بثبات قد تكون أرخص من Model رخيصة تعمل Retries وHuman Cleanup.

خطأ شائع: بناء RAG قبل التأكد إن Retrieval مطلوبة

لو المعلومات المطلوبة أصلًا موجودة في Small Structured Dataset أو API Lookup، Full Semantic Retrieval System قد تكون غير ضرورية.

مثلًا Check Order Status الأفضل غالبًا Query لـOrder System مباشرة.

ما تحطش Live Transactional Truth في Document Retrieval لو عندك Authoritative API.

استخدم RAG لنوع المعلومات اللي هي جيدة فيه.

خطأ شائع: استخدام Agent في Fixed Workflow

Multi-agent Architecture قد تبدو Sophisticated، لكن لو Process معروفة مسبقًا، Orchestration Code غالبًا تنفذها بشكل أكثر Predictability.

استخدم AI في Uncertain Step.

وخلي Deterministic Transitions deterministic.

مثلًا:

Incoming Email → AI Extracts Intent → Deterministic Validation → Workflow Engine → Human Approval if Required → API Action

جزء واحد فقط كان يحتاج Probabilistic Interpretation.

خطأ شائع: Fine-Tuning قبل Evaluation Set

لو مش قادر تقيس Base Model، مش هتقدر تثبت إن Fine-tuned Model اتحسنت.

قبل Training:

1. اجمع Representative Examples.
2. حدد Expected Outputs.
3. اعمل Baseline للBase Model.
4. صنف Failures.
5. قرر هل Training تعالج Failures دي.
6. اعمل Evaluation مرة ثانية بعد Training.

غير كده Fine-Tuning تتحول Experiment بدون Decision Framework.

خطأ شائع: التعامل مع Company Data كأنها نوع واحد

"درّبه على بياناتنا" قد تشمل:

• Policies.
• Customer Records.
• Product Catalog.
• Historical Conversations.
• Support Tickets.
• Analytics.
• Employee Preferences.

الأنواع دي لها Architecture Needs مختلفة.

Policies قد تكون RAG.

Customer Records مكانها APIs.

Historical Conversations قد تصبح Evaluation أو Fine-Tuning Dataset بعد Governance مناسبة.

User Preferences قد تكون Memory.

Analytics قد تكون Database Query أو Analytics Service.

صنف الـData قبل اختيار AI Technique.

Decision Table

المشكلة	أول Architecture تستحق الفحص
Current/Private Document Knowledge	RAG
Live Customer/Order/Account Data	API أو Database Tool
Repeatable Learned Behavior	Fine-Tuning
Dynamic Actions عبر Tools	AI Agent / Agentic Workflow
Fixed Multi-step Automation	Workflow Automation
Exact Rule أو Calculation	Deterministic Software
Information عبر Conversations	Memory/State Architecture

استخدام كلمة "أول" مقصود.

Real Systems لازم تتقيم على Requirements الفعلية.

Architecture Workshop أفضل

بدل ما Meeting تبدأ بـ:

"نستخدم RAG ولا Fine-Tuning؟"

حط Real Business Task واحدة على السبورة.

مثلًا:

"لما Customer يطلب تغيير Booking، System تفهم الطلب، تراجع Policy، تشوف Availability، تؤكد التغيير، تحدث Booking وتسجل اللي حصل."

بعدها فككها:

Understand Request → LLM قد تساعد.

Check Policy → RAG قد تساعد.

Inspect Availability → Booking API.

Apply Rules → Deterministic Software.

Confirm Risky Action → Human/User Approval.

Update Booking → Controlled Tool/API.

Remember Conversation State → State/Memory.

Architecture تبدأ تبان لأن المشكلة اتفككت الأول.

إزاي تتجنب Over-engineering؟

استخدم Minimum Complexity التي تنجح في Evaluation.

ابدأ بـ:

1. Existing Software وAPIs.
2. Clear Deterministic Rules.
3. Prompting مع Capable Model.
4. Retrieval لو Knowledge ناقصة.
5. Tools لو Actions مطلوبة.
6. Fine-Tuning لما Measured Behavior تبرر Training.
7. More Complex Agent Orchestration فقط لما Workflow فعلًا تحتاجها.

ده مش Universal Sequence جامدة، لكنه Bias مفيد تجاه Simpler Systems.

كل Layer إضافية تخلق شيء آخر محتاج تشغيل وEvaluation وDebugging.

الـArchitecture لازم تتبع Failure Mode

دي الفكرة الأساسية.

لو Model ناقصها Knowledge، ادّيها Knowledge الصح.

لو Learned Behavior هي المشكلة، قيّم هل Training تحسنها.

لو System محتاجة تنفذ، اربطها بـControlled Tools.

لو Rule معروفة، اكتب الـRule.

لو محتاجة Continuity، صمم State وMemory.

ما تستخدمش Technique واحدة Fashionable لحل كل أنواع المشاكل.

بتخطط AI System ومش عارف محتاج أنهي Architecture؟

هات Workflow حقيقية وكام Representative Example.

نقدر نفصل Knowledge وBehavior وActions وDeterministic Rules وMemory، وبعدها نختار أصغر Architecture تحقق Requirement.

ناقش AI Architecture مع فادى مندي.

أصمم Production AI Systems حول Failure Mode الحقيقية — تشمل RAG وAI Agents وModel Evaluation وPrivate AI والـIntegrations وFine-Tuning عندما Evidence تثبت إنها مفيدة.

---

مرتبط: AI Agents، Private AI، Local LLM vs Hosted AI، AI Integration، AI Consulting، AI for Business وCustom AI Development.