HyDE کیا ہے؟ ورچوئل دستاویزات کے ساتھ RAG کو کیسے بہتر بنایا جائے۔

Retrieval-Augmented Generation، جسے عام طور پر RAG کے نام سے جانا جاتا ہے، بڑے پیمانے پر لینگویج ماڈلز کا استعمال کرتے ہوئے ایپلی کیشنز بنانے کے لیے سب سے زیادہ مقبول طریقوں میں سے ایک بن گیا ہے۔

LLM سے مکمل طور پر تربیتی ڈیٹا سے جواب دینے کے لیے کہنے کے بجائے، RAG سسٹم ایک بیرونی علمی بنیاد سے متعلقہ معلومات حاصل کرتا ہے اور وہ معلومات ماڈل کے سیاق و سباق کے طور پر فراہم کرتا ہے۔

بنیادی خیال سادہ ہے۔

  • صارف کے سوال کو ایمبیڈنگ میں تبدیل کریں۔

  • لفظی طور پر ملتے جلتے دستاویزات کے ٹکڑوں کے لیے ویکٹر ڈیٹا بیس تلاش کریں۔

  • بازیافت شدہ ٹکڑوں کو LLM میں منتقل کریں۔

  • ان ٹکڑوں کی بنیاد پر جواب تیار کریں۔

تاہم بظاہر آسان نظر آنے والے اس عمل کی ایک بڑی کمزوری ہے۔ اس کا مطلب ہے کہ آپ کے سوالات اور جوابات پر مشتمل دستاویز بہت مختلف انداز میں لکھی جا سکتی ہے۔

صارفین سوالات پوچھ سکتے ہیں جیسے:

لاکھوں ریکارڈ پر کارروائی کرنے کے بعد میرا AWS Glue کام کافی سست کیوں ہے؟

علم کی بنیاد میں متعلقہ مضمون یہ کہہ سکتا ہے:

خراب کارکردگی اس وقت ہو سکتی ہے جب اسپارک ایگزیکیوٹرز کو ضرورت سے زیادہ شفلنگ آپریشنز، گڑبڑ پارٹیشنز، ناکافی میموری، یا بار بار ڈسک لیک ہونے کا تجربہ ہوتا ہے۔

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

یہ وہ مسئلہ ہے جسے حل کرنے کے لیے HyDE (HyDE) کو ڈیزائن کیا گیا تھا۔

انڈیکس

شرطیں

اس مضمون سے زیادہ سے زیادہ فائدہ اٹھانے کے لیے آپ کو کچھ چیزیں جاننے کی ضرورت ہے۔

آپ کو کیا جاننے کی ضرورت ہے:

  • RAG کے بارے میں بنیادی معلومات اور اسے کیوں استعمال کیا جاتا ہے۔

  • تصوراتی سطح پر ویکٹر ایمبیڈنگز کیسے کام کرتی ہیں۔

  • ازگر کا کام کرنے والا علم۔

آپ کے پاس کیا ہونا چاہیے:

  • numpy، جملہ کنورٹر، اور Anthropic انسٹال کے ساتھ ایک مقامی ازگر کا ماحول۔

  • اگر آپ HyDE کوڈ کے نمونے چلانا چاہتے ہیں تو ایک Anthropic API کلید (console.anthropic.com پر دستیاب ہے)۔

HyDE کیا ہے؟

HyDE کا مطلب ہے فرضی دستاویز ایمبیڈنگ۔ ٹیکنالوجی سادہ ہے. استفسار کرتے وقت، ہم LLM سے کہتے ہیں کہ صارف کے سوال کا جواب دینے کے لیے ایک ورچوئل دستاویز بنائیں، استفسار کی جگہ اس دستاویز کو داخل کریں، اور انڈیکس کو تلاش کرنے کے لیے اس ویکٹر کا استعمال کریں۔ بس۔ باقی سب انجینئرنگ ہے۔

50c5909c-c7fa-4c92-bf11-c7a1b3411142

شکل 2: HyDE عمل

فرضی دستاویزات کو حتمی جواب نہیں سمجھا جاتا۔ یہ صرف صارف کے استفسار اور نالج بیس میں محفوظ اصل دستاویزات کے درمیان ایک پل کا کام کرتا ہے۔

