انقلابی مونسٹر ہنٹس: AI سے بہتر ڈی اینڈ ڈی مقابلے

تاریکی کی AI سے چلنے والی فوج

یہ کھیل کی رات ہے، آپ کے دوست گیمز کی میز کے ارد گرد بیٹھے ہیں، یہ دیکھنے کے لیے انتظار کر رہے ہیں کہ وہ کون سا Dungeons & Dragons (D&D) کردار بنیں گے اور جس تلاش میں وہ شروع ہوں گے۔ آج رات، آپ Dungeon Master (کہانی سنانے والے اور گائیڈ) ہیں، اپنے کھلاڑیوں کو للکارنے اور ان کا دل موہ لینے کے لیے سنسنی خیز مقابلوں کے ماہر ہیں۔ آپ کے قابل اعتماد ڈی اینڈ ڈی مونسٹر مینوئل میں ہزاروں مخلوقات شامل ہیں۔ بے شمار اختیارات میں سے ہر صورت حال کے لیے کامل عفریت کی تلاش بہت زیادہ ہو سکتی ہے۔ مثالی دشمن کو اس لمحے کی ترتیب، مشکل اور بیانیہ سے مطابقت رکھنے کی ضرورت ہے۔

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

آئیے اپنی ایک جستجو کا آغاز کریں: ملٹی ایٹریبیوٹ ویکٹر سرچ کی طاقت کا استعمال کرتے ہوئے، حتمی مونسٹر فائنڈنگ سسٹم بنائیں!

ویکٹر کی تلاش سے مخلوق پیدا کرنا، ایسا کیوں؟

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

ملٹی انتساب ویکٹر کی تلاش کے لیے دو عام طریقے ہیں۔ دونوں الگ الگ ڈیٹا آبجیکٹ کے ہر وصف کو سرایت کرکے شروع کرتے ہیں۔ ان دو طریقوں کے درمیان بنیادی فرق یہ ہے کہ ہماری ایمبیڈنگز کو کیسے ذخیرہ اور تلاش کیا جاتا ہے۔

1. سادہ نقطہ نظر - ہر ویکٹر ویکٹر کو الگ الگ ویکٹر اسٹورز میں اسٹور کریں (ایک فی وصف)، ہر ایک وصف کے لیے الگ تلاش کریں، تلاش کے نتائج کو یکجا کریں، اور بعد از عمل (مثلاً وزن) حسب ضرورت۔
2. سپر لنکڈ اپروچ - تمام انتساب ویکٹرز کو ایک ہی ویکٹر اسٹور میں جوڑیں اور اسٹور کریں (سپر لنکڈ کی بلٹ ان فنکشنلٹی کا استعمال کرتے ہوئے)، جو ہمیں صرف ایک بار تلاش کرنے کی اجازت دیتا ہے، اٹینڈنٹ کی کارکردگی کے فوائد کے ساتھ۔ سپر لنکڈ کی spaces ہمیں استفسار کے وقت ہر ایک وصف کا وزن کرنے دیتی ہیں تاکہ مزید متعلقہ نتائج سامنے آئیں، بغیر کسی پوسٹ پروسیسنگ کے۔

ذیل میں، ہم ملٹی ایٹریبیوٹ ویکٹر سرچ ٹول کو لاگو کرنے کے لیے ان دو طریقوں کا استعمال کریں گے - ایک Dungeons and Dragons Monster Finder! ہمارے سادہ نفاذ، خاص طور پر دوسرا، یہ واضح کرے گا کہ کس طرح زیادہ طاقتور اور لچکدار تلاش کے نظام بنائے جائیں، جو پیچیدہ، کثیر جہتی سوالات کو آسانی کے ساتھ ہینڈل کر سکتے ہیں، چاہے آپ کے استعمال کا معاملہ کچھ بھی ہو۔

اگر آپ ویکٹر مماثلت کی تلاش میں نئے ہیں، تو پریشان نہ ہوں! ہم نے آپ کا احاطہ کیا ہے - ہمارے بلڈنگ بلاکس کے مضامین دیکھیں۔

