5 হার্ড ভেক্টর অনুসন্ধান সমস্যা এবং কিভাবে আমরা Apache Cassandra এ তাদের সমাধান করেছি

ভেক্টর অনুসন্ধান জেনারেটিভ এআই টুলিংয়ের একটি গুরুত্বপূর্ণ উপাদান কারণ পুনরুদ্ধার অগমেন্টেড জেনারেশন (RAG) কীভাবে পছন্দ করে ফ্লেয়ার হ্যালুসিনেশন এড়ানোর সময় এলএলএমগুলিকে আপ-টু-ডেট, কাস্টমাইজড তথ্য অন্তর্ভুক্ত করতে সাহায্য করে . একই সময়ে, ভেক্টর অনুসন্ধান একটি বৈশিষ্ট্য, একটি পণ্য নয় - আপনাকে ভেক্টরগুলিকে জিজ্ঞাসা করতে হবে কারণ সেগুলি আপনার বাকি ডেটার সাথে সম্পর্কিত, বিচ্ছিন্নভাবে নয়, এবং আপনার বাকিগুলি সিঙ্ক করার জন্য আপনাকে একটি পাইপলাইন তৈরি করতে হবে না এটি করার জন্য একটি ভেক্টর স্টোরের সাথে ডেটা।

2023 ভেক্টর অনুসন্ধান পণ্য এবং প্রকল্পগুলিতে একটি বিস্ফোরণ দেখেছে, তাদের মধ্যে নির্বাচন করা একটি গুরুতর প্রচেষ্টা করে তুলেছে। আপনি বিকল্পগুলি নিয়ে গবেষণা করার সাথে সাথে আপনাকে নিম্নলিখিত কঠিন সমস্যাগুলি এবং সেগুলি সমাধানের বিভিন্ন পদ্ধতি বিবেচনা করতে হবে৷ এখানে, আমি আপনাকে এই চ্যালেঞ্জগুলির মধ্য দিয়ে হেঁটে যাবো এবং বর্ণনা করব কিভাবে DataStax Astra DB এবং Apache Cassandra-এর জন্য আমাদের ভেক্টর অনুসন্ধান বাস্তবায়নের জন্য DataStax তাদের মোকাবেলা করেছে।

বিষয়বস্তু ওভারভিউ

• মাত্রিকতার অভিশাপ
• সমস্যা 1: স্কেল-আউট
• সমস্যা 2: দক্ষ আবর্জনা সংগ্রহ
• সাইডবার: ক্লাউড অ্যাপ্লিকেশন ওয়ার্কলোড
• সমস্যা 3: সামঞ্জস্য
• সমস্যা 4: ডিস্কের কার্যকর ব্যবহার
• সমস্যা 5: সংমিশ্রণযোগ্যতা
• শেষ করি

মাত্রিকতার অভিশাপ

এই কঠিন সমস্যার মূলে রয়েছে গবেষকরা যাকে বলে " মাত্রিকতার অভিশাপ " অনুশীলনে এর অর্থ হল যে অ্যালগরিদমগুলি 2-ডি বা 3-ডি স্পেসে সঠিক ভেক্টর অনুসন্ধানের জন্য কাজ করে, যেমন kd গাছ , যখন আপনি আপনার ভেক্টরে 10s বা 100s বা 1000s মাত্রায় পৌঁছান তখন আলাদা হয়ে যান। ফলাফল হল উচ্চ-মাত্রিক ভেক্টরের সাথে সঠিক মিল অনুসন্ধানের জন্য কোন শর্টকাট নেই; লগারিদমিক-টাইম ফলাফল পেতে, আমাদের আনুমানিক নিকটতম প্রতিবেশী (ANN) অ্যালগরিদম ব্যবহার করতে হবে, যা তাদের সাথে নিম্নলিখিত ক্ষেত্রে চ্যালেঞ্জ নিয়ে আসে।

সমস্যা 1: স্কেল-আউট