یہ تفریق بہت اہم ہے۔

تیار کردہ دستاویز میں غلط تفصیلات ہوسکتی ہیں۔ یہ لازمی طور پر ناکامی نہیں ہے کیونکہ سسٹم اسے براہ راست صارف کو ظاہر نہیں کرتا ہے۔ مقصد یہ ہے کہ جس معلومات کی تلاش کی جا رہی ہے اس کی ایک بھرپور سیمینٹک نمائندگی پیدا کی جائے۔

اصل HyDE اپروچ نے ورچوئل دستاویز بنانے کے لیے زبان کے ماڈل کا استعمال کیا اور اس دستاویز کو سرایت کرنے والی جگہ پر نقشہ بنانے کے لیے ایک غیر زیر نگرانی گھنے تلاش کنندہ کا استعمال کیا۔ ایمبیڈنگز کارپس سے اصل دستاویزات کی بازیافت کے لیے سرچ کمانڈز کے طور پر کام کرتی ہیں۔

HyDE کیوں کام کرتا ہے۔

وجدان ہندسی ہے۔ ایک گھنے تلاش کرنے والا متن کو ایک معنوی جگہ میں پیش کرتا ہے، اور متن کے دو ٹکڑوں کے درمیان مماثلت ویکٹرز کے درمیان زاویہ کی کوزائن ہے۔

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

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

یہ سارا میکانزم ہے۔ باقی سب کچھ – تیز انجینئرنگ، ماڈل کا انتخاب، کیشنگ – اس ایک ہندسی حقیقت کا بہاو ہے۔

HyDE کی میکانکس

سب سے پہلے، ہم یہ کہتے ہیں کہ صارف مندرجہ ذیل سوال پوچھتا ہے: میرے لیمبڈا فنکشن کو جواب دینے میں زیادہ وقت کیوں لگ رہا ہے جب اسے کچھ عرصے سے کال نہیں کیا گیا ہے؟

پھر LLM سے وہ سوال ایک مختصر پرامپٹ کے طور پر پوچھیں۔ "اس سوال کا جواب دینے والے تکنیکی مضمون سے ایک حوالہ لکھیں۔”

LLM جواب دیتا ہے:

"AWS Lambda نے ایک ایسے ایگزیکیوشن ماحول کا دوبارہ دعویٰ کیا ہے جو کچھ عرصے سے بیکار تھا۔ جب کسی فنکشن کو دوبارہ شروع کیا جاتا ہے، تو اسے رن ٹائم سیٹ اپ کرنے اور لوڈنگ کے انحصار سے وابستہ ایک کولڈ سٹارٹ کا سامنا کرنا پڑتا ہے۔ یہ بیکار مدت کے بعد پہلی درخواست میں تاخیر کا اضافہ کرتا ہے۔”

اب پیدا شدہ آیت داخل کریں۔ یہ اصل سوال نہیں ہے، یہ جملہ ہے۔

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

اگلا، ہم اصل صارف کے سوال کے ساتھ جنریٹر کو بازیافت کی گئی سب سے اوپر کی دستاویزات بھیجتے ہیں۔ جنریٹر اس کی بازیافت شدہ اصل دستاویز کا استعمال کرتے ہوئے جواب دیتا ہے۔ مفروضہ رد کر دیا گیا ہے۔

ایل ایل ایم کو دو بار استعمال کیا گیا، لیکن مختلف کاموں کے لیے۔ ایک بار جب ہم نے سوال کو ایک دستاویز کے طور پر دوبارہ لکھا، اور ایک بار پھر ہم نے سوال کا جواب دینے کے لیے بازیافت شدہ دستاویز کا استعمال کیا۔ پہلی کال سستی ہے اور داؤ کم ہے۔ دوسرا ایک اہم ہے۔

شکل 3: Naive RAG اور HyDE پائپ لائنوں کا موازنہ۔

چترا 3: Naïve RAG اور HyDE پائپ لائنوں کا موازنہ۔

کم سے کم نفاذ

