क्रान्तिकारी मोन्स्टर हन्टहरू: एआई-एन्हान्स्ड डी एन्काउन्टरहरू

अन्धकारको एआई-संचालित सेना

यो खेलको रात हो, तपाईंका साथीहरू खेल तालिकाको वरिपरि बसेका छन्, तिनीहरू कुन डन्जियन्स एण्ड ड्र्यागन (डी एन्ड डी) क्यारेक्टर बन्नेछन् र खोजीमा लाग्नेछन् भनेर पर्खिरहेका छन्। आज राति, तपाईं डन्जियन मास्टर (कथाकार र गाइड), तपाईंका खेलाडीहरूलाई चुनौती दिन र मोहित पार्न रोमाञ्चक मुठभेडहरूको शिल्पकार हुनुहुन्छ। तपाईंको भरपर्दो D&D Monster Manual मा हजारौं जीवहरू छन्। असंख्य विकल्पहरू बीच प्रत्येक अवस्थाको लागि उत्तम राक्षस खोज्नु भारी हुन सक्छ। आदर्श शत्रुले पलको सेटिङ, कठिनाई र कथासँग मेल खानुपर्छ।

के हुन्छ यदि हामीले एउटा उपकरण सिर्जना गर्न सक्छौं जसले तुरुन्तै प्रत्येक परिदृश्यमा सबैभन्दा उपयुक्त राक्षस फेला पार्छ? एक उपकरण जसले एकै साथ धेरै कारकहरू विचार गर्दछ , प्रत्येक मुठभेड सम्भव भएसम्म इमर्सिभ र रोमाञ्चक छ भनेर सुनिश्चित गर्दै?

हाम्रो आफ्नै खोजमा लागौं: बहु-विशेषता भेक्टर खोजको शक्ति प्रयोग गरेर, अन्तिम राक्षस-खोज प्रणाली निर्माण गर्नुहोस्!

भेक्टर खोजको साथ जीवहरू सिर्जना गर्दै, यो किन?

भेक्टर खोज जानकारी पुन: प्राप्ति मा एक क्रान्ति को प्रतिनिधित्व गर्दछ। भेक्टर इम्बेडिङ - सन्दर्भ र सिमान्टिक अर्थलाई ध्यानमा राखेर - भेक्टर खोजलाई थप सान्दर्भिक र सही नतिजाहरू फर्काउन, संरचित मात्र होइन असंरचित डेटा र बहु भाषाहरू, र स्केल ह्यान्डल गर्न सशक्त बनाउँछ। तर वास्तविक-विश्व अनुप्रयोगहरूमा उच्च गुणस्तर प्रतिक्रियाहरू उत्पन्न गर्न, हामीले प्रायः हाम्रा डेटा वस्तुहरूको विशिष्ट विशेषताहरूमा विभिन्न वजनहरू तोक्न आवश्यक हुन्छ।

बहु-विशेषता भेक्टर खोजमा दुई साझा दृष्टिकोणहरू छन्। दुबै डेटा वस्तुको प्रत्येक विशेषतालाई अलग-अलग इम्बेड गरेर सुरु हुन्छ। यी दुई दृष्टिकोणहरू बीचको मुख्य भिन्नता हाम्रो इम्बेडिङहरू कसरी भण्डारण र खोजी गरिन्छ ।

1. सरल दृष्टिकोण - प्रत्येक विशेषता भेक्टरलाई छुट्टै भेक्टर स्टोरहरूमा भण्डार गर्नुहोस् (एक प्रति विशेषता), प्रत्येक विशेषताको लागि छुट्टै खोजी गर्नुहोस्, खोज परिणामहरू संयोजन गर्नुहोस्, र पोस्ट-प्रक्रिया (जस्तै, वजन) आवश्यकता अनुसार।
2. सुपरलिंक गरिएको दृष्टिकोण - एउटै भेक्टर स्टोरमा सबै एट्रिब्युट भेक्टरहरू जोड्नुहोस् र भण्डार गर्नुहोस् (सुपरलिङ्कको बिल्ट-इन फंक्शनलिटी प्रयोग गरेर), जसले हामीलाई परिचर दक्षता लाभहरूको साथ, एक पटक मात्र खोज्न अनुमति दिन्छ। Superlinked को spaces हामीलाई कुनै पोस्ट-प्रोसेसिङ बिना, थप सान्दर्भिक परिणामहरू सतह गर्न क्वेरी समयमा प्रत्येक विशेषतालाई वजन दिन्छ।