অনেক ভেক্টর অনুসন্ধান অ্যালগরিদম একটি একক মেশিনে মেমরিতে ফিট করা ডেটাসেটের জন্য ডিজাইন করা হয়েছিল এবং এটি এখনও একমাত্র দৃশ্য ann-বেঞ্চমার্ক . (অ্যান-বেঞ্চমার্কগুলি আরও একটি একক কোরে এর পরীক্ষাকে সীমাবদ্ধ করে!) এটি এক মিলিয়ন নথি বা সারির একাডেমিক কাজের জন্য ঠিক হতে পারে, তবে এটি বাস্তব-বিশ্ব কাজের চাপের প্রতিনিধি হিসাবে বিবেচিত হতে অনেক বছর হয়ে গেছে।

অন্য যেকোনো ডোমেনের মতো, স্কেল-আউটের জন্য প্রতিলিপি এবং পার্টিশন উভয়ই প্রয়োজন, সেইসাথে মৃত প্রতিলিপিগুলি প্রতিস্থাপন, নেটওয়ার্ক পার্টিশনের পরে সেগুলি মেরামত করা এবং আরও অনেক কিছু পরিচালনা করার জন্য সাবসিস্টেম প্রয়োজন।

এটি আমাদের জন্য একটি সহজ ছিল: স্কেল-আউট প্রতিলিপি হল ক্যাসান্দ্রার রুটি এবং মাখন, এবং এটিকে নতুন-ইন-ক্যাসান্ড্রা-5.0 SAI (স্টোরেজ-সংযুক্ত সূচক – দেখুন সিইপি-7 এটি কিভাবে কাজ করে, এবং SAI ডকুমেন্টেশন কিভাবে এটি ব্যবহার করতে হয়) আমাদের ভেক্টর অনুসন্ধান বাস্তবায়ন শক্তিশালী স্কেল-আউট ক্ষমতা কার্যকরভাবে বিনামূল্যে দিয়েছে।

সমস্যা 2: দক্ষ আবর্জনা সংগ্রহ

"আবর্জনা সংগ্রহ" দ্বারা, আমি সূচী থেকে অপ্রচলিত তথ্য মুছে ফেলার অর্থ - মুছে ফেলা সারিগুলি পরিষ্কার করা এবং সারিগুলির সাথে কাজ করা যার সূচীকৃত ভেক্টর মান পরিবর্তিত হয়েছে৷ এটি উল্লেখ করার মতো মনে হতে পারে না - এটি রিলেশনাল ডাটাবেস জগতে চল্লিশ বছর ধরে একটি কমবেশি সমাধান করা সমস্যা - তবে ভেক্টর সূচকগুলি অনন্য।

মূল সমস্যা হল যে সমস্ত অ্যালগরিদম যা আমরা জানি সেগুলি কম-বিলম্বিত অনুসন্ধান এবং উচ্চ-রিকল ফলাফল উভয়ই গ্রাফ-ভিত্তিক। অন্যান্য অনেক ভেক্টর ইনডেক্সিং অ্যালগরিদম উপলব্ধ রয়েছে - FAISS তাদের অনেকগুলিকে প্রয়োগ করে – কিন্তু সেগুলির সবগুলিই তৈরি করতে খুব ধীর, অনুসন্ধান করতে খুব ধীর, বা প্রত্যাহার অফার করে যা খুব কম (এবং কখনও কখনও তিনটিই!) একটি সাধারণ-উদ্দেশ্য সমাধান হতে পারে৷ এই কারণেই আমার জানা প্রতিটি প্রোডাকশন ভেক্টর ডাটাবেস একটি গ্রাফ-ভিত্তিক সূচক ব্যবহার করে, যার মধ্যে সবচেয়ে সহজ হল HNSW। হায়ারার্কিক্যাল নেভিগেবল স্মল ওয়ার্ল্ড গ্রাফ ছিল 2016 সালে ইউরি মালকভ এট আল দ্বারা প্রবর্তিত ; কাগজটি বেশ পঠনযোগ্য এবং আমি এটির সুপারিশ করছি। নীচে HNSW সম্পর্কে আরও।