ایک بولی RAG اس طرح نظر آئے گا:

import numpy as np
from sentence_transformers import SentenceTransformer

collection = [
    "AWS Lambda reclaims idle execution environments after a period of inactivity, causing a cold start on the next invocation that includes runtime bootstrap and dependency loading.",
    "Apache Airflow schedules tasks using a directed acyclic graph, where each node represents a unit of work.",
    "AWS Glue crawlers infer schemas from source data and populate the Glue Data Catalog automatically.",
    "Amazon Bedrock exposes foundation models behind a single API and handles provisioning transparently.",
    "DynamoDB partitions data across nodes using the partition key, which determines physical placement.",
]

embedder = SentenceTransformer("all-MiniLM-L6-v2")
collection_embeddings = embedder.encode(collection, normalize_embeddings=True)

def retrieve(query: str, k: int = 2) -> list[str]:
    query_embedding = embedder.encode(query, normalize_embeddings=True)
    scores = collection_embeddings @ query_embedding
    top_k = np.argsort(scores)[::-1][:k]
    return [collection[i] for i in top_k]

query = "Why does my Lambda function take longer to respond when it hasn't been called in a while?"
for passage in retrieve(query):
    print(passage)

یہ نمونہ جمع کرنے کا امکان ہے کہ رینک 1 پر صحیح اقتباس واپس آجائے۔ جب ہم 50,000 دستاویزات کو اصل استفسار کے فرق کے ساتھ پیمانہ کرتے ہیں، تو صحیح اقتباسات درجہ بندی میں نیچے جانے لگتے ہیں۔

آگے جو کچھ آتا ہے اس پر توجہ دینے کی لائن تلاش کے اندر کی لائن ہے۔ embedder.encode(query, ...) دوڑو۔ یہ وہ جگہ ہے جہاں خام سوال ایک ویکٹر بن جاتا ہے، اور یہ وہ لائن ہے جو HyDE بدلتی ہے۔

HyDE متغیر میں، ڈیلٹا ایک فنکشن ہے۔

import numpy as np
from anthropic import Anthropic
from sentence_transformers import SentenceTransformer

# collection. In production this is your vector store.

collection = [
    "AWS Lambda reclaims idle execution environments after a period of inactivity, causing a cold start on the next invocation that includes runtime bootstrap and dependency loading.",
    "Apache Airflow schedules tasks using a directed acyclic graph, where each node represents a unit of work.",
    "AWS Glue crawlers infer schemas from source data and populate the Glue Data Catalog automatically.",
    "Amazon Bedrock exposes foundation models behind a single API and handles provisioning transparently.",
    "DynamoDB partitions data across nodes using the partition key, which determines physical placement.",
]

embedder = SentenceTransformer("all-MiniLM-L6-v2")
corpus_embeddings = embedder.encode(collection, normalize_embeddings=True)

client = Anthropic()

# HyDE: generate a hypothetical answer, embed that, then search.

HYDE_PROMPT = (
    "Write a short passage from technical documentation that would answer "
    "the following question. Write in the register of official docs: "
    "declarative, precise, no hedging. Do not include the question itself. "
    "Passage only, two to four sentences.nn"
    "Question: {query}"
)

def generate_hypothetical(query: str) -> str:
    """Ask an LLM to write a fake documentation passage answering the query."""
    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=200,
        messages=[
            {"role": "user", "content": HYDE_PROMPT.format(query=query)}
        ],
    )
    return message.content[0].text

def retrieve_hyde(query: str, k: int = 2) -> list[str]:
    """Generate a hypothetical passage, embed it, and search with that vector."""
    hypothetical = generate_hypothetical(query)
    hyde_embedding = embedder.encode(hypothetical, normalize_embeddings=True)
    scores = corpus_embeddings @ hyde_embedding
    top_k_indices = np.argsort(scores)[::-1][:k]
    return [collection[i] for i in top_k_indices]

if __name__ == "__main__":
    query = (
        "Why does my Lambda function take longer to respond "
        "when it hasn't been called in a while?"
    )
    for passage in retrieve_hyde(query):
        print(passage)