बहु-विशेषता भेक्टर खोजमा दुई दृष्टिकोणहरू

तल, हामी बहु-विशेषता भेक्टर खोज उपकरण लागू गर्न यी दुई दृष्टिकोणहरू प्रयोग गर्नेछौं - एक Dungeons र Dragons राक्षस खोजकर्ता! हाम्रा साधारण कार्यान्वयनहरू, विशेष गरी दोस्रोले, कसरी थप शक्तिशाली र लचिलो खोज प्रणालीहरू सिर्जना गर्ने भनेर चित्रण गर्नेछ, जुन जटिल, बहु-आयामी प्रश्नहरू सजिलैसँग ह्यान्डल गर्न सक्छ, तपाईंको प्रयोगमा जेसुकै भए पनि।

यदि तपाईं भेक्टर समानता खोजमा नयाँ हुनुहुन्छ भने, चिन्ता नगर्नुहोस्! हामीले तपाइँलाई कभर गरेका छौं - हाम्रो निर्माण ब्लक लेखहरू हेर्नुहोस्।

ठीक छ, राक्षस शिकार गरौं!

डाटासेट

पहिले, हामी ठूलो भाषा मोडेल (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 को प्रयोग गरेर हाम्रो dataset मा समानता-आधारित खोज गर्न।

 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 नतिजाबाट एउटा मात्र राक्षस सान्दर्भिक थियो (लुमिनोथ), तर यो habitat लागि सान्दर्भिक भन्दा फरक छ।
2. समग्र सान्दर्भिकता:
   • कुनै एकल राक्षस एकै साथ सबै तीन विशेषताहरूको लागि पुन: प्राप्त गरिएको थिएन।
   • परिणामहरू खण्डित छन्: विभिन्न राक्षसहरू विभिन्न विशेषताहरूको लागि सान्दर्भिक छन्।

छोटकरीमा, भोली खोजी दृष्टिकोणले एकैचोटि सबै मापदण्डहरू पूरा गर्ने राक्षसहरू फेला पार्न असफल हुन्छ। हुनसक्छ हामी सक्रिय रूपमा प्रत्येक विशेषताको लागि थप राक्षसहरू पुन: प्राप्त गरेर यो समस्या समाधान गर्न सक्छौं? 3 को सट्टा, 6 monsters प्रति विशेषता संग प्रयास गरौं। यस दृष्टिकोणले के उत्पन्न गर्छ भनेर हेरौं:

हामीले अब 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 )

र भोइला! यस पटक, हाम्रा प्रत्येक शीर्ष फिर्ता भएका राक्षसहरू स्कोरमा उच्च स्थानमा छन् जुन हामी हाम्रो राक्षससँग भएको तीनवटा विशेषताहरूको एक प्रकारको "मीन" प्रतिनिधित्व गर्दछ। प्रत्येक राक्षसको स्कोरलाई विस्तृत रूपमा तोडौं:

हाम्रो दोस्रो र तेस्रो नतिजाहरू, लुमिनोथ र लिभिङ ग्राफिटी, दुबैमा तीनवटै वांछित विशेषताहरू छन्। शीर्ष परिणाम, व्हिस्परिङ शेड, यद्यपि यो प्रकाश हेरफेरको सन्दर्भमा कम सान्दर्भिक छ - यसको behavior स्कोर (0.006) मा प्रतिबिम्बित रूपमा, "चमकाउने" सुविधाहरू र एक अँध्यारो वातावरण छ जसले यसको look (0.168) र habitat (0.203) स्कोरहरू धेरै बनाउँछ। उच्च, यसलाई उच्चतम कुल स्कोर (०.३७७) प्रदान गर्दै, यसलाई समग्रमा सबैभन्दा सान्दर्भिक राक्षस बनाउँदै। कस्तो सुधार!

के हामी हाम्रो नतिजा दोहोर्याउन सक्छौं? अर्को प्रश्न प्रयास गरौं र पत्ता लगाउनुहोस्।

 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 अक्टोपस र 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 }

