شکار هیولاهای انقلابی: برخوردهای D&D با هوش مصنوعی

ارتش تاریکی با هوش مصنوعی

شب بازی است، دوستان شما دور میز بازی نشسته‌اند و منتظرند ببینند چه شخصیتی از Dungeons & Dragons (D&D) خواهند شد و به دنبال آن تلاش خواهند کرد. امشب، شما استاد سیاه چال (داستان نویس و راهنما) هستید، طراح برخوردهای هیجان انگیز برای به چالش کشیدن و مجذوب کردن بازیکنان خود. راهنمای مطمئن D&D Monster شما حاوی هزاران موجود است. یافتن هیولای عالی برای هر موقعیتی در میان گزینه های بی شمار می تواند بسیار دشوار باشد. دشمن ایده آل باید با محیط، دشواری و روایت لحظه مطابقت داشته باشد.

اگر بتوانیم ابزاری بسازیم که فورا هیولایی را که برای هر سناریو مناسب‌تر است را بیابد؟ ابزاری که چندین عامل را به طور همزمان در نظر می گیرد و اطمینان می دهد که هر برخورد تا حد امکان غوطه ور و هیجان انگیز است؟

بیایید تلاش خودمان را آغاز کنیم: با استفاده از قدرت جستجوی برداری چند ویژگی، سیستم نهایی هیولا یاب را بسازیم!

ایجاد موجودات با جستجوی برداری، چرا این کار را انجام دهیم؟

جستجوی برداری نشان دهنده یک انقلاب در بازیابی اطلاعات است. جاسازی برداری - با در نظر گرفتن زمینه و معنای معنایی - جستجوی برداری را برای بازگرداندن نتایج مرتبط تر و دقیق تر، مدیریت نه تنها داده های ساختاریافته، بلکه بدون ساختار و چندین زبان و مقیاس، توانمند می سازد. اما برای تولید پاسخ‌های با کیفیت بالا در برنامه‌های کاربردی دنیای واقعی، ما اغلب نیاز داریم که وزن‌های متفاوتی را به ویژگی‌های خاص اشیاء داده خود اختصاص دهیم.

دو رویکرد رایج برای جستجوی برداری چند ویژگی وجود دارد. هر دو با تعبیه جداگانه هر ویژگی یک شی داده شروع می شوند. تفاوت اصلی بین این دو رویکرد در نحوه ذخیره و جستجوی تعبیه‌های ما است.

1. رویکرد ساده لوحانه - هر بردار ویژگی را در فروشگاه های برداری جداگانه (یکی برای هر ویژگی) ذخیره کنید، جستجوی جداگانه برای هر ویژگی انجام دهید، نتایج جستجو را ترکیب کنید، و پس از پردازش (به عنوان مثال وزن) در صورت لزوم.
2. رویکرد Superlinked - همه بردارهای مشخصه را در یک ذخیره برداری (با استفاده از عملکرد داخلی Superlinked) به هم متصل کرده و ذخیره می کند، که به ما امکان می دهد فقط یک بار جستجو کنیم ، با افزایش کارایی همراه. spaces Superlinked همچنین به ما اجازه می دهند تا هر ویژگی را در زمان پرس و جو وزن کنیم تا نتایج مرتبط تری را بدون هیچ پس پردازشی نشان دهیم.

در زیر، ما از این دو رویکرد برای پیاده سازی یک ابزار جستجوی برداری چند ویژگی استفاده خواهیم کرد - یاب هیولاهای Dungeons and 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 غیر قطعی است، بنابراین نتایج شما ممکن است متفاوت باشد.

اینها پنج هیولای اول ما هستند:

... و پرس و جوهای تولید شده ما:

مجموعه داده اصلی و نمونه های پرس و جو را اینجا ببینید.

بازیابی

بیایید پارامترهایی را تنظیم کنیم که در هر دو رویکردمان - ساده‌لوحانه و Superlinked - در زیر استفاده خواهیم کرد.

ما جاسازی های برداری خود را با استفاده از:

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

برای سادگی، خروجی خود را به 3 مسابقه برتر محدود می کنیم. (برای کد کامل، از جمله واردات ضروری و توابع کمکی، به دفترچه یادداشت مراجعه کنید.)

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

اکنون، بیایید جستجوی هیولای چند ویژگی خود را آغاز کنیم! اول، ما رویکرد ساده لوحانه را امتحان خواهیم کرد.

رویکرد ساده لوحانه

در رویکرد ساده لوحانه خود، ویژگی ها را به طور مستقل جاسازی می کنیم و آنها را در شاخص های مختلف ذخیره می کنیم. در زمان پرس و جو، چندین جستجوی kNN را روی همه شاخص ها اجرا می کنیم، و سپس تمام نتایج جزئی خود را در یک ترکیب می کنیم.

