تزويد الذكاء الاصطناعي بالأدوات (Tools): كيف نعلمه البحث في جوجل للتحقق من الأخبار؟

لماذا يحتاج LLM إلى أدوات خارجية للتحقق من الأخبار؟

النموذج اللغوي الكبير قوي جداً في الفهم، التلخيص، إعادة الصياغة، وربط الأنماط، لكنه ليس محرك بحث حياً بطبيعته. أي LLM يعمل فوق بيانات تدريب سابقة، ولذلك قد يفشل عند سؤال حساس زمنياً مثل: هل هذا الخبر العاجل صحيح؟ هنا تظهر مشكلة الهلوسة ومشكلة تقادم المعرفة. ولهذا السبب نزوّد النموذج بأداة خارجية مثل Google Search أو واجهة بحث بديلة حتى ينتقل من “التخمين اللغوي” إلى “التحقق القائم على مصادر”.

هذه الفكرة تقع ضمن عالم العملاء الأذكياء AI Agents، حيث لا يكتفي النظام بتوليد نص، بل يقرر: هل أجيب مباشرة؟ أم أستدعي أداة؟ أم أطلب بيانات إضافية؟ وهي أيضاً امتداد طبيعي لما تعلمناه في كيفية عمل نماذج اللغة الكبيرة برمجياً، لأن النموذج وحده ليس قاعدة حقائق آنية.

الفكرة الهندسية: من سؤال المستخدم إلى خبر موثّق

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

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

هذا التدفق قريب مفاهيمياً من نظام RAG، لكن الفرق أن المصدر هنا ليس قاعدة داخلية فقط، بل الويب المفتوح عبر أداة بحث. لذلك يمكن اعتباره نوعاً من Tool-Augmented Generation حيث يجمع النموذج بين التفكير النصي والاستدعاء الخارجي.

المكوّنات الأساسية في المعمارية

• طبقة الإدخال: تستقبل ادعاء المستخدم وتطبّع النص.
• طبقة اتخاذ القرار: تقرر إن كان السؤال يحتاج أداة بحث.
• طبقة الأداة: تنفذ استدعاء البحث عبر API.
• طبقة التحليل: تقارن بين صياغة الخبر والنتائج المسترجعة.
• طبقة الإخراج: تنتج استجابة حذرة مع تبرير وروابط.

كيف نعلّم النموذج متى يستخدم الأداة؟

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

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

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

بناء أداة بحث بسيطة في Python

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

import os
import requests

SERPAPI_KEY = os.getenv("SERPAPI_KEY")

def google_search_news(query: str, num_results: int = 5):
    url = "https://serpapi.com/search.json"
    params = {
        "engine": "google",
        "q": query,
        "api_key": SERPAPI_KEY,
        "num": num_results,
        "hl": "en"
    }

    response = requests.get(url, params=params, timeout=20)
    response.raise_for_status()
    data = response.json()

    results = []
    for item in data.get("organic_results", [])[:num_results]:
        results.append({
            "title": item.get("title", ""),
            "link": item.get("link", ""),
            "snippet": item.get("snippet", "")
        })
    return results

هذه الدالة لا “تتحقق” وحدها؛ هي فقط تسترجع أدلة أولية. التحقق الحقيقي يحصل عندما نمرر النتائج إلى النموذج ضمن قالب تحليل منضبط.

دمج الأداة مع LangChain كأداة رسمية

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

from langchain.tools import tool

@tool
def verify_news_with_search(claim: str) -> str:
    """
    Search the web for recent evidence related to a news claim.
    Returns summarized search results as plain text.
    """
    results = google_search_news(claim, num_results=5)

    if not results:
        return "No search results found."

    lines = []
    for idx, item in enumerate(results, start=1):
        lines.append(
            f"{idx}. Title: {item['title']}\n"
            f"Link: {item['link']}\n"
            f"Snippet: {item['snippet']}\n"
        )

    return "\n".join(lines)

هنا أصبحت الأداة مفهومة للوكيل على أنها وظيفة قابلة للاستدعاء. وعند بناء التطبيق، يمكن للوكيل أن يقرر استخدامها عندما يتعرف على نمط “تحقق من خبر”.

تحويل النتائج إلى حكم منظم بصيغة JSON

للاستخدام الإنتاجي، لا نريد إجابات إنشائية فقط؛ نريد مخرجات قابلة للبرمجة. لذلك من الأفضل إجبار النموذج على الرد بصيغة منظمة كما شرحنا في Output Parsers.

حلّل الادعاء اعتماداً على نتائج البحث فقط. أعد النتيجة بصيغة JSON تحتوي على المفاتيح التالية: claim, verdict, confidence, reasoning, sources. لا تضف أي نص خارج JSON. إذا كانت الأدلة متضاربة فليكن verdict = “inconclusive”.

import json
from openai import OpenAI

client = OpenAI()

def analyze_claim(claim: str, search_results: list):
    prompt = f"""
Claim: {claim}

Search Results:
{json.dumps(search_results, ensure_ascii=False, indent=2)}

Return JSON only with keys:
claim, verdict, confidence, reasoning, sources
"""

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        temperature=0,
        messages=[
            {"role": "system", "content": "You are a cautious fact-checking assistant."},
            {"role": "user", "content": prompt}
        ]
    )

    return response.choices[0].message.content

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

أفضل ممارسة: لا تثق في عنوان واحد فقط

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

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

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

توسيع النظام: الجمع بين البحث وEmbeddings

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

• استدعاء بحث ويب للأحداث الحديثة.
• استدعاء بحث دلالي داخلي في الأرشيف.
• دمج النتائج الخارجية والداخلية.
• توليد حكم أكثر استقراراً وأقل عرضة للتضليل.

وهذا فعلياً نموذج هجين بين الأدوات الحية ودمج السياق المسترجع مع النموذج.

اعتبارات موثوقية، تكلفة، وسياسة محتوى

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

قواعد عملية قبل النشر الإنتاجي

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

الخلاصة الهندسية

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