গ্রাফ সূচীগুলির সাথে চ্যালেঞ্জ হল যে একটি সারি বা নথি পরিবর্তন হলে আপনি পুরানো (ভেক্টর-সম্পর্কিত) নোডটি ছিঁড়ে ফেলতে পারবেন না; যদি আপনি এটি কয়েকবার বেশি করেন, তাহলে আপনার গ্রাফটি আর BFS (প্রস্থ-প্রথম অনুসন্ধান) একটি কোয়েরি ভেক্টরের সাথে বৃহত্তর সাদৃশ্যপূর্ণ এলাকার দিকে নির্দেশ করার উদ্দেশ্য সম্পাদন করতে সক্ষম হবে না।

তাই এই আবর্জনা সংগ্রহ করার জন্য আপনাকে কিছু সময়ে আপনার সূচীগুলি পুনর্নির্মাণ করতে হবে, কিন্তু কখন-এবং কীভাবে-আপনি এটি সংগঠিত করবেন? পরিবর্তন করার সময় আপনি যদি সর্বদা সবকিছু পুনর্নির্মাণ করেন, তাহলে আপনি সম্পাদিত শারীরিক লেখাগুলি ব্যাপকভাবে বৃদ্ধি করবেন; একে রাইট এম্পলিফিকেশন বলা হয়। অন্যদিকে, আপনি যদি কখনও পুনর্নির্মাণ না করেন তবে আপনি অনুসন্ধানের সময় অপ্রচলিত সারিগুলি ফিল্টার করার জন্য অতিরিক্ত কাজ করবেন ("পড়ুন পরিবর্ধন")।

এটি আরেকটি সমস্যা স্থান যা ক্যাসান্দ্রা বছরের পর বছর ধরে কাজ করছে। যেহেতু SAI সূচকগুলি মূল স্টোরেজ লাইফসাইকেলের সাথে সংযুক্ত, তাই তারা ক্যাসান্দ্রাতেও অংশগ্রহণ করে কম্প্যাকশন , যা পঠন এবং লেখার মধ্যে একটি সুস্থ ভারসাম্য প্রদান করতে লগারিদমিকভাবে স্টোরেজ ইউনিটগুলিকে বৃদ্ধি করে।

সাইডবার: ক্লাউড অ্যাপ্লিকেশন ওয়ার্কলোড

DataStax Astra DB ক্লাউড অ্যাপ্লিকেশন ওয়ার্কলোডের জন্য একটি প্ল্যাটফর্ম প্রদান করতে Apache Cassandra-তে তৈরি করে।

এর মানে হল কাজের চাপ যা হল:

• প্রতি সেকেন্ডে হাজার হাজার থেকে লক্ষাধিক অনুরোধ, সাধারণত কয়েকটি সারি পুনরুদ্ধার করার জন্য। এই কারণে আপনি Snowflake-এ Netflix চালাতে পারেননি, এমনকি যদি আপনি এটি সামর্থ্য করতে পারেন: Snowflake এবং অনুরূপ বিশ্লেষণাত্মক সিস্টেমগুলি শুধুমাত্র কয়েকটি সমবর্তী অনুরোধগুলি পরিচালনা করার জন্য ডিজাইন করা হয়েছে যেগুলি প্রতিটি কয়েক সেকেন্ড থেকে মিনিট বা তারও বেশি সময় ধরে চলে৷

  
  