با تعریف کلاس شروع می کنیم

 NaiveRetriever

برای انجام جستجوی مبتنی بر شباهت در مجموعه داده ما، با استفاده از جاسازی‌های تولید شده توسط all-mpnet-base-v2 .

 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 : سه هیولا (Whispering Shade، Sandstorm Djinn و Luminoth) بازیابی شدند.
   • habitat : فقط یک هیولا از نتایج look مرتبط بود (Whispering Shade).
   • behavior : فقط یک هیولا از نتایج look مرتبط بود (Luminoth)، اما با هیولای مربوط به habitat متفاوت است.
2. ارتباط کلی:
   • هیچ هیولایی برای هر سه ویژگی به طور همزمان بازیابی نشد.
   • نتایج تکه تکه هستند: هیولاهای مختلف برای ویژگی های مختلف مرتبط هستند.

به طور خلاصه، رویکرد جستجوی ساده لوحانه نمی تواند هیولاهایی را بیابد که همه معیارها را به یکباره برآورده کنند. شاید بتوانیم این مشکل را با بازیابی فعالانه هیولاهای بیشتری برای هر ویژگی برطرف کنیم؟ بیایید آن را با 6 هیولا در هر ویژگی امتحان کنیم، به جای 3. بیایید نگاهی بیندازیم که این رویکرد چه چیزی ایجاد می کند:

ما اکنون 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 )

et voila! این بار، هر یک از هیولاهای برتر ما در امتیازی که نشان دهنده نوعی «متوسط» از هر سه ویژگی است که می‌خواهیم هیولایمان داشته باشد، رتبه بالایی کسب می‌کند. بیایید امتیاز هر هیولا را با جزئیات بشکنیم:

نتایج دوم و سوم ما، 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 اهمیت بیشتری بدهیم. چارچوب Superlinked به ما امکان می دهد به راحتی وزن ها را در زمان پرس و جو تنظیم کنیم. برای مقایسه آسان، ما هیولاهایی شبیه به هارمونیک مرجانی را جستجو می کنیم، اما با وزن هایمان که به نفع 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)، ما عمداً هیولاهایی را با زیستگاه‌های مشابه «دور می‌کنیم» و در عوض هیولاهای سطحی که محیط‌هایشان با هارمونیک کورال متفاوت است - همانطور که در امتیازات habitat منفی Luminoth و Zephyr Dancer دیده می‌شود. نمرات behavior Luminoth و Zephyr Dancer نسبتاً بالا است که نشان دهنده شباهت رفتاری آنها به هارمونیک کورال است. نمرات look آنها مثبت است اما پایین تر است، که نشان دهنده شباهت بصری کمی اما نه شدید به هارمونیک کورال است.

به طور خلاصه، استراتژی ما برای کاهش وزن habitat_weight به -1.0 و look_weight به 0.5 اما نگه داشتن behavior_weight در 1.0 در رویارویی با هیولاهایی که ویژگی های رفتاری کلیدی با هارمونیک کورال دارند، اما محیط های بسیار متفاوتی دارند و حداقل تا حدودی متفاوت به نظر می رسند، موثر است.

نتیجه گیری

جستجوی برداری چند ویژگی پیشرفت قابل توجهی در بازیابی اطلاعات است که نسبت به جستجوی تشابه معنایی اولیه، دقت، درک زمینه‌ای و انعطاف‌پذیری بیشتری ارائه می‌دهد. با این حال، رویکرد ساده لوحانه ما (در بالا) - ذخیره و جستجوی بردارهای ویژگی به طور جداگانه، سپس ترکیب نتایج - زمانی که نیاز به بازیابی اشیا با چندین ویژگی همزمان داریم، از نظر توانایی، ظرافت و کارایی محدود است. (علاوه بر این، چندین جستجوی kNN نسبت به یک جستجوی منفرد با بردارهای پیوسته زمان بیشتری می برد.)

برای رسیدگی به سناریوهایی مانند این، بهتر است همه بردارهای ویژگی خود را در یک ذخیره برداری ذخیره کنید و یک جستجو انجام دهید و ویژگی های خود را در زمان پرس و جو وزن کنید. رویکرد Superlinked دقیق‌تر، کارآمدتر و مقیاس‌پذیرتر از رویکرد ساده‌لوحانه برای هر برنامه‌ای است که به بازیابی سریع، قابل اعتماد، ظریف و چند ویژگی نیاز دارد - چه مورد استفاده شما در حال مقابله با چالش‌های داده‌های دنیای واقعی در تجارت الکترونیک یا سیستم توصیه شما باشد. ... یا چیزی کاملاً متفاوت، مانند مبارزه با هیولاها.

مشارکت کنندگان

• آندری پیکونوف، نویسنده
• مور کاپرونچای، ویراستار