ٹھیک ہے، چلو عفریت کا شکار کرتے ہیں!

ڈیٹا سیٹ

سب سے پہلے، ہم ایک بڑے لینگویج ماڈل (LLM) کا اشارہ دے کر، راکشسوں کا ایک چھوٹا مصنوعی ڈیٹا سیٹ تیار کریں گے:

 Generate two JSON lists: 'monsters' and 'queries'. 1. 'monsters' list: Create 20 unique monsters with the following properties: - name: A distinctive name - look: Brief description of appearance (2-3 sentences) - habitat: Where the monster lives (2-3 sentences) - behavior: How the monster acts (2-3 sentences) Ensure some monsters share similar features while remaining distinct. 2. 'queries' list: Create 5 queries to search for monsters: - Each query should be in the format: {look: "...", habitat: "...", behavior: "..."} - Use simple, brief descriptions (1-3 words per field) - Make queries somewhat general to match multiple monsters Output format: { "monsters": [ {"name": "...", "look": "...", "habitat": "...", "behavior": "..."}, ... ], "queries": [ {"look": "...", "habitat": "...", "behavior": "..."}, ... ] }

آئیے ہمارے LLM کے تیار کردہ ڈیٹاسیٹ کے نمونے پر ایک نظر ڈالیں۔ نوٹ: LLM جنریشن غیر فیصلہ کن ہے، اس لیے آپ کے نتائج مختلف ہو سکتے ہیں۔

ہمارے پہلے پانچ راکشس یہ ہیں:

...اور ہمارے پیدا کردہ سوالات:

اصل ڈیٹا سیٹ اور استفسار کی مثالیں یہاں دیکھیں۔

بازیافت

آئیے پیرامیٹرز مرتب کریں جو ہم اپنے دونوں طریقوں میں استعمال کریں گے - بولی اور سپر لنکڈ - نیچے۔

ہم اپنے ویکٹر ایمبیڈنگ اس کے ساتھ تیار کرتے ہیں:

 sentence-transformers/all-mpnet-base-v2.

سادگی کی خاطر، ہم اپنے آؤٹ پٹ کو ٹاپ 3 میچوں تک محدود کر دیں گے۔ (مکمل کوڈ کے لیے، بشمول ضروری درآمدات اور مددگار افعال، نوٹ بک دیکھیں۔)

 LIMIT = 3 MODEL_NAME = "sentence-transformers/all-mpnet-base-v2"

اب، آئیے اپنی کثیر الصفات عفریت کی تلاش جاری رکھیں! سب سے پہلے، ہم بولی نقطہ نظر کی کوشش کریں گے.

بولی نقطہ نظر

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

ہم کلاس کی وضاحت کرتے ہوئے شروع کرتے ہیں۔

 NaiveRetriever

ہمارے all-mpnet-base-v2 -generated embeddings کا استعمال کرتے ہوئے، ہمارے ڈیٹاسیٹ پر مماثلت پر مبنی تلاش کرنے کے لیے۔

 class NaiveRetriever: def __init__(self, data: pd.DataFrame): self.model = SentenceTransformer(MODEL_NAME) self.data = data.copy() self.ids = self.data.index.to_list() self.knns = {} for key in self.data: embeddings = self.model.encode(self.data[key].values) knn = NearestNeighbors(metric="cosine").fit(embeddings) self.knns[key] = knn def search_key(self, key: str, value: str, limit: int = LIMIT) -> pd.DataFrame: embedding = self.model.encode(value) knn = self.knns[key] distances, indices = knn.kneighbors( [embedding], n_neighbors=limit, return_distance=True ) ids = [self.ids[i] for i in indices[0]] similarities = (1 - distances).flatten() # by definition: # cosine distance = 1 - cosine similarity result = pd.DataFrame( {"id": ids, f"score_{key}": similarities, key: self.data[key][ids]} ) result.set_index("id", inplace=True) return result def search(self, query: dict, limit: int = LIMIT) -> pd.DataFrame: results = [] for key, value in query.items(): if key not in self.knns: continue result_key = self.search_key(key, value, limit=limit) result_key.drop(columns=[key], inplace=True) results.append(result_key) merged_results = pd.concat(results, axis=1) merged_results["score"] = merged_results.mean(axis=1, skipna=False) merged_results.sort_values("score", ascending=False, inplace=True) return merged_results naive_retriever = NaiveRetriever(df.set_index("name"))