یہ پوری تکنیک ہے۔ ایک اضافی LLM کال اور ایک اضافی خصوصیت ہے، باقی سب کچھ بیس لائن کی طرح ہے۔ سیوڈو ٹیکسٹ داخل کرنے کے بعد ضائع کر دیا جاتا ہے اور کبھی جنریٹر تک نہیں پہنچتا۔

Naïve بیس لائن سوال کو براہ راست ویکٹرائز کرتی ہے اور کلیکشن ویکٹرز پر کوزائن مماثلت کی تلاش کرتی ہے۔ یہ کوڈ کی یہ ایک لائن ہے جو کال کرتی ہے: embedder.encode(query, ...)یہاں سوالات کو جوابی ویکٹر کی شکل کے بجائے سوال کی شکل کے ویکٹرز میں ویکٹرائز کیا گیا ہے، جو اس مضمون میں زیر بحث تلاش کے معیار کے مسائل کی واحد وجہ ہے۔

HyDE نقطہ نظر کے درمیان صرف ایک فرق ہے۔ سرایت کرنے سے پہلے، LLM سے تکنیکی دستاویز کے رجسٹر میں متن کا ایک چھوٹا ٹکڑا تیار کرنے کو کہا جاتا ہے جو سوال کا جواب دیتا ہے، اور اس متن کے لیے اصل سوال کے بجائے ویکٹر کی گنتی کی جاتی ہے۔ باقی سب کچھ بالکل ویسا ہی رہتا ہے۔ ایک ہی ایمبیڈنگ ماڈل، کوزائن مماثلت کی تلاش اور ٹاپ-کے سلیکشن کا استعمال کیا جاتا ہے۔

یہ فرضی اقتباس کبھی بھی تلاش ویکٹر پیدا کرنے کے علاوہ کسی اور مقصد کے لیے استعمال نہیں ہوتا ہے۔ فرق تلاش کے طریقہ کار میں فرق نہیں ہے، صرف متن کی ظاہری شکل میں تبدیلی ہے۔

ہیلوسینیشن خود بخود HyDE کو کیوں نہیں روکتے

پہلی نظر میں، HyDE متضاد لگتا ہے. حقائق کو بازیافت کرنے سے پہلے زبان کے ماڈل سے معلومات پیدا کرنے کا کہہ کر ایک نظام حقائق کی بازیافت کو کیوں بہتر بناتا ہے؟

جواب یہ ہے کہ HyDE تیار کردہ دستاویزات کو مستند علم کے بجائے تلاش کی نمائندگی کے طور پر استعمال کرتا ہے۔

ہم کہتے ہیں کہ ایک صارف مندرجہ ذیل سوال پوچھتا ہے: 18 جولائی کو ڈیٹا بیس کی بندش کی وجہ کیا تھی؟ LLM ذاتی حادثے کی رپورٹ سے اصل وجہ کا تعین نہیں کر سکتا۔ آپ کو کچھ بنانا ہوگا۔

تو آپ یہ بھی کہہ سکتے ہیں:

"18 جولائی کو ڈیٹا بیس کی بندش پرائمری ریپلیکا پر فیل اوور کنفیگریشن کی خرابی کی وجہ سے تھی، جس کی وجہ سے منحصر خدمات میں کنکشن کا وقت ختم ہو گیا۔ انجینئرز نے ٹریفک کو ثانوی علاقے میں تبدیل کرکے اور کنکشن پول کو دوبارہ بنا کر سروس کو بحال کیا۔”

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

ڈیٹا بیس کی بندش پر پوسٹ مارٹم ڈیٹا بیس کی بندش پر پوسٹ مارٹم کی طرح لگتا ہے۔ وہ الفاظ، رجسٹر، اور ساخت کا اشتراک کرتے ہیں، قطع نظر ان کی مخصوص بنیادی وجہ سے۔