महान परिणाम फेरि! हाम्रा दुई अन्य पुनःप्राप्त राक्षसहरू - लुमिनोथ र जेफिर डान्सर - हार्मोनिक कोरल जस्तै व्यवहार गर्छन् र हार्मोनिक कोरल भन्दा फरक बासस्थानमा बस्छन्। तिनीहरू हार्मोनिक कोरल भन्दा धेरै फरक देखिन्छन्। (हार्मोनिक कोरलको टेन्ड्रिलहरू र लुमिनोथको एन्टेना केही हदसम्म समान विशेषताहरू भए तापनि, हामीले look_weight ०.५ ले मात्र घटाउँछौं, र दुई राक्षसहरू बीचको समानता त्यहाँ समाप्त हुन्छ।)

यी राक्षसहरूको समग्र स्कोर व्यक्तिगत विशेषताहरूको सन्दर्भमा कसरी बाहिर आउँछ हेरौं:

habitat_weight (-१.०) लाई नकारात्मक तौल गरेर, हामी जानाजानी समान बासस्थान भएका राक्षसहरूलाई "दूर धकेल्छौं" र यसको सट्टा हार्मोनिक कोरलहरू भन्दा फरक सतहका राक्षसहरू - लुमिनोथ र जेफिर डान्सरको नकारात्मक habitat स्कोरहरूमा देखिएझैं। Luminoth's र Zephyr Dancer को behavior स्कोर अपेक्षाकृत उच्च छ, Harmonic Coral को व्यवहार समानता को संकेत गर्दछ। तिनीहरूको look स्कोरहरू सकारात्मक तर कम छन्, केही तर हार्मोनिक कोरलसँग चरम दृश्य समानतालाई प्रतिबिम्बित गर्दछ।

छोटकरीमा भन्नुपर्दा, हार्मोनिक कोरलसँग मुख्य व्यवहारिक विशेषताहरू साझा गर्ने तर धेरै फरक वातावरण भएका र कम्तिमा पनि फरक देखिने राक्षसहरूलाई सर्फेसिङमा प्रभावकारी साबित गर्छ तर habitat_weight -१.० मा र look_weight ०.५ मा कम behavior_weight हाम्रो रणनीति।

निष्कर्ष

बहु-विशेषता भेक्टर खोज जानकारी पुन: प्राप्ति मा एक महत्वपूर्ण अग्रिम, अधिक सटीकता, प्रासंगिक समझ, र आधारभूत अर्थ समानता खोज भन्दा लचिलोपन प्रदान गर्दछ। अझै पनि, हाम्रो सरल दृष्टिकोण (माथि) - एट्रिब्यूट भेक्टरहरूलाई अलग-अलग भण्डारण गर्ने र खोजी गर्ने, त्यसपछि परिणामहरू संयोजन गर्ने - क्षमता, सूक्ष्मता र दक्षतामा सीमित हुन्छ जब हामीले बहुविध विशेषताहरूसँग वस्तुहरू पुन: प्राप्त गर्न आवश्यक हुन्छ। (यसबाहेक, धेरै kNN खोजहरूले एकल खोजी भन्दा बढी समय लिन्छ एकल भेक्टरहरूसँग।)

यस प्रकारका परिदृश्यहरू ह्यान्डल गर्नका लागि, तपाइँका सबै विशेषता भेक्टरहरूलाई एउटै भेक्टर स्टोरमा भण्डारण गर्न र एकल खोज प्रदर्शन गर्न, तपाइँका विशेषताहरूलाई क्वेरी समयमा वजन गर्ने राम्रो हुन्छ। सुपरलिंक गरिएको दृष्टिकोण छिटो, भरपर्दो, सूक्ष्म, बहु-विशेषता भेक्टर पुन: प्राप्तिको आवश्यकता पर्ने कुनै पनि अनुप्रयोगको लागि सरल दृष्टिकोण भन्दा बढी सटीक, प्रभावकारी र मापनयोग्य छ - तपाईंको प्रयोग केसले तपाईंको ई-वाणिज्य वा सिफारिस प्रणालीमा वास्तविक विश्व डेटा चुनौतीहरूको सामना गरिरहेको छ। ... वा केहि पुरा तरिकाले फरक, जस्तै लडाई राक्षसहरु।

योगदानकर्ताहरू

• Andrey Pikunov, लेखक
• Mór Kapronczay, सम्पादक