آئیے اوپر ہماری تیار کردہ فہرست سے پہلا سوال استعمال کریں، اور اپنے naive_retriever استعمال کرتے ہوئے راکشسوں کو تلاش کریں:

 query = { 'look': 'glowing', 'habitat': 'dark places', 'behavior': 'light manipulation' } naive_retriever.search(query)

ہماری

 naive_retriever

ہر ایک خصوصیت کے لیے درج ذیل تلاش کے نتائج لوٹاتا ہے:

بہت اچھے! ہمارے لوٹے ہوئے عفریت کے نتائج متعلقہ ہیں - ان سب میں کچھ "چمکنے والی" خصوصیت ہے۔

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

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

اور یہاں، بولی اپروچ کی حدیں واضح ہو جاتی ہیں۔ آئیے اندازہ لگاتے ہیں:

1. وصف کے لحاظ سے مطابقت:
   • look : تین راکشسوں کو بازیافت کیا گیا تھا (فسپرنگ شیڈ، سینڈ اسٹورم جین، اور لومینوت)۔
   • habitat : look نتائج سے صرف ایک عفریت متعلقہ تھا (سرگوشی کا سایہ)۔
   • behavior : look نتائج سے صرف ایک عفریت متعلقہ تھا (Luminoth)، لیکن یہ habitat کے لیے متعلقہ سے مختلف ہے۔
2. مجموعی مطابقت:
   • بیک وقت تینوں صفات کے لیے کوئی ایک راکشس بازیافت نہیں کیا گیا۔
   • نتائج بکھرے ہوئے ہیں: مختلف راکشس مختلف صفات کے لیے متعلقہ ہیں۔

مختصراً، بولی تلاش کا طریقہ ایسے راکشسوں کو تلاش کرنے میں ناکام رہتا ہے جو ایک ساتھ تمام معیارات کو پورا کرتے ہیں۔ ہو سکتا ہے کہ ہم ہر ایک وصف کے لیے مزید راکشسوں کو فعال طور پر بازیافت کر کے اس مسئلے کو حل کر سکیں؟ آئیے اسے 3 کے بجائے 6 راکشس فی انتساب کے ساتھ آزماتے ہیں۔ آئیے ایک نظر ڈالتے ہیں کہ یہ نقطہ نظر کیا پیدا کرتا ہے:

اب ہم نے 13 راکشسوں کو بازیافت کیا ہے (ہمارے چھوٹے ڈیٹاسیٹ کے آدھے سے زیادہ!)، اور اب بھی ایک ہی مسئلہ ہے: ان تینوں صفات کے لیے ان میں سے کسی ایک کو بھی بازیافت نہیں کیا گیا۔

بازیافت شدہ راکشسوں کی تعداد میں اضافہ (6 سے زیادہ) ہمارا مسئلہ حل کر سکتا ہے ، لیکن اس سے اضافی مسائل پیدا ہوتے ہیں:

1. پیداوار میں، مزید نتائج کی بازیافت (متعدد kNN تلاشیں) تلاش کے وقت کو نمایاں طور پر بڑھاتا ہے۔
2. ہر نئی خصوصیت کے لیے جو ہم متعارف کراتے ہیں، ایک "مکمل" عفریت تلاش کرنے کے ہمارے امکانات - ہماری استفسار میں موجود تمام صفات کے ساتھ - تیزی سے کم ہو جاتے ہیں۔ اسے روکنے کے لیے، ہمیں بہت سے قریبی پڑوسیوں (راکشسوں) کو بازیافت کرنا ہوگا، جس سے بازیافت شدہ راکشسوں کی کل تعداد تیزی سے بڑھ رہی ہے۔
3. ہمارے پاس اب بھی کوئی گارنٹی نہیں ہے کہ ہم ان راکشسوں کو بازیافت کریں گے جو ہماری تمام مطلوبہ صفات کے مالک ہیں۔
4. اگر ہم ایسے راکشسوں کو بازیافت کرنے کا انتظام کرتے ہیں جو ایک ہی وقت میں تمام معیارات کو پورا کرتے ہیں، تو ہمیں اضافی اوور ہیڈ مصالحتی نتائج کو خرچ کرنا پڑے گا۔

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

سپر لنک شدہ نقطہ نظر

آئیے اپنے دوسرے نقطہ نظر کو لاگو کرتے ہیں یہ دیکھنے کے لیے کہ آیا یہ بولی سے بہتر کام کرتا ہے۔

سب سے پہلے، ہم اسکیما، اسپیس، انڈیکس، اور استفسار کی وضاحت کرتے ہیں:

 @schema class Monster: id: IdField look: String habitat: String behavior: String monster = Monster() look_space = TextSimilaritySpace(text=monster.look, model=MODEL_NAME) habitat_space = TextSimilaritySpace(text=monster.habitat, model=MODEL_NAME) behavior_space = TextSimilaritySpace(text=monster.behavior, model=MODEL_NAME) monster_index = Index([look_space, habitat_space, behavior_space]) monster_query = ( Query( monster_index, weights={ look_space: Param("look_weight"), habitat_space: Param("habitat_weight"), behavior_space: Param("behavior_weight"), }, ) .find(monster) .similar(look_space.text, Param("look")) .similar(habitat_space.text, Param("habitat")) .similar(behavior_space.text, Param("behavior")) .limit(LIMIT) ) default_weights = { "look_weight": 1.0, "habitat_weight": 1.0, "behavior_weight": 1.0 }

اب، ہم ایگزیکیوٹر شروع کرتے ہیں اور ڈیٹا اپ لوڈ کرتے ہیں:

 monster_parser = DataFrameParser(monster, mapping={monster.id: "name"}) source: InMemorySource = InMemorySource(monster, parser=monster_parser) executor = InMemoryExecutor(sources=[source], indices=[monster_index]) app = executor.run() source.put([df])

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

 query = { 'look': 'glowing', 'habitat': 'dark places', 'behavior': 'light manipulation' } app.query( monster_query, limit=LIMIT, **query, **default_weights )

اور آواز! اس بار، ہمارے سب سے اوپر آنے والے راکشسوں میں سے ہر ایک اس اسکور میں اعلیٰ درجہ پر ہے جو ان تینوں خصوصیات میں سے ایک قسم کے "مطلب" کی نمائندگی کرتا ہے جو ہم چاہتے ہیں کہ ہمارے عفریت کو حاصل ہو۔ آئیے ہر عفریت کے اسکور کو تفصیل سے توڑتے ہیں:

ہمارے دوسرے اور تیسرے نتائج، Luminoth اور Living Graffiti، دونوں مطلوبہ تینوں خصوصیات کے مالک ہیں۔ سرفہرست نتیجہ، Whispering Shade، اگرچہ یہ روشنی کی ہیرا پھیری کے معاملے میں کم متعلقہ ہے - جیسا کہ اس کے behavior اسکور (0.006) سے ظاہر ہوتا ہے، اس میں "چمکتی ہوئی" خصوصیات اور ایک تاریک ماحول ہے جو اس کی look (0.168) اور habitat (0.203) اسکور کو بہت زیادہ بناتا ہے۔ اعلی، اسے سب سے زیادہ کل سکور (0.377) دیتا ہے، جو اسے مجموعی طور پر سب سے زیادہ متعلقہ عفریت بناتا ہے۔ کیا بہتری ہے!