LLM کی طرف سے تیار کردہ راستے کنکشن کی سنترپتی، لاک تنازعہ، اسٹوریج میں تاخیر، تعیناتی کی ناکامی، یا وسائل کی تھکن کو دور کرسکتے ہیں۔ ان میں سے کچھ تفصیلات غلط ہو سکتی ہیں، لیکن اس سے کوئی فرق نہیں پڑتا۔ ان میں سے ہر ایک اصطلاح اب بھی اسی ماحول میں سرایت کر جاتی ہے جیسے حقیقی دنیا کی بندش کا تجزیہ، بنیادی وجہ رپورٹس، ڈیٹا بیس میٹرکس، اور عمل کے بعد کی دستاویزات۔

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

مفروضہ حقائق کے بارے میں غلط تھا، لیکن شکل کے بارے میں درست تھا۔ شکل وہی ہے جو سرایت کرنے والا دیکھتا ہے۔ حقائق وہی ہیں جو بازیافت شدہ دستاویزات فراہم کرتے ہیں۔

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

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

پیداوار کی پٹیاں

HyDE نے LLM کو اپنی تلاش کے راستے میں شامل کیا، جس سے انجینئرنگ کے نئے چیلنجز پیدا ہوتے ہیں۔ یہاں کچھ پروڈکشن گارڈریل ہیں جو آپ اپنے کام کو مزید محفوظ اور قابل اعتماد بنانے کے لیے شامل کر سکتے ہیں۔

ٹائم آؤٹ اور فال بیک نفاذ

اگر ورچوئل تخلیق سست ہے یا ناکام ہو جاتی ہے، تو صارف کو بلاک کیے جانے کے بجائے ایک سادہ تلاش کی طرف لے جایا جائے گا۔

def retrieve_with_fallback(query: str, k: int = 2) -> list[str]:
    try:
        hypothetical = generate_hypothetical(query)
        search_vector = embedder.encode(hypothetical, normalize_embeddings=True)
    except Exception:
        logger.exception(
            "HyDE generation failed; falling back to the original query."
        ) 
        # Fall back to embedding the raw query
        search_vector = embedder.encode(query, normalize_embeddings=True)

    scores = corpus_embeddings @ search_vector
    top_k = np.argsort(scores)[::-1][:k]
    return [collection[i] for i in top_k]

کلائنٹ پر ہی ایک واضح ٹائم آؤٹ سیٹ کریں۔ [Anthropic(timeout=3.0)]

تخلیق کی لمبائی کی حد

لمبی ورچوئل دستاویزات غیر متعلقہ تصورات متعارف کرواتی ہیں اور سرایت کو کمزور کرتی ہیں۔ ایل ایل ایم کالز سے آؤٹ پٹ کو محدود کریں۔

message = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=200,   # keep the hypothetical dense
    messages=[{"role": "user", "content": HYDE_PROMPT.format(query=query)}],
)

تکنیکی دستاویزات کے علاقے میں ہدف کے متن کے لیے 200 ٹوکن کافی ہیں۔ اس سے زیادہ کچھ بھی عام طور پر تلاش کو زیادہ مشکل بنا دیتا ہے۔

حساس ڈیٹا کو بیرونی ماڈل فراہم کنندگان کو بھیجنے سے پہلے اس کی حفاظت کریں۔

ہم مفروضے کی تخلیق کو چلانے سے پہلے ان پٹ سے ذاتی طور پر قابل شناخت ڈیٹا کو ہٹا دیتے ہیں اور اسے نیچے کی طرف کال کرنے والوں پر انحصار کرنے کے بجائے انٹرفیس کی سطح پر نافذ کرتے ہیں۔

PII_PATTERNS = {
    "email": r'b[w.-]+@[w.-]+.w+b',
    "ssn":   r'bd{3}-d{2}-d{4}b',
    "card":  r'bd{4}[s-]?d{4}[s-]?d{4}[s-]?d{4}b',
}

def scrub_pii(text: str) -> str:
    for label, pattern in PII_PATTERNS.items():
        text = re.sub(pattern, f"[REDACTED_{label.upper()}]", text)
    return text

def safe_generate_hypothetical(query: str) -> str:
    return generate_hypothetical(scrub_pii(query))

ریگولیٹڈ ڈیٹا کے لیے یہ سب سے کم ضرورت ہے۔ اس کے اوپر مزید کنٹرولز شامل کریں۔

ہر قدم کو ٹریک کریں۔

