البصمة التشفيرية للبيانات في مسارات معالجة RAG: دليل تقني

نظام RAG بلا تحقق من السلامة بيتٌ من ورق

صُمِّمت بنى التوليد المعزَّز بالاسترجاع (Retrieval-Augmented Generation، RAG) لحل مشكلة محددة: فالنماذج اللغوية لها تاريخ توقف لبيانات تدريبها، بينما المعرفة المؤسسية ديناميكية. ومن خلال استرجاع المستندات ذات الصلة لحظة الاستدلال، تستطيع أنظمة RAG تقديم إجابات محدَّثة وخاصة بالمجال دون إعادة تدريب مكلفة.

البنية تعمل. غير أن نموذج الثقة الذي تفترضه نادرًا ما يصمد.

تسترجع معظم تطبيقات RAG في المؤسسات المستندات من مستودعات تفتقر إلى أي طبقة للتحقق من السلامة. ويفترض النموذج أن المستندات المسترجَعة دقيقة وغير معدَّلة وصادرة عن المصادر التي تدّعي أنها صادرة عنها. أما في الواقع، فلا توجد في معظم تطبيقات RAG أي آلية للتحقق من أيٍّ من هذه الافتراضات.

تعالج البصمة التشفيرية للبيانات هذه المشكلة مباشرة. فمن خلال تثبيت قيمة تجزئة (hash) لكل مستند لحظة إدخاله والتحقق منها لحظة استرجاعه، تستطيع المؤسسات بناء مسارات معالجة RAG يرافق فيها كلَّ مستندٍ مسترجَع دليلٌ رياضي على سلامته.

كيف تعمل البصمة التشفيرية

الآلية بسيطة من حيث المفهوم:

1. عند الإدخال: عندما يدخل مستند إلى مجموعة مستندات RAG، احسب قيمة التجزئة SHA-256 الخاصة به (أو ما يعادلها). ثبّت هذه القيمة، مع طابع زمني وبيانات وصفية عن المصدر، في سجل مستقل مقاوم للتلاعب.

2. عند الاسترجاع: قبل تمرير المستند المسترجَع إلى سياق النموذج، أعد حساب قيمة التجزئة الخاصة به. وقارنها بالقيمة المثبَّتة في السجل.

3. عند عدم التطابق: إذا اختلفت قيمتا التجزئة، فهذا يعني أن المستند قد عُدِّل منذ إدخاله. وينبغي لنظام RAG أن يرفض المستند وينبّه فريق الأمن بدلًا من تمرير محتوى يُحتمل أنه مخترَق إلى النموذج.

4. المراقبة المستمرة: إلى جانب الفحص عند كل استرجاع، ينبغي لطبقة السلامة أن تراقب مجموعة المستندات باستمرار - لاكتشاف التعديلات على مستندات لم تُسترجَع مؤخرًا لكنها قد تكون مهيَّأة مسبقًا لهجمات مستقبلية.

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

import { createHash } from 'crypto';

interface VerifiedDocument {
  content: string;
  hash: string;
  anchoredAt: string;
  source: string;
}

async function verifyDocumentIntegrity(
  document: VerifiedDocument,
  ledger: IntegrityLedger
): Promise<{ verified: boolean; reason?: string }> {
  // Recompute hash from current document content
  const currentHash = createHash('sha256')
    .update(document.content)
    .digest('hex');

  // Retrieve the anchored hash from the immutable ledger
  const anchoredRecord = await ledger.getRecord(document.source);

  if (!anchoredRecord) {
    return { verified: false, reason: 'No integrity record found for document' };
  }

  if (currentHash !== anchoredRecord.hash) {
    return {
      verified: false,
      reason: `Hash mismatch: document modified since ${anchoredRecord.anchoredAt}`
    };
  }

  return { verified: true };
}

// Usage in RAG retrieval pipeline
async function retrieveVerifiedDocuments(
  query: string,
  vectorStore: VectorStore,
  ledger: IntegrityLedger
): Promise<VerifiedDocument[]> {
  const candidates = await vectorStore.similaritySearch(query, 10);

  const verified = await Promise.all(
    candidates.map(async (doc) => {
      const result = await verifyDocumentIntegrity(doc, ledger);
      return { doc, ...result };
    })
  );

  // Filter to only integrity-verified documents
  const safe = verified.filter(v => v.verified).map(v => v.doc);

  if (safe.length < candidates.length) {
    console.warn(`${candidates.length - safe.length} documents failed integrity check`);
    // Alert security team
  }

  return safe;
}

التكامل مع منظومات RAG القائمة

تقع طبقة التحقق من السلامة بين مخزن المتجهات لديك وسياق النموذج اللغوي. ولا تتطلب استبدال بنية RAG التحتية القائمة لديك - بل تعززها.

أنماط التكامل الشائعة:

LangChain / LlamaIndex: غلّف أداة الاسترجاع (retriever) بخطوة تحقق قبل أن تصل المستندات إلى السلسلة (chain) أو محرك الاستعلام (query engine). ويوضح مثال الشيفرة أعلاه هذا النمط - إذ تحل retrieveVerifiedDocuments محل الاستدعاء المباشر لـ vectorStore.similaritySearch.

مسارات معالجة الاسترجاع المخصصة: تقتصر مقارنة قيم التجزئة على استدعاءين لواجهة API (البحث في السجل + حساب قيمة التجزئة)، ويمكن إضافتهما إلى أي دالة استرجاع.

قواعد بيانات المستندات المضمَّنة (ChromaDB، Weaviate، Qdrant): خزّن قيمة التجزئة المثبَّتة ضمن البيانات الوصفية للمستند لحظة إدخاله. تقرأ خطوة التحقق هذه البيانات الوصفية وتقارنها بقيمة التجزئة المحسوبة. ولضمان مقاومة التلاعب، ينبغي أن يكون القيد المرجعي لقيمة التجزئة في سجل خارجي، لا مخزَّنًا في النظام نفسه الذي يضم المستند.

يشرح دليل التكامل مع واجهات API من ROOTKey كيفية ربط استدعاءات التثبيت في السجل والتحقق بمسار المعالجة القائم لديك. وتوفر منصة ROOTKey سجل السلامة كخدمة مُدارة. ابدأ البناء اليوم مع الباقة المجانية.

• دقّق في مسار معالجة RAG الحالي لديك: في أي مرحلة (إن وُجدت) يجري التحقق من سلامة المستندات المسترجَعة؟
• طبّق تثبيت قيم التجزئة عند إدخال المستندات - فهذه هي طبقة السلامة الدنيا القابلة للتطبيق.
• أضف التحقق من قيم التجزئة لحظة الاسترجاع، قبل أن تدخل المستندات سياق النموذج.
• في التطبيقات عالية المخاطر (القانونية، والمتعلقة بالامتثال، والطبية)، طبّق مراقبة مستمرة لمجموعة المستندات، لا الفحص عند كل استرجاع فحسب.
• اختبر طبقة السلامة لديك بتعديل مستند عمدًا في مجموعة مستندات الاختبار، والتحقق من اكتشاف التعديل قبل الاسترجاع.