کیا ہم اپنے نتائج کو نقل کر سکتے ہیں؟ آئیے ایک اور استفسار کرنے کی کوشش کریں اور معلوم کریں۔

 query = { 'look': 'shapeshifting', 'habitat': 'varied landscapes', 'behavior': 'illusion creation' }

بہت اچھا! ہمارے نتائج ایک بار پھر بہترین ہیں۔

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

 app.query( monster_query.with_vector(monster, "Harmonic Coral"), **default_weights, limit=LIMIT )

سب سے اوپر نتیجہ سب سے زیادہ متعلقہ ہے، ہارمونک کورل خود، جیسا کہ توقع کی گئی ہے۔ دیگر دو عفریت جو ہماری تلاش سے حاصل ہوئے ہیں وہ ہیں Dreamweaver Octopus اور Aqua Wraith۔ دونوں ہارمونک کورل کے ساتھ اہم موضوعاتی ( انتساب ) عناصر کا اشتراک کرتے ہیں:

1. آبی رہائش گاہیں ( habitat )
2. ان کے ماحول پر اثر انداز ہونے یا اس میں ہیرا پھیری کرنے کی صلاحیت ( behavior )
3. متحرک یا سیال بصری خصوصیات ( look )

وصف وزن

فرض کریں، اب، کہ ہم look وصف کو زیادہ اہمیت دینا چاہتے ہیں۔ سپر لنکڈ فریم ورک ہمیں استفسار کے وقت وزن کو آسانی سے ایڈجسٹ کرنے دیتا ہے۔ آسان موازنہ کے لیے، ہم ہارمونک کورل سے ملتے جلتے راکشسوں کی تلاش کریں گے، لیکن اپنے وزن کو موافق look کے ساتھ۔

 weights = { "look_weight": 1.0, "habitat_weight": 0, "behavior_weight": 0 } app.query( monster_query.with_vector(monster, "Harmonic Coral"), limit=LIMIT, **weights )

ہمارے تمام نتائج (مناسب طور پر) ایک جیسے ہوتے ہیں - "ہلتے ہوئے ٹینڈرلز کے ساتھ شاخیں"، "مڑی ہوئی بیلوں اور کانٹوں کے جسم کے ساتھ پودوں کی طرح کی جاندار"، "سانپ کی طرح"۔

اب، آئیے ایک اور تلاش کرتے ہیں، ظاہری شکل کو نظر انداز کرتے ہوئے، اور اس کے بجائے ایسے راکشسوں کی تلاش کرتے ہیں جو بیک وقت habitat اور behavior کے لحاظ سے ایک جیسے ہوتے ہیں:

 weights = { "look_weight": 0, "habitat_weight": 1.0, "behavior_weight": 1.0 }

ایک بار پھر، Superlinked اپروچ بہت اچھے نتائج پیدا کرتا ہے۔ تینوں راکشس پانی والے ماحول میں رہتے ہیں اور دماغ پر قابو پانے کی صلاحیتوں کے مالک ہیں۔

آخر میں، آئیے ایک اور تلاش کرنے کی کوشش کرتے ہیں، تینوں صفات کو مختلف طریقے سے وزن کرتے ہوئے - ایسے راکشسوں کو تلاش کرنے کے لیے جو ہارمونک کورل کے مقابلے میں کچھ ملتے جلتے نظر آتے ہیں، بہت مختلف رہائش گاہوں میں رہتے ہیں، اور بہت ملتے جلتے سلوک کے مالک ہیں:

 weights = { "look_weight": 0.5, "habitat_weight": -1.0, "behavior_weight": 1.0 }

ایک بار پھر عظیم نتائج! ہمارے دو دیگر بازیافت شدہ راکشس - Luminoth اور Zephyr Dancer - ہارمونک کورل کی طرح برتاؤ رکھتے ہیں اور ہارمونک کورل سے مختلف رہائش گاہوں میں رہتے ہیں۔ وہ ہارمونک کورل سے بھی بہت مختلف نظر آتے ہیں۔ (جبکہ ہارمونک کورل کے ٹینڈرلز اور لومینوتھ کا اینٹینا کچھ اسی طرح کی خصوصیات ہیں، ہم نے صرف look_weight وزن کو 0.5 تک کم کیا، اور دونوں راکشسوں کے درمیان مماثلت وہیں ختم ہو جاتی ہے۔)