ہر قدم پر مرئیت کے بغیر، تلاش کے مسائل کو ڈیبگ کرنے کا کوئی طریقہ نہیں ہے۔ ہر استفسار کے لیے استفسار، فوری، مصنوعی جواب، تاخیر، بازیافت شدہ ID، اور مماثلت اسکور جمع کرتا ہے۔

import time
import logging

logger = logging.getLogger(__name__)

def traced_retrieve_hyde(query: str, k: int = 2) -> HyDEContext:
    t0 = time.time()
    hypothetical = generate_hypothetical(query)
    gen_ms = int((time.time() - t0) * 1000)

    t1 = time.time()
    search_vector = embedder.encode(hypothetical, normalize_embeddings=True)
    embed_ms = int((time.time() - t1) * 1000)

    scores = corpus_embeddings @ search_vector
    top_k = np.argsort(scores)[::-1][:k]

    logger.info(
        "hyde_retrieval",
        extra={
            "query": query,
            "prompt_version": "v1",
            "hypothetical": hypothetical,
            "gen_latency_ms": gen_ms,
            "embed_latency_ms": embed_ms,
            "retrieved_ids": top_k.tolist(),
            "similarity_scores": [float(scores[i]) for i in top_k],
        },
    )
    return HyDEContext(
        original_query=query,
        hypothetical=hypothetical,
        retrieved_documents=[collection[i] for i in top_k],
    )

سٹرکچرڈ لاگز لیٹنسی ڈیش بورڈز، ڈرفٹ الرٹس، اور آف لائن تلاش کے جائزوں کی بنیاد بناتے ہیں۔

HyDE کب استعمال کریں اور کب استعمال نہ کریں۔

درج ذیل صورتوں میں HyDE کا استعمال کریں:

  • سرایت کرنے والا ماڈل ڈومین کو پوری طرح سے نہیں سمجھتا ہے۔

  • تلاش کنندہ کو ٹھیک کرنے کے لیے کوئی لیبل شدہ استفسار دستاویز جوڑے نہیں ہیں۔

  • صارفین انٹرایکٹو سوالات پوچھتے ہیں، لیکن دستاویزات رسمی یا تکنیکی ہیں۔

  • آپ اپنی تلاش سے پہلے ایک اضافی LLM کال برداشت کر سکتے ہیں۔

HyDE سے بچیں اگر:

  • آپ کی درخواست میں تاخیر کے سخت تقاضے ہیں۔

  • ایک عام مقصد کا LLM ڈومین کی غلط اصطلاحات پیدا کر سکتا ہے۔

  • آپ کی تلاش کی اصطلاح پہلے سے ہی مضبوط کلیدی الفاظ، شناخت کنندگان، یا ایرر کوڈز پر مشتمل ہے۔

  • BM25 یا ہائبرڈ تلاش پہلے ہی متعلقہ نتائج حاصل کر لیتی ہے۔

  • خود ڈیٹیکٹر کو ٹھیک کرنے کے لیے کافی لیبل شدہ ڈیٹا موجود ہے۔

خلاصہ

HyDE ایک چھوٹا خیال ہے جس کا بڑا اثر ہے۔ یہ انڈیکس، ایمبیڈنگ ماڈل، یا جنریٹر کو تبدیل نہیں کرتا ہے۔ میں ایک لائن بدل رہا ہوں۔ جب استفسار آتا ہے تو یہی شامل ہوتا ہے۔ یہ واحد تبدیلی تلاش کے ڈھانچے کو سوال سے جواب سے جواب سے جواب تک تبدیل کرتی ہے، جس کے بعد تلاش کا معیار آتا ہے۔

ٹیکنالوجی جادو نہیں ہے. یہ صرف اس صورت میں برقرار رہتا ہے جب آپ لیٹنسی اور کال اور استفسار کے لیے لاگت کو ختم کرتے ہیں اور دستاویز کی مطابقت پائپ لائن میں ایک حقیقی رکاوٹ ہے۔ اگر ایسا ہے تو، HyDE آپ کے RAG ٹول باکس میں سب سے سستی جیتوں میں سے ایک ہے۔

اوپر تک سکرول کریں۔