مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

صفر سے Adaptive-RAG ای کامرس کسٹمر سروس بنائیں: موافقانہ بازیافت، ارادے کی شناخت اور آرڈر ٹولز کا عملی تجربہ

یہ ٹیوٹوریل آپ کو مقامی ماحول میں Adaptive-RAG ای کامرس کسٹمر سروس چلانے، متحرک بازیافت، متعدد مراحل میں شواہد کی تکمیل، وفاداری کی جانچ، Jev اور DeepSeek کے ذریعے ارادے کی شناخت سمجھنے، اور پالیسی سوال و جواب، آرڈر کی تلاش، انسانی تصدیق، ٹیسٹ و جائزہ اور Docker تعیناتی آزمانے میں رہنمائی کرے گا۔

تقریباً 32 منٹ کا مطالعہ
Adaptive-RAG ای کامرس کسٹمر سروس: بازیافت، ارادے کی شناخت اور آرڈر ٹولز

پروجیکٹ کا تعارف

Adaptive-RAG ای کامرس کسٹمر سروس ایک ذہین کسٹمر سروس پروجیکٹ ہے جو متعدد شرائط پر مشتمل پالیسی سے متعلق سوالات کے لیے بنایا گیا ہے۔ اس کا بنیادی مقصد ناکافی شواہد، بے بنیاد جوابات اور ایسے پیچیدہ سوالات کے مسائل حل کرنا ہے جنہیں ایک ہی بار کی تلاش سے مکمل طور پر حل نہیں کیا جا سکتا۔ بیک اینڈ FastAPI اور LangGraph سے چلتا ہے، جبکہ فرنٹ اینڈ React استعمال کرتا ہے۔ نظام صارف کی نیت اور سوال کی پیچیدگی کے مطابق براہ راست جواب، علمی تلاش، اضافی تلاش، ٹول کے اجرا، انسانی تصدیق اور جواب دینے سے انکار کے درمیان متحرک طور پر راستہ منتخب کر سکتا ہے۔

یہ پروجیکٹ مقامی ڈیمو، Adaptive RAG ورک فلو سیکھنے اور انجینئرنگ کی توثیق کے لیے موزوں ہے۔ یہ پالیسی ذرائع کے حوالے، ڈیمو آرڈر کی تلاش، زیرِ تصدیق کارروائیوں، سیشن کی یادداشت اور SSE رسپانس کو سپورٹ کرتا ہے، لیکن آرڈر اور لاجسٹکس کا ڈیٹا حقیقی کاروباری ڈیٹا نہیں ہے۔

موجودہ API کلائنٹ کی جانب سے بھیجے گئے user_id کو براہ راست قبول کرتی ہے اور ابھی تک اس کی حقیقی شناخت کی تصدیق نہیں کرتی۔ قابلِ اعتماد شناختی تصدیق، TLS اور رسائی کنٹرول شامل کیے بغیر اس پروجیکٹ کو براہ راست عوامی نیٹ ورک پر تعینات نہ کریں۔

نظام ایک درخواست کو کیسے پراسیس کرتا ہے

صارف Web صفحے یا HTTP API کے ذریعے سوال بھیجنے کے بعد درخواست ان پٹ گارڈ، نیت کی شناخت اور پیچیدگی کی روٹنگ سے گزرتی ہے۔ اس کے بعد نظام مناسب پراسیسنگ شاخ منتخب کرتا ہے اور آخر میں جواب تیار کرتا ہے، وفاداری کی جانچ کرتا ہے، سیشن کی یادداشت اپ ڈیٹ کرتا ہے اور حوالے واپس بھیجتا ہے۔

صارف → Web / HTTP API → ان پٹ گارڈ
     → نیت کی شناخت → پیچیدگی کی روٹنگ
       ├─ براہ راست جواب
       ├─ تلاش → دوبارہ درجہ بندی → ضرورت پڑنے پر اضافی تلاش
       ├─ منصوبہ بندی → ٹول کا اجرا / انسانی تصدیق
       └─ جواب دینے سے انکار
     → تیاری اور وفاداری کی جانچ → سیشن کی یادداشت → جواب اور حوالے