آئیے دیکھتے ہیں کہ انفرادی صفات کے لحاظ سے ان راکشسوں کے مجموعی اسکور کیسے نکلتے ہیں:

habitat_weight (-1.0) کو منفی طور پر وزن دے کر، ہم جان بوجھ کر اسی طرح کے مسکن والے راکشسوں کو "دور دھکیلتے" ہیں اور اس کی بجائے سطحی راکشسوں کو جن کے ماحول ہارمونک کورل سے مختلف ہیں - جیسا کہ Luminoth's اور Zephyr Dancer کے منفی habitat اسکور میں دیکھا گیا ہے۔ Luminoth's اور Zephyr Dancer کے behavior اسکور نسبتاً زیادہ ہیں، جو ہارمونک کورل سے ان کے رویے کی مماثلت کی نشاندہی کرتے ہیں۔ ان کے look کے اسکور مثبت لیکن کم ہیں، جو ہارمونک کورل سے کچھ لیکن انتہائی بصری مماثلت کی عکاسی کرتے ہیں۔

مختصراً، habitat_weight کو -1.0 تک اور look_weight 0.5 تک کم کرنے کی ہماری حکمت عملی لیکن behavior_weight 1.0 پر رکھنے کی حکمت عملی ایسے راکشسوں کو سرفیس کرنے میں کارگر ثابت ہوتی ہے جو ہارمونک کورل کے ساتھ کلیدی طرز عمل کی خصوصیات کا اشتراک کرتے ہیں لیکن ان کا ماحول بہت مختلف ہے اور کم از کم کچھ مختلف نظر آتے ہیں۔

نتیجہ

ملٹی ایٹریبیوٹ ویکٹر کی تلاش معلومات کی بازیافت میں ایک اہم پیشرفت ہے، جو بنیادی معنوی مماثلت کی تلاش کے مقابلے میں زیادہ درستگی، سیاق و سباق کی تفہیم اور لچک پیش کرتی ہے۔ پھر بھی، ہمارا سادہ طریقہ (اوپر) - انتساب ویکٹرز کو الگ سے ذخیرہ کرنا اور تلاش کرنا، پھر نتائج کو یکجا کرنا - قابلیت، باریک بینی اور کارکردگی میں محدود ہے جب ہمیں ایک ساتھ متعدد صفات کے ساتھ اشیاء کو بازیافت کرنے کی ضرورت ہوتی ہے۔ (مزید برآں، متعدد kNN تلاشوں میں مربوط ویکٹر کے ساتھ ایک ہی تلاش سے زیادہ وقت لگتا ہے۔)

اس طرح کے منظرناموں کو ہینڈل کرنے کے لیے، یہ بہتر ہے کہ اپنے تمام ویکٹر ویکٹرز کو ایک ہی ویکٹر اسٹور میں اسٹور کریں اور ایک ہی تلاش کریں، استفسار کے وقت اپنے اوصاف کو وزن دیں۔ سپر لنکڈ اپروچ کسی بھی ایپلیکیشن کے لیے سادہ طریقہ سے زیادہ درست، موثر اور توسیع پذیر ہے جس کے لیے تیز، قابل بھروسہ، باریک بینی، ملٹی ایٹریبیوٹ ویکٹر بازیافت کی ضرورت ہوتی ہے - چاہے آپ کے استعمال کا معاملہ آپ کے ای کامرس میں حقیقی دنیا کے ڈیٹا چیلنجوں سے نمٹ رہا ہو یا سفارشی نظام۔ ... یا کچھ بالکل مختلف، جیسے راکشسوں سے لڑنا۔

تعاون کرنے والے

• اینڈری پیکونوف، مصنف
• Mór Kapronczay، ایڈیٹر