• মেমরির চেয়ে বড় যদি আপনার ডেটাসেট একটি একক মেশিনে মেমরিতে ফিট করে তবে আপনি কোন সরঞ্জামগুলি ব্যবহার করেন তা প্রায় বিবেচ্য নয়৷ Sqlite, MongoDB, MySQL - তারা সব ঠিকঠাক কাজ করবে। বিষয়গুলি আরও চ্যালেঞ্জিং হয়ে ওঠে যখন এটি হয় না - এবং খারাপ খবর হল যে ভেক্টর এম্বেডিংগুলি সাধারণত কয়েক KB হয়, বা সাধারণ ডাটাবেস নথির চেয়ে বড় আকারের অর্ডারের কাছাকাছি, তাই আপনি তুলনামূলকভাবে দ্রুত মেমরির চেয়ে বড় হয়ে যাবেন৷

  
  

• অ্যাপ্লিকেশানের মূল আপনি যদি আপনার ডেটা হারিয়ে ফেলেন তবে আপনি যত্ন না করেন, কারণ এটি তেমন গুরুত্বপূর্ণ নয় বা আপনি এটিকে রেকর্ডের প্রকৃত উত্স থেকে পুনর্নির্মাণ করতে পারেন, তাহলে আপনি কোন সরঞ্জামগুলি ব্যবহার করেন তাতে আবার কিছু যায় আসে না৷ Cassandra, এবং Astra DB-এর মতো ডেটাবেসগুলি আপনার ডেটা উপলভ্য এবং টেকসই রাখার জন্য তৈরি করা হয়েছে তা যাই হোক না কেন।

সমস্যা 3: সামঞ্জস্য

আমি উপরে উল্লেখ করেছি যে সুপরিচিত ann-বেঞ্চমার্ক তুলনা সমস্ত অ্যালগরিদমকে একটি একক কোরে সীমাবদ্ধ করে। যদিও এটি খেলার ক্ষেত্রকে স্তর দেয়, এটি তাদের প্রতিবন্ধী করে যারা গত দুই দশকে হার্ডওয়্যার উন্নতির প্রধান উত্সের সুবিধা নিতে পারে।

একটি সম্পর্কিত সমস্যা হল যে অ্যান-বেঞ্চমার্কগুলি একবারে শুধুমাত্র এক ধরণের অপারেশন করে: প্রথমে, এটি সূচক তৈরি করে, তারপরে এটি জিজ্ঞাসা করে। অনুসন্ধানের সাথে সংযুক্ত আপডেটগুলির সাথে মোকাবিলা করা ঐচ্ছিক - এবং সম্ভবত একটি প্রতিবন্ধকতাও; আপনি যদি জানেন যে আপনাকে আপডেটের সাথে মোকাবিলা করতে হবে না, আপনি অনেক সরলীকরণ অনুমান করতে পারেন যা কৃত্রিম মানদণ্ডে ভাল দেখায়।

আপনি যদি আপনার সূচকের সাথে একাধিক সমসাময়িক ক্রিয়াকলাপ করতে সক্ষম হন বা এটি তৈরি হওয়ার পরে এটি আপডেট করতে সক্ষম হন তবে এটি কীভাবে কাজ করে এবং কী ট্রেডঅফ জড়িত তা বোঝার জন্য আপনাকে আরও গভীরভাবে দেখতে হবে।

প্রথমত, সমস্ত সাধারণ-উদ্দেশ্য ভেক্টর ডাটাবেস যা আমি গ্রাফ-ভিত্তিক সূচী ব্যবহার সম্পর্কে জানি। কারণ প্রথম ভেক্টর সন্নিবেশিত হওয়ার সাথে সাথে আপনি একটি গ্রাফ সূচক অনুসন্ধান শুরু করতে পারেন। বেশিরভাগ অন্যান্য বিকল্পের জন্য আপনাকে অনুসন্ধান করার আগে সম্পূর্ণ সূচক তৈরি করতে হবে বা অন্তত কিছু পরিসংখ্যানগত বৈশিষ্ট্যগুলি শিখতে ডেটার একটি প্রাথমিক স্ক্যান করতে হবে।