نیت کی شناخت کے لیے پہلے سے طے شدہ DeepSeek استعمال کیا جا سکتا ہے، یا اسے TypeSafe Jev پر تبدیل کیا جا سکتا ہے۔ یاد رہے کہ Jev صرف نیت کی درجہ بندی کے نوڈ کو تبدیل کرتا ہے؛ پیچیدگی کا تعین، سوال کی تدوین، کام کی منصوبہ بندی، جواب کی تیاری، وفاداری کی جانچ اور یادداشت کے خلاصے جیسے دیگر LLM نوڈز اب بھی DeepSeek کے زیرِ انتظام ہیں۔

بنیادی صلاحیتیں

  • مطابقت پذیر روٹنگ: کاروباری نیت اور سوال کی پیچیدگی کو ملا کر براہ راست جواب، ایک مرحلے کی تلاش، متعدد مراحل کی تلاش، ٹول کا اجرا یا جواب دینے سے انکار منتخب کرتی ہے۔
  • مخلوط تلاش: BM25 اور گھنے ویکٹر کی بازیافت کو یکجا کرتی ہے، نتائج کو RRF سے ملاتی ہے اور Cross-Encoder کی دوبارہ درجہ بندی فعال کی جا سکتی ہے۔
  • شواہد میں اضافہ: سوال کی تدوین، ناکافی شواہد کی صورت میں اضافی تلاش، جواب کی وفاداری کی جانچ اور خودکار اصلاح کو سپورٹ کرتی ہے۔
  • دوہرا نیت بیک اینڈ: پہلے سے طے شدہ طور پر DeepSeek استعمال کرتا ہے، جبکہ Jev کے ساختی choice انٹرفیس کے ذریعے پہلے سے متعین 14 کاروباری نیتوں کی شناخت بھی کی جا سکتی ہے۔
  • دستاویز پراسیسنگ: Markdown کو براہ راست سپورٹ کرتا ہے؛ اختیاری انحصارات اور سسٹم ٹولز انسٹال کرنے کے بعد PDF، Office اور OCR دستاویزات بھی پارس کی جا سکتی ہیں۔
  • ساختی حصوں میں تقسیم: عام متن کے لیے پہلے سے طے شدہ طور پر 500 حروف کی ونڈو اور 60 حروف کا اوورلیپ استعمال ہوتا ہے؛ شناخت شدہ جدول الگ حصہ بنتے ہیں اور عنوان، باب اور ماخذ جیسے میٹا ڈیٹا محفوظ رکھتے ہیں۔
  • کاروباری ٹولز: آرڈر سے متعلق ڈیمو ٹولز فراہم کرتا ہے، جن میں اجازت کی جانچ، متبادل طریقہ، انسانی تصدیق اور idempotency میکانزم شامل ہیں؛ MCP ٹولز سے بھی منسلک کیا جا سکتا ہے۔
  • انجینئرنگ کی صلاحیتیں: سیشن کی یادداشت کا اختصار، ساختی لاگز، Prometheus میٹرکس، صحت کی جانچ اور خودکار ٹیسٹنگ شامل ہیں۔

رن ٹائم ماحول تیار کریں

بنیادی تقاضے

  • Python 3.11 یا اس سے نیا ورژن۔
  • Web فرنٹ اینڈ چلانے کے لیے Node.js 20.19+ یا 22.12+ اور npm درکار ہے۔
  • پہلے سے طے شدہ مقامی موڈ SQLite اور میموری پر مبنی تلاش کے اجزا استعمال کرتا ہے، اس لیے Docker کو پہلے سے شروع کرنا ضروری نہیں۔

Windows PowerShell انسٹالیشن کے مراحل

ریپوزٹری کلون کر کے پروجیکٹ کی بنیادی ڈائریکٹری میں جانے کے بعد ورچوئل ماحول بنائیں، ڈویلپمنٹ انحصارات انسٹال کریں، کنفیگریشن فائل نقل کریں اور ڈیمو ڈیٹا تیار کریں:

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"
Copy-Item .env.example .env
.\.venv\Scripts\python.exe -m scripts.seed_demo