যাইহোক, গ্রাফ সূচক বিভাগের মধ্যেও এখনও গুরুত্বপূর্ণ বাস্তবায়ন বিবরণ রয়েছে। উদাহরণস্বরূপ, আমরা প্রথমে ভেবেছিলাম যে আমরা লুসিনের HNSW সূচক বাস্তবায়ন ব্যবহার করে সময় বাঁচাতে পারি, যেভাবে MongoDB ইলাস্টিক এবং সোলার করে। কিন্তু আমরা দ্রুত শিখেছি যে লুসিন শুধুমাত্র একক-থ্রেডেড, অ-সমসাময়িক সূচক নির্মাণের প্রস্তাব দেয়। অর্থাত্, আপনি এটি তৈরি করা হওয়ার কারণে এটিকে জিজ্ঞাসা করতে পারবেন না (যা এই ডেটা কাঠামোটি ব্যবহার করার প্রাথমিক কারণগুলির মধ্যে একটি হওয়া উচিত!) বা একাধিক থ্রেডকে একই সাথে এটি তৈরি করার অনুমতি দিতে পারে না।

এইচএনএসডব্লিউ পেপার পরামর্শ দেয় যে একটি সূক্ষ্ম-দানাযুক্ত লকিং পদ্ধতি কাজ করতে পারে, তবে আমরা আরও ভাল হয়েছি এবং একটি নন-ব্লকিং সূচক তৈরি করেছি। এটি ওপেন সোর্স ইন JVector .

JVector অন্তত 32টি থ্রেডে রৈখিকভাবে সমবর্তী আপডেটগুলিকে স্কেল করে। এই গ্রাফটি x এবং y উভয় অক্ষে লগ-স্কেল করা হয়েছে, যা দেখায় যে থ্রেড গণনা দ্বিগুণ করা বিল্ড সময়কে অর্ধেক করে।

আরও গুরুত্বপূর্ণ, JVector-এর নন-ব্লকিং কনকারেন্সি আপডেটের সাথে অনুসন্ধানগুলিকে মিশ্রিত করে আরও বাস্তবসম্মত কাজের চাপকে উপকৃত করে। এখানে Astra DB-এর পারফরম্যান্সের (JVector ব্যবহার করে) বিভিন্ন ডেটাসেটের সাথে Pinecone-এর তুলনা করা হয়েছে। যদিও Astra DB একটি স্ট্যাটিক ডেটাসেটের জন্য Pinecone থেকে প্রায় 10% দ্রুত, এটি নতুন ডেটা ইন্ডেক্স করার সময় 8x থেকে 15x দ্রুত। আমরা উচ্চতর থ্রুপুট এবং কম লেটেন্সির জন্য তাদের সুপারিশের ভিত্তিতে পাইনেকোন (পড টাইপ: p2 এবং পড সাইজ: x8, প্রতি প্রতিলিপি 2 পড সহ) সহ সেরা উপলব্ধ পড টিয়ার বেছে নিয়েছি। পাইনকোন প্রকাশ করে না যে এটি কোন ভৌত সম্পদের সাথে সঙ্গতিপূর্ণ। Astra DB এর দিকে, আমরা ডিফল্ট PAYG স্থাপনার মডেলটি বেছে নিয়েছি এবং এটি সার্ভারহীন হওয়ায় সংস্থানগুলি বেছে নেওয়ার বিষয়ে চিন্তা করতে হবে না। ব্যবহার করে পরীক্ষা করা হয়েছিল NoSQLBench .

উচ্চতর স্মরণ এবং নির্ভুলতা বজায় রাখার সময় Astra DB এটি করে ( F1 হল রিকল এবং নির্ভুলতার সংমিশ্রণ ) :

সমস্যা 4: ডিস্কের কার্যকর ব্যবহার

আমরা দিয়ে শুরু HNSW গ্রাফ ইন্ডেক্সিং অ্যালগরিদম কারণ এটি সূচক তৈরি করা দ্রুত, অনুসন্ধানের জন্য দ্রুত, অত্যন্ত নির্ভুল এবং কার্যকর করা সহজ। যাইহোক, এর একটি সুপরিচিত নেতিবাচক দিক রয়েছে: এটির জন্য প্রচুর মেমরির প্রয়োজন।

একটি এইচএনএসডব্লিউ সূচক হল স্তরগুলির একটি সিরিজ, যেখানে বেস স্তরের উপরে প্রতিটি স্তর পূর্বের তুলনায় প্রায় 10% বেশি নোড। এটি উপরের স্তরগুলিকে এড়িয়ে যাওয়ার তালিকা হিসাবে কাজ করতে সক্ষম করে, যাতে সমস্ত ভেক্টর রয়েছে নীচের স্তরের ডান পাশের দিকে অনুসন্ধানকে শূন্য করতে দেয়।

যাইহোক, এই ডিজাইনের অর্থ হল (সমস্ত গ্রাফ সূচকের সাথে সাধারণ) আপনি "ডিস্ক ক্যাশে আমাদের বাঁচাবে" বলার থেকে দূরে থাকতে পারবেন না কারণ, সাধারণ ডাটাবেস কোয়েরি ওয়ার্কলোডের বিপরীতে, গ্রাফের প্রতিটি ভেক্টরের প্রায় সমান সুযোগ রয়েছে একটি অনুসন্ধানের সাথে প্রাসঙ্গিক হচ্ছে (ব্যতিক্রম উপরের স্তর, যা আমরা ক্যাশে করতে পারি এবং করতে পারি।)

উইকিপিডিয়া নিবন্ধের অংশগুলির (ডিস্কে প্রায় 120 জিবি) একটি 100M ভেক্টর ডেটাসেট পরিবেশন করার প্রোফাইলটি আমার ডেস্কটপে 64GB RAM সহ দেখতে কেমন ছিল, যখন আমরা লুসিন ব্যবহার করছিলাম:

ক্যাসান্ড্রা ডিস্কের বাইরে ভেক্টর পড়ার অপেক্ষায় তার প্রায় সমস্ত সময় ব্যয় করছে।

এই সমস্যাটি সমাধান করার জন্য, আমরা DiskANN নামে একটি আরও উন্নত অ্যালগরিদম প্রয়োগ করেছি এবং এটিকে একটি স্বতন্ত্র এমবেডেড ভেক্টর সার্চ ইঞ্জিন হিসাবে ওপেন সোর্স করেছি, JVector . (বিশেষত, JVector এ বর্ণিত DiskANN-এর বর্ধিত সংস্করণ প্রয়োগ করে ফ্রেশডিস্কএএনএন কাগজ।) সংক্ষেপে, DiskANN HNSW এর চেয়ে দীর্ঘ প্রান্ত সহ একটি একক-স্তরের গ্রাফ ব্যবহার করে এবং ডিস্ক IOPS কমাতে ভেক্টর এবং প্রতিবেশীদের একটি অপ্টিমাইজড বিন্যাস ব্যবহার করে এবং সাদৃশ্য গণনার গতি বাড়াতে মেমরিতে ভেক্টরগুলির একটি সংকুচিত উপস্থাপনা রাখে। এর ফলে উইকিপিডিয়া কাজের চাপ তিনগুণ বেড়ে যায়।

এখানে HNSW বনাম DiskANN ক্লায়েন্ট/সার্ভারের কোনো উপাদান ছাড়াই বিশুদ্ধভাবে এম্বেড করা দৃশ্যের মতো দেখায়। এটি Lucene (HNSW) এবং JVector (DiskANN) এর অধীনে Deep100M ডেটাসেট অনুসন্ধানের গতি পরিমাপ করে। সূচক এবং কাঁচা ভেক্টর সহ লুসিন সূচক 55GB। JVector সূচক হল 64GB। অনুসন্ধানটি আমার 24GB MacBook-এ সঞ্চালিত হয়েছিল, যার প্রায় এক-তৃতীয়াংশ মেমরি রয়েছে যতটা RAM-তে সূচক ধরে রাখতে লাগবে।

সমস্যা 5: সংমিশ্রণযোগ্যতা

ডাটাবেস সিস্টেমের প্রেক্ষাপটে কম্পোজেবিলিটি বলতে বোঝায় সুসংহতভাবে বিভিন্ন বৈশিষ্ট্য এবং ক্ষমতাকে নিরবিচ্ছিন্নভাবে একীভূত করার ক্ষমতা। ভেক্টর অনুসন্ধানের মতো নতুন ক্যাটাগরির ক্ষমতার একীকরণ নিয়ে আলোচনা করার সময় এটি বিশেষভাবে তাৎপর্যপূর্ণ। অ-খেলনা অ্যাপ্লিকেশন সবসময় উভয় ক্লাসিক প্রয়োজন হবে CRUD ডাটাবেস বৈশিষ্ট্যের পাশাপাশি নতুন ভেক্টর অনুসন্ধান।

সহজ বিবেচনা করুন এআই চ্যাটবট Astra DB এর জন্য নমুনা আবেদন। এটি একটি RAG অ্যাপ্লিকেশনের মতোই খাঁটি যা আপনি পাবেন, ভেক্টর অনুসন্ধান ব্যবহার করে ব্যবহারকারীর প্রশ্নের উত্তর দেওয়ার জন্য এলএলএম-এর উপযুক্ত ডকুমেন্টেশন তৈরি করা। যাইহোক, এমনকি এই জাতীয় একটি সাধারণ ডেমোর জন্য এখনও কথোপকথনের ইতিহাস পুনরুদ্ধার করার জন্য Astra DB-কে "স্বাভাবিক" নন-ভেক্টর কোয়েরি করতে হবে, যা অবশ্যই LLM-এর প্রতি অনুরোধের সাথে অন্তর্ভুক্ত করতে হবে যাতে এটি ইতিমধ্যে যা আছে তা "মনে রাখতে" পারে। গৃহীত জায়গা. তাই মূল প্রশ্নগুলির মধ্যে রয়েছে:

1. ব্যবহারকারীর প্রশ্নের জন্য সবচেয়ে প্রাসঙ্গিক নথি (বা নথির খণ্ড) খুঁজুন
2. ব্যবহারকারীর কথোপকথন থেকে শেষ বিশটি বার্তা পুনরুদ্ধার করুন

আরও বাস্তবসম্মত ব্যবহারের ক্ষেত্রে, আমাদের একজন সমাধান প্রকৌশলী সম্প্রতি এশিয়ার একটি কোম্পানির সাথে কাজ করছিলেন যেটি তাদের পণ্যের ক্যাটালগে শব্দার্থিক অনুসন্ধান যোগ করতে চেয়েছিল, কিন্তু শব্দ-ভিত্তিক ম্যাচিং সক্ষম করতেও চেয়েছিল। উদাহরণ স্বরূপ, ব্যবহারকারী যদি [“লাল” বল ভালভ] অনুসন্ধান করে, তাহলে তারা সেই আইটেমগুলিতে অনুসন্ধান সীমাবদ্ধ করতে চায় যার বিবরণ “লাল” শব্দটির সাথে মেলে, ভেক্টর এমবেডিংগুলি শব্দার্থগতভাবে যতই একই রকম হোক না কেন। তারপরে মূল নতুন ক্যোয়ারীটি (সেশন ম্যানেজমেন্ট, অর্ডার ইতিহাস এবং শপিং কার্ট আপডেটের মতো ক্লাসিক কার্যকারিতার উপরে) এইভাবে: পণ্যগুলিকে সেগুলির মধ্যে সীমাবদ্ধ করুন যাতে সমস্ত উদ্ধৃত পদ রয়েছে, তারপর ব্যবহারকারীর অনুসন্ধানের সাথে সর্বাধিক মিল খুঁজে পান

এই দ্বিতীয় উদাহরণটি এটি স্পষ্ট করে যে শুধুমাত্র যে অ্যাপ্লিকেশনগুলির জন্য ক্লাসিক ক্যোয়ারী কার্যকারিতা এবং ভেক্টর অনুসন্ধান উভয়েরই প্রয়োজন তা নয়, তবে তাদের প্রায়শই একই ক্যোয়ারীতে প্রতিটির উপাদান ব্যবহার করতে সক্ষম হতে হবে।

এই তরুণ ক্ষেত্রের শিল্পের বর্তমান অবস্থা হল আমি যাকে "স্বাভাবিক" ডাটাবেসে ক্লাসিক কোয়েরি, ভেক্টর ডাটাবেসে ভেক্টর ক্যোয়ারী, এবং তারপর দুটিকে একটি অ্যাডহক ফ্যাশনে একসাথে সেলাই করার চেষ্টা করা। একই সময়ে প্রয়োজনীয়। এটি ত্রুটি-প্রবণ, ধীর এবং ব্যয়বহুল; এটির একমাত্র গুণ হল যে আপনি এটিকে কার্যকর করতে পারবেন যতক্ষণ না আপনার কাছে একটি ভাল সমাধান রয়েছে।

Astra DB-তে, আমরা ক্যাসান্দ্রা SAI-এর উপরে সেই আরও ভাল সমাধান তৈরি করেছি (এবং ওপেন-সোর্স)। যেহেতু SAI কাস্টম সূচকের প্রকারগুলি তৈরি করার অনুমতি দেয় যেগুলি সমস্তই ক্যাসান্ড্রা স্থিতিশীল এবং কমপ্যাকশন জীবন চক্রের সাথে আবদ্ধ, তাই Astra DB এর জন্য বিকাশকারীদের বুলিয়ান পূর্বাভাস, শব্দ-ভিত্তিক অনুসন্ধান এবং ভেক্টর অনুসন্ধানকে মিশ্রিত করতে এবং মেলাতে অনুমতি দেওয়া সহজ। পৃথক সিস্টেম পরিচালনা এবং সিঙ্ক্রোনাইজ করা। এটি ডেভেলপারদের তৈরি করে জেনারেটিভ AI অ্যাপ্লিকেশনগুলিকে আরও পরিশীলিত ক্যোয়ারী ক্ষমতা দেয় যা আরও বেশি উত্পাদনশীলতা এবং দ্রুত সময়ে বাজারে নিয়ে যায়।

শেষ করি

ভেক্টর সার্চ ইঞ্জিনগুলি স্কেল-আউট, আবর্জনা সংগ্রহ, সঙ্গতি, ডিস্কের কার্যকর ব্যবহার এবং সংমিশ্রণযোগ্যতা সহ একাধিক স্থাপত্য চ্যালেঞ্জ সহ একটি গুরুত্বপূর্ণ নতুন ডাটাবেস বৈশিষ্ট্য। আমি বিশ্বাস করি যে Astra DB-এর জন্য ভেক্টর অনুসন্ধান তৈরিতে আমরা জেনারেটিভ AI অ্যাপ্লিকেশনগুলির বিকাশকারীদের জন্য একটি সেরা-ইন-ক্লাস অভিজ্ঞতা প্রদানের জন্য ক্যাসান্ড্রার ক্ষমতাগুলিকে কাজে লাগাতে সক্ষম হয়েছি। এখানে Astra DB সম্পর্কে আরও জানুন , অথবা আপনি যদি ভেক্টর অনুসন্ধান অ্যালগরিদমগুলির সাথে কাছাকাছি এবং ব্যক্তিগতভাবে উঠতে চান তবে চেক আউট করুন৷ JVector .

- জোনাথন এলিস, ডেটাস্ট্যাক্স দ্বারা