اگر پروجیکٹ کی بنیادی ڈائریکٹری میں پہلے ہی .env موجود ہو تو اصل فائل برقرار رکھیں اور نقل کرنے والی کمانڈ چھوڑ دیں۔ اس کے بعد FastAPI شروع کریں:

.\.venv\Scripts\python.exe -m uvicorn app.asgi:app --reload --host 127.0.0.1 --port 8000

macOS اور Linux

macOS یا Linux پر ورچوئل ماحول بنائیں اور فعال کریں، پھر متعلقہ انسٹالیشن کمانڈز چلائیں:

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env
python -m scripts.seed_demo
python -m uvicorn app.asgi:app --reload --host 127.0.0.1 --port 8000

ماڈل اور مقامی سروسز کی کنفیگریشن

پروجیکٹ کی بنیادی ڈائریکٹری میں موجود .env کھولیں۔ درج ذیل کنفیگریشن کو ترجیحی طور پر چیک کریں:

  • DEEPSEEK_API_KEY: DeepSeek ورک فلو اور پہلے سے طے شدہ نیت کی درجہ بندی فعال کرتا ہے۔ حقیقی API کالز پر لاگت آ سکتی ہے۔
  • INTENT_BACKEND: پہلے سے طے شدہ deepseek یا اختیاری jev مقرر کیا جا سکتا ہے۔
  • JEV_API_KEY: Jev نیت کی درجہ بندی فعال کرتے وقت درکار ہے۔
  • JEV_MODEL: پروجیکٹ کی موجودہ پہلے سے طے شدہ قدر jev-1.13.0 ہے۔
  • DATABASE_URL: پہلے سے طے شدہ طور پر sqlite+aiosqlite:///./data/local/app.db استعمال ہوتا ہے۔
  • KNOWLEDGE_DIR: پہلے سے طے شدہ قدر knowledge ہے، اس میں موجود علمی دستاویزات آغاز کے وقت ڈیٹا بیس میں شامل کی جاتی ہیں۔
  • LOCAL_EMBEDDING_ENABLED: مقامی معنوی ویکٹر کی سہولت کو کنٹرول کرتا ہے۔
  • CROSS_ENCODER_ENABLED: مقامی دوبارہ درجہ بندی کی سہولت کو کنٹرول کرتا ہے۔
  • REDIS_URL اور QDRANT_URL: اختیاری بیرونی کیش اور ویکٹر سروسز کی کنفیگریشن کے لیے ہیں۔

اگر DeepSeek کی کلید کنفیگر نہ کی جائے تو نظام آف لائن ڈیمو منطق کے ساتھ پھر بھی چل سکتا ہے، لیکن اس کے جوابات کا معیار حقیقی ماڈل موڈ سے مختلف ہوگا۔ تمام متغیرات کنفیگریشن حوالہ اور مثالی ماحول فائل میں دیکھے جا سکتے ہیں۔

React چیٹ انٹرفیس شروع کریں

بیک اینڈ کا عمل چلتا رہنے دیں اور دوسرے ٹرمینل میں فرنٹ اینڈ کی ڈائریکٹری میں جائیں:

cd frontend
npm ci
npm run dev

http://127.0.0.1:5173 کھول کر چیٹ صفحہ دیکھا جا سکتا ہے۔ ڈویلپمنٹ سرور /api کی درخواستوں کو مقامی 8000 پورٹ پر بھیج دے گا۔

فرنٹ اینڈ ماخذ کے حوالے، مقامی سیشن فہرست اور کارروائی کی تصدیقی کارڈز کو سپورٹ کرتا ہے۔ جواب کی جانچ مکمل ہونے کے بعد بیک اینڈ SSE کے ذریعے مواد کو حصوں میں بھیجتا ہے۔ اگر npm run build چلا کر frontend/dist تیار کیا جائے تو FastAPI اس ڈائریکٹری کا پتا چلنے پر بنیادی راستے سے فرنٹ اینڈ صفحہ فراہم کرے گا۔

بنیادی استعمال: واپسی اور تبادلے کی پالیسی سے متعلق سوال

سب سے پہلے سروس کی حالت کی تصدیق کریں:

اب PowerShell کے ذریعے چیٹ انٹرفیس پر متعدد پالیسی شرائط والا سوال بھیجیں:

$payload = @{
    message = "定制马克杯过了七天，但是有质量问题，可以退吗？"
    user_id = "u_demo"
} | ConvertTo-Json

Invoke-RestMethod `
    -Uri "http://127.0.0.1:8000/api/v1/chat" `
    -Method Post `
    -ContentType "application/json; charset=utf-8" `
    -Body ([System.Text.Encoding]::UTF8.GetBytes($payload))

نظام پہلے واپسی اور تبادلے سے متعلق نیت کی شناخت کرے گا، پھر سوال کی پیچیدگی کے مطابق فیصلہ کرے گا کہ پالیسی دستاویزات تلاش کی جائیں یا نہیں۔ اگر ابتدائی شواہد ناکافی ہوں تو ورک فلو سوال کو دوبارہ لکھ کر اضافی تلاش کر سکتا ہے؛ جواب تیار کرنے کے بعد یہ بھی جانچا جائے گا کہ جواب تلاش شدہ شواہد سے وفادار ہے یا نہیں، اور دستیاب ماخذ حوالے واپس کیے جائیں گے۔

HTTP API کے علاوہ، بیک اینڈ چلنے کے دوران درج ذیل کمانڈ چلا کر ٹرمینل کلائنٹ بھی استعمال کیا جا سکتا ہے:

python -m app.cli

بنیادی استعمال: ڈیمو آرڈر کی تلاش اور کارروائیاں

scripts.seed_demo ڈیمو آرڈر واضح طور پر بناتا ہے۔ API کا آغاز خود بخود یہ ڈیٹا نہیں لکھتا، اس لیے پہلی بار چلانے پر ڈیٹا کی ابتدا کو نہ چھوڑیں۔ ڈیمو صارف u_demo ہے، دستیاب آرڈرز یہ ہیں:

  • ORD10001: بھیج دیا گیا ہے، مصنوعات شور کم کرنے والے ہیڈ فون ہیں۔
  • ORD10002: وصول کر لیا گیا ہے، مصنوعات حسبِ ضرورت بنایا گیا مگ ہے۔
  • ORD10003: ادائیگی ہو چکی ہے مگر بھیجا نہیں گیا، مصنوعات ٹی شرٹ ہے۔

مثلاً چیٹ صفحے میں 取消订单 ORD10003 درج کریں۔ ایسی کارروائی انجام دیتے وقت جس کے لیے تصدیق درکار ہو، نظام pending_action واپس کر سکتا ہے۔ تصدیقی درخواست میں رسپانس کا session_id واپس بھیجنا ضروری ہے، اور pending_action.action_id کو confirm_action_id میں رکھنا ہوگا۔ Web صفحہ تصدیقی کارڈ کے ذریعے اس عمل کو مکمل کرنے میں مدد دے گا۔

زیرِ تصدیق کارروائیاں پہلے سے طے شدہ طور پر سرور کے عمل میں 15 منٹ تک محفوظ رہتی ہیں۔ سروس دوبارہ شروع ہونے یا درخواست کسی دوسرے عمل میں منتقل ہونے کے بعد کارروائی دوبارہ شروع کرنا پڑ سکتی ہے۔ مخصوص فیلڈز اور انٹرفیس فارمیٹ کے لیے API حوالہ دیکھیں۔

اعلیٰ درجے کی کنفیگریشن: Jev نیت کی شناخت فعال کریں

نیت کی درجہ بندی کے نوڈ کو TypeSafe Jev پر منتقل کرنے کے لیے مقامی .env میں درج ذیل کنفیگریشن شامل یا تبدیل کریں:

INTENT_BACKEND=jev
JEV_API_KEY=your_jev_api_key
JEV_ENDPOINT=https://api.typesafe.ai/v1/systemone
JEV_MODEL=jev-1.13.0
JEV_TIMEOUT_SECONDS=10
JEV_MAX_RETRIES=2
JEV_INTENT_APPLY_OVERLAY=true

DEEPSEEK_API_KEY=your_deepseek_api_key

محفوظ کرنے کے بعد بیک اینڈ دوبارہ شروع کریں۔ Jev HTTP انٹرفیس کے ذریعے منسلک ہوتا ہے، اس لیے مخصوص SDK انسٹال کرنے کی ضرورت نہیں۔ واپس آنے والے نتائج Pydantic سے جانچے جاتے ہیں، پھر یکساں درجہ بندی کے نتائج میں تبدیل کیے جاتے ہیں۔

جب Jev کی کلید غائب ہو، درخواست ناکام ہو یا رسپانس غیر قانونی ہو، تو نظام پہلے سے موجود IntentClassifier پر واپس آ جاتا ہے۔ واپسی کا راستہ پہلے کنفیگر شدہ DeepSeek استعمال کرتا ہے؛ آف لائن ہونے یا ماڈل کال ناکام ہونے کی صورت میں اصولی درجہ بندی جاری رہتی ہے۔ دوبارہ کوشش کے قابل غلطیوں کے لیے ایکسپونینشل بیک آف استعمال ہوتا ہے، اور موجودہ نفاذ میں JEV_MAX_RETRIES زیادہ سے زیادہ کوششوں کی تعداد ظاہر کرتا ہے۔

JEV_INTENT_APPLY_OVERLAY Jev کی کامیاب درجہ بندی کے بعد اصولی اصلاح کو کنٹرول کرتا ہے اور پہلے سے طے شدہ طور پر فعال ہے۔ یہ اختیار واپسی والے درجہ بندی کنندہ کی اپنی اوورلے کو کنٹرول نہیں کرتا۔ پہلے سے طے شدہ نیت کی درجہ بندی بحال کرنے کے لیے INTENT_BACKEND کو واپس deepseek پر مقرر کریں۔

اعلیٰ درجے کی ترتیب: بہتر تلاش اور دستاویزات کی تجزیہ کاری

مقامی ویکٹر اور ری رینکنگ کی ضروریات انسٹال کریں

.\.venv\Scripts\python.exe -m pip install -e ".[rerank]"

rerank کی ضروریات مقامی dense vector ماڈل اور Cross-Encoder کے لیے استعمال ہوتی ہیں۔ پہلے سے طے شدہ ویکٹر ماڈل BAAI/bge-small-zh-v1.5 ہے، جبکہ پہلے سے طے شدہ ری رینکنگ ماڈل BAAI/bge-reranker-base ہے۔ پہلی بار لوڈ کرتے وقت ماڈل کے وزن ڈاؤن لوڈ ہو سکتے ہیں؛ ماڈل دستیاب نہ ہونے کی صورت میں نظام fallback استعمال کرے گا، اس لیے نتائج مکمل ماڈل کی ترتیب کے برابر نہیں ہوں گے۔

توسیعی دستاویز تجزیہ کاری کی ضروریات انسٹال کریں

.\.venv\Scripts\python.exe -m pip install -e ".[docs]"

docs کی ضروریات Unstructured دستاویز تجزیہ کاری کے لیے استعمال ہوتی ہیں۔ PDF، OCR اور Office فائلوں پر کارروائی کرتے وقت Poppler، Tesseract اور چینی زبان کا پیکیج، نیز LibreOffice بھی انسٹال کرنا پڑ سکتا ہے۔ تفصیلی تقاضوں کے لیے تجزیہ کاری اور تلاش کی وضاحت دیکھیں۔

علمی حصوں کی IDs دستاویز کے راستے اور حصے کے نمبر کی بنیاد پر تیار ہوتی ہیں۔ جب راستہ اور تقسیم کے نتائج تبدیل نہ ہوں تو دوبارہ اندراج سے ID یکساں رہ سکتی ہے؛ فائل منتقل ہونے، مواد میں ترمیم یا حصے بنانے کی حکمتِ عملی تبدیل ہونے کے بعد تاریخی حوالوں کے اسی مواد کی طرف اشارہ کرتے رہنے کی ضمانت نہیں ہے۔

Docker کے ذریعے مکمل سروس شروع کریں

اگر آپ API، PostgreSQL، Redis، Qdrant اور build شدہ Web فرنٹ اینڈ کو بیک وقت چلانا چاہتے ہیں تو پہلے مقامی .env تیار کریں، پھر چلائیں:

docker compose up --build

شروع ہونے کے بعد http://127.0.0.1:8000 کھولیں۔ Compose میں موجود ڈیٹابیس پاس ورڈ اور پورٹ میپنگ صرف مقامی مظاہرے کے لیے ہیں۔ عوامی تعیناتی سے پہلے مظاہرے کا پاس ورڈ لازماً تبدیل کریں، ڈیٹابیس اور cache پورٹس محدود کریں، قابلِ اعتماد شناخت کی تصدیق اور TLS فعال کریں، اور قابلِ اعتماد مستقل ذخیرہ کاری و آپریشنز کا منصوبہ بنائیں۔

ٹیسٹنگ، جامد جانچ اور تشخیص

پروجیکٹ کی جڑ میں backend ٹیسٹ اور معیار کی جانچ چلائیں:

.\.venv\Scripts\python.exe -m pytest -q
.\.venv\Scripts\python.exe -m ruff check app eval tests
.\.venv\Scripts\python.exe -m mypy
.\.venv\Scripts\python.exe -m eval.runner --task retrieval

فرنٹ اینڈ ٹیسٹ اور build کمانڈز frontend ڈائریکٹری میں چلانی ہوں گی:

npm test
npm run build

ٹیسٹ کی ترتیب مقامی ماڈل کیز کو الگ رکھتی ہے اور ٹیسٹ ڈیٹابیس استعمال کرتی ہے۔ حقیقی ماڈل کی تشخیص الگ سے چلانے سے پہلے ماڈل اور نیٹ ورک کی ترتیب جانچ لیں، کیونکہ بیرونی ماڈل کو کال کرنے پر اخراجات ہو سکتے ہیں۔

Jev اور DeepSeek کی نیت کی درجہ بندی کا موازنہ

دونوں ماڈلز کی مقامی کیز ترتیب دینے کے بعد، یکساں نمونوں اور یکساں overlay شرائط کے تحت موازنہ چلایا جا سکتا ہے:

.\.venv\Scripts\python.exe -m eval.compare_intent --backend both --limit 10 --no-overlay --output data/local/intent-comparison.json

رپورٹ میں درستگی، P50 اور P95 تاخیر، fallback کی تعداد اور قواعد کے ذریعے cover ہونے کی تعداد شامل ہوتی ہے۔ --no-overlay دونوں درجہ بندی کاروں کی قواعدی اصلاح بند کر دیتا ہے، تاکہ خود ماڈل کے درجہ بندی نتائج کا مشاہدہ کیا جا سکے؛ اس پیرامیٹر کو ہٹانے سے overlay شامل ہونے کے بعد کے نتائج کا موازنہ کیا جا سکتا ہے۔

موجودہ نیت کا ڈیٹاسیٹ development set ہے، اور درستگی میں fallback نمونے شامل ہوں گے؛ اسے براہِ راست Jev کے آزاد ماڈل کی عمومی صلاحیت نہیں سمجھا جا سکتا۔ سابقہ تشخیص اس بات کی نمائندگی نہیں کرتی کہ موجودہ ورژن کی دوبارہ توثیق ہو چکی ہے، اور نہ ہی یہ حقیقی کاروباری نتائج کی ضمانت ہے۔

عملی انجینئرنگ کی تجاویز

  1. پہلے پہلے سے طے شدہ مقامی موڈ میں عمل کی توثیق کریں: SQLite اور memory retrieval اجزا بنیادی مظاہرے کے لیے کافی ہیں؛ ابتدا ہی میں بیرونی ڈیٹابیس اور ویکٹر سروس تعینات کرنے کی ضرورت نہیں۔
  2. نیت کے ماڈل اور workflow ماڈل میں فرق رکھیں: Jev پر منتقل ہونے سے دوسرے DeepSeek nodes تبدیل نہیں ہوتے۔ مکمل آن لائن workflow چلانے کے لیے DeepSeek کی ترتیب پھر بھی درکار ہے۔
  3. مسائل کی جانچ کے لیے health endpoints استعمال کریں: /api/v1/health عمل کی جانچ کے لیے ہے، جبکہ /api/v1/ready اس بات کی تصدیق کے لیے زیادہ موزوں ہے کہ dependencies تیار ہیں۔
  4. حصے بنانے کی حکمتِ عملی تبدیل کرتے وقت احتیاط کریں: راستے، متن یا حصے بنانے کے پیرامیٹرز میں تبدیلی سے حصوں کی IDs اور تاریخی حوالوں پر اثر پڑ سکتا ہے۔
  5. عمل کے اندر موجود confirmation state پر انحصار نہ کریں: پہلے سے طے شدہ زیرِ تصدیق کارروائیاں صرف 15 منٹ تک مؤثر رہتی ہیں، اور restart یا متعدد processes کے درمیان تبدیلی سے ضائع ہو سکتی ہیں۔
  6. حساس ڈیٹا محفوظ رکھیں: .env، حقیقی کیز، مقامی ڈیٹابیس، logs، صارف کی اپ لوڈ کردہ دستاویزات یا نجی مواد GitHub پر commit نہ کریں۔
  7. بیرونی ڈیٹا کی منتقلی کا جائزہ لیں: بیرونی ماڈل یا remote MCP استعمال کرنے سے پہلے یقینی بنائیں کہ درخواست کے مواد میں ایسی صارف معلومات شامل نہ ہوں جنہیں باہر بھیجنا ممنوع ہو۔
  8. علمی ذخیرے کی تازہ کاری کا منصوبہ بنائیں: موجودہ نظام startup کے وقت مکمل اندراج کرتا ہے، اور ابھی مکمل incremental deletion عمل فراہم نہیں کرتا۔

پروجیکٹ ڈائریکٹری کا جائزہ

  • app/api：HTTP API اور SSE۔
  • app/agents：LangGraph execution graph اور workflow nodes۔
  • app/retrieval：تجزیہ کاری، حصے بنانا، recall، fusion اور reranking۔
  • app/providers：ماڈل اور ویکٹر سروس adapters۔
  • app/tools：کاروباری tools، tool registration اور اجازتوں کا کنٹرول۔
  • app/mcp：MCP tool integration۔
  • app/memory：conversation memory اور compression۔
  • app/guardrails：ان پٹ اور جواب کی جانچ۔
  • app/observability：logs اور metrics۔
  • frontend：React اور TypeScript chat interface۔
  • knowledge：پالیسی سے متعلق علمی دستاویزات۔
  • tests اور eval：خودکار ٹیسٹ، تشخیصی ڈیٹا اور execution runners۔

خلاصہ

Adaptive-RAG ای کامرس کسٹمر سروس ایک نسبتاً مکمل intelligent customer service engineering workflow پیش کرتی ہے: پہلے نیت کی شناخت اور پیچیدگی کا تعین کیا جاتا ہے، پھر ضرورت کے مطابق hybrid retrieval، متعدد turns میں شواہد کی تکمیل، tool calls، انسانی تصدیق اور fidelity validation کو یکجا کیا جاتا ہے۔ آپ پہلے SQLite، مظاہرے کے orders اور offline logic استعمال کر کے تیزی سے تجربہ کر سکتے ہیں، پھر بتدریج DeepSeek، Jev، مقامی vector model، Cross-Encoder، توسیعی دستاویز تجزیہ کاری اور Docker services فعال کر سکتے ہیں۔

حقیقی کاروبار میں داخل ہونے سے پہلے شناخت کی تصدیق، حقیقی order system integration، confirmation state کی مستقل ذخیرہ کاری، knowledge base کی incremental maintenance، key management اور production-grade network security کو ترجیحی بنیادوں پر مکمل کرنا ہوگا۔ پروجیکٹ MIT License کے تحت ہے؛ مزید architecture اور limitations کی وضاحت کے لیے architecture اور runtime flow، retrieval design اور limitations اور roadmap دیکھیں۔