Qdrant အပြည့်အစုံသင်ခန်းစာ: Docker စတင်ခြင်းမှ စစ်ထုတ်မှုပါ vector ရှာဖွေမှုအထိ၊ သင့်ပထမဆုံး RAG အခြေခံကို တည်ဆောက်ပါ

RAG လုပ်သူတိုင်း အခြေအနေတစ်ခုတည်းကို ဖြတ်သန်းဖူးကြမည်: ဦးစွာ memory ထဲရှိ list တစ်ခုဖြင့် vector သိမ်း၊ numpy ဖြင့် cosine similarity တွက်၊ ပျော်ပျော်ပါးပါး အလုပ်လုပ်သည်။ ထို့နောက် အချက်အလက်ပမာဏ တစ်သိန်းရောက်၊ query သည် စက္ကန့်ပိုင်း ကြာစပြုသောအခါ၊ တကယ့် vector database တစ်ခု ရှာသင့်ပြီဟု သတိထားမိသည်။

Qdrant သည် ဤအဆင့်တွင် အများဆုံးအကြံပြုခံရသည့် ရွေးချယ်မှုများထဲမှ တစ်ခုဖြစ်သည်။ ၎င်းသည် Rust ဖြင့်ရေးထားသော open source vector database ဖြစ်ပြီး၊ ကိုယ်တိုင်တည်ဆောက်ရ လွယ်ကူ၊ memory ထိရောက်မှုကောင်း၊ စစ်ထုတ်မှုလုပ်ဆောင်ချက်မှာလည်း တူညီသောထုတ်ကုန်များထဲတွင် ဒီဇိုင်းအပြည့်စုံဆုံးဖြစ်သည်။

ဤသင်ခန်းစာက သုညမှ အသုံးပြုနိုင်သည်အထိ လမ်းညွှန်ပေးမည်: စတင်၊ table ဆောက်၊ ရေးသွင်း၊ ရှာဖွေ၊ စစ်ထုတ်၊ နှင့် အစကတည်းက သိထားသင့်သည့် တွင်းအနည်းငယ်။

ဒါက ဘာလဲ

Qdrant လုပ်သည့်အလုပ်ကို စာတစ်ကြောင်းဖြင့်ပြောရလျှင်: မြင့်မားသောဖက်ရှင် vector ကို သိမ်းဆည်းပြီး၊ သင့် query vector နှင့် အဆင်တူဆုံး အနည်းငယ်ကို milliseconds အတွင်း ရှာဖွေပေးခြင်းဖြစ်သည်။

သို့သော် ၎င်းသည် အဆင်တူမှုတွက်ချက်ခြင်းသာ မလုပ်ပါ။ vector တစ်ခုစီတွင် payload တစ်ခု (metadata အဖြစ် နားလည်နိုင်သည်) တွဲထားနိုင်ပြီး၊ အထဲတွင် မည်သည့် JSON အချက်အလက်မဆို—စာရွက်စာတမ်းခေါင်းစဉ်၊ ရေးသားသူ၊ ရက်စွဲ၊ စျေးနှုန်း၊ ကုန်လက်ကျန်အခြေအနေ—ထည့်နိုင်သည်။ ရှာဖွေသည့်အခါ "အဓိပ္ပာယ်အဆင်တူ" နှင့် "payload အခြေအနေစစ်ထုတ်ခြင်း" ကို တစ်ပြိုင်နက် လုပ်နိုင်သည်။ ဤသည် RAG မြင်ကွင်းတွင် ၎င်း၏ တန်ဖိုးအရှိဆုံးစွမ်းရည်ဖြစ်သည်။

စစ်ထုတ်ခြင်း အဘယ်ကြောင့် ဤမျှအရေးကြီးသနည်း။ အချက်အလက်များစွာသည် vector ထဲ ထည့်၍မရသောကြောင့်ဖြစ်သည်။ တရားဝင်စာရွက်စာတမ်းက အလွန်ရှင်းလင်းစွာ ပြောထားသည်: အရာဝတ္ထု၏ အချို့လက္ခဏာများကို embedding vector ဖြင့် ဖော်ပြ၍မဖြစ်နိုင်သောအခါ (ဥပမာ ကုန်လက်ကျန်အခြေအနေ သို့မဟုတ် စျေးနှုန်းအပိုင်းအခြား)၊ ထပ်ဆောင်းအခြေအနေသတ်မှတ်ခြင်းသည် မရှိမဖြစ်လိုအပ်လာသည်။ RAG က သုံးနှစ်ကြာ ဖယ်ရှားပြီးသား စာရွက်စာတမ်းဟောင်းကို အကြံပြုစေချင်မည် မဟုတ်ပါ။

ဘာလုပ်နိုင်သလဲ

လက်တွေ့တွင် အသုံးအများဆုံး အသုံးပြုမှုများမှာ:

• RAG ၏ ရှာဖွေရေးအလွှာ: စာရွက်စာတမ်းကို အပိုင်းခွဲ၊ embed လုပ်၊ Qdrant ထဲသိမ်း၊ query လုပ်သည့်အခါ အသက်ဆိုင်ဆုံးအပိုင်းကို ပြန်ယူ၍ LLM ကို ကျွေးသည်။
• အဓိပ္ပာယ်ရှာဖွေမှု: ဆိုက်တွင်းရှာဖွေမှုသည် သော့ချက်စကားလုံးတိုက်ဆိုင်မှုကိုသာ အားမကိုးတော့ဘဲ၊ "စျေးပေါသော laptop" နှင့် "တန်ဖိုးသက်သာသော လက်ပ်တော့ကွန်ပျူတာ" သည် အတူတူဖြစ်ကြောင်း နားလည်နိုင်သည်။
• အကြံပြုစနစ်: ကုန်ပစ္စည်း သို့မဟုတ် အကြောင်းအရာ၏ embedding vector ဖြင့် အဆင်တူအရာများကို ရှာသည်။
• ထပ်နေမှုဖယ်ရှားခြင်းနှင့် အဆင်တူမှုရှာဖွေခြင်း: အကြောင်းအရာထပ်နေသည့် သို့မဟုတ် အလွန်ဆင်တူသည့် အချက်အလက်ကို ရှာဖွေသည်။

ဘယ်လိုသုံးမလဲ (အဆင့်များ)

အဆင့်တစ်: Docker ဖြင့် စတင်ပါ

အမြန်ဆုံးစတင်နည်းမှာ Docker ဖြစ်သည်:

docker pull qdrant/qdrant

docker run -p 6333:6333 -p 6334:6334 \
    -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \
    qdrant/qdrant

အလုပ်လုပ်ပြီးနောက် မှတ်ထားရမည့် port သုံးခုရှိသည်:

• localhost:6333 — REST API
• localhost:6333/dashboard — ဝဘ်စီမံခန့်ခွဲမှု interface (ဖွင့်ကြည့်ရန် အထူးအကြံပြုသည်၊ debug လုပ်ရာတွင် အလွန်အထောက်အကူဖြစ်သည်)
• localhost:6334 — gRPC

ထို -v mount သည် အလွန်အရေးကြီးသည်။ မ mount ထားလျှင် container ရပ်တာနှင့် အချက်အလက်ပျောက်သွားမည်။ ဤသည် အစပြုသူ အများဆုံးတွေ့ရသည့် ပထမတွင်းဖြစ်သည်။

အဆင့်နှစ်: client ကို install လုပ်ပြီး ချိတ်ဆက်ပါ

Python ဥပမာအနေဖြင့်:

pip install qdrant-client

from qdrant_client import QdrantClient

client = QdrantClient(url="http://localhost:6333")

တရားဝင်အနေဖြင့် JavaScript၊ Rust၊ Java၊ C# နှင့် Go client များကိုပါ ပေးထားပြီး၊ syntax သဘောတရား တူညီသည်။

အဆင့်သုံး: collection တည်ဆောက်ပါ

Collection သည် relational database ရှိ table နှင့် ညီမျှသည်။ တည်ဆောက်ရာတွင် ကိစ္စနှစ်ခုကို ဆုံးဖြတ်ရမည်: vector ဖက်ရှင်နှင့် အကွာအဝေးတိုင်းတာမှု။

from qdrant_client.models import Distance, VectorParams

client.create_collection(
    collection_name="test_collection",
    vectors_config=VectorParams(size=4, distance=Distance.DOT),
)

size သည် သင့် embedding မော်ဒယ်၏ output ဖက်ရှင်နှင့် လုံးဝကိုက်ညီရမည်၊ မှားဖြည့်လျှင် ရေးသွင်းစဉ် error တက်မည်။ အကွာအဝေးတိုင်းတာမှုသည် inner product (DOT)၊ cosine (COSINE) နှင့် Euclidean distance (EUCLID) ကို ထောက်ပံ့သည်။

လက်တွေ့အကြံပြုချက်: သင် OpenAI သို့မဟုတ် များစွာသော open source embedding မော်ဒယ်ကို သုံးလျှင် COSINE ရွေးခြင်းက ပုံမှန်အားဖြင့် အတည်ငြိမ်ဆုံးဖြစ်သည်။ မော်ဒယ် output ကို normalize လုပ်ပြီးဖြစ်ကြောင်း သင်သေချာမှတပါး DOT ကို default အဖြစ် မသုံးပါနှင့်။

အဆင့်လေး: vector ရေးသွင်းခြင်း (upsert)

from qdrant_client.models import PointStruct

client.upsert(
    collection_name="test_collection",
    wait=True,
    points=[
        PointStruct(
            id=1,
            vector=[0.05, 0.61, 0.76, 0.74],
            payload={"city": "Yangon", "category": "tech", "price": 1200},
        ),
        PointStruct(
            id=2,
            vector=[0.19, 0.81, 0.75, 0.11],
            payload={"city": "Mandalay", "category": "food", "price": 300},
        ),
    ],
)

wait=True ကို သတိပြုပါ။ ၎င်းသည် ရေးသွင်းပြီးမှ ပြန်ပေးမည်—စမ်းသပ်အဆင့်တွင် မဖြစ်မနေဖွင့်ပါ၊ မဟုတ်လျှင် နောက်တစ်ကြောင်းတွင် အချက်အလက်ရှာမတွေ့ဘဲ ဘဝကို သံသယဖြစ်နေမည်။ တရားဝင်ပတ်ဝန်းကျင်တွင် batch ရေးသွင်းသည့်အခါ throughput မြှင့်ရန် ပိတ်ထားနိုင်သည်။

အဆင့်ငါး: ရှာဖွေခြင်းနှင့် စစ်ထုတ်ခြင်း

ဤသည် Qdrant ၏ သင်ယူ၍တန်ဆုံးအပိုင်းဖြစ်သည်။ စစ်ထုတ်အခြေအနေတွင် clause သုံးမျိုးရှိပြီး၊ မည်သို့မဆို ပေါင်းစပ်နှင့် ထပ်ဆင့်အသိုက်လုပ်နိုင်သည်:

• must — အခြေအနေအားလုံး ကျေနပ်ရမည်၊ AND နှင့်ညီ
• should — အနည်းဆုံးတစ်ခု ကျေနပ်ရမည်၊ OR နှင့်ညီ
• must_not — အခြေအနေအားလုံး မကျေနပ်ရ၊ NOT A AND NOT B နှင့်ညီ

လက်တွေ့ဥပမာတစ်ခု:

{
  "filter": {
    "must": [
      { "key": "city", "match": { "value": "Yangon" } }
    ],
    "must_not": [
      { "key": "category", "match": { "value": "food" } }
    ]
  }
}

ဤအပိုင်း၏ အဓိပ္ပာယ်မှာ: မြို့သည် ရန်ကုန်ဖြစ်ပြီး၊ အမျိုးအစားသည် အစားအစာ မဟုတ်။ တိကျတိုက်ဆိုင်မှုအပြင်၊ အပိုင်းအခြားရှာဖွေမှု (စျေးနှုန်းအပိုင်းအခြား)၊ ပထဝီအာကာသရှာဖွေမှု၊ full-text တိုက်ဆိုင်မှုနှင့် အသိုက်အရာဝတ္ထုစစ်ထုတ်မှုကိုပါ ထောက်ပံ့သည်။

အဆင့်မြင့်နည်းပညာ

payload အညွှန်း မဖြစ်မနေ ဆောက်ပါ။ တရားဝင်အနေဖြင့် ရှင်းလင်းစွာ အကြံပြုသည်: မကြာခဏ စစ်ထုတ်ရန်သုံးသည့် field များအတွက် payload အညွှန်းတည်ဆောက်ပါ၊ မဟုတ်လျှင် စစ်ထုတ်ခြင်းသည် full table scan အဖြစ် ကျဆင်းသွားမည်။ ဤသည် စွမ်းဆောင်ရည်တွင် အလွယ်ဆုံးနင်းမိပြီး အလွယ်ဆုံးပြင်နိုင်သည့်တွင်းဖြစ်သည်။

payload ၏ schema ကို ဦးစွာ တွေးပါ။ vector ကို ပြန်တွက်နိုင်သော်လည်း၊ payload ဖွဲ့စည်းပုံ ပြောင်းရသည်မှာ အလွန်နာသည်။ စတင်မီ အနာဂတ်တွင် မည်သည့်အခြေအနေဖြင့် စစ်ထုတ်မည်ကို ဦးစွာ တွေးပါ—အချိန်အပိုင်းအခြားလား? ခွင့်ပြုချက်အဆင့်လား? အချက်အလက်ရင်းမြစ်လား? RAG စနစ်တွင်၊ "ဤစာရွက်စာတမ်းကို ဤအသုံးပြုသူ ကြည့်နိုင်မကြည့်နိုင်" ဟူသော ခွင့်ပြုချက်စစ်ထုတ်ခြင်းသည် လုနီးပါး မဖြစ်မနေ သုံးရမည်၊ ပြီးမှ မထည့်ဘဲ။

dashboard ဖြင့် debug လုပ်ပါ။ localhost:6333/dashboard က collection အခြေအနေ၊ points ကြည့်ခြင်း၊ query စမ်းလုပ်ခြင်းကို တိုက်ရိုက်ကြည့်နိုင်သည်။ တစ်လမ်းတည်း print လုပ်တာထက် များစွာ မြန်သည်။

batch ရေးသွင်းသည့်အခါ wait ကို ပိတ်ပါ။ အများအပြားရေးသွင်းသည့်အခါ wait=True သည် အရှိန်ကို ပြင်းပြင်းထန်ထန် နှေးစေမည်၊ batch ပို့ပြီးမှ တစ်ကြိမ် အတည်ပြုရုံဖြင့် လုံလောက်သည်။

id ကို အဓိပ္ပာယ်ရှိသောတန်ဖိုးဖြင့် သုံးပါ။ Qdrant သည် integer နှင့် UUID ကို id အဖြစ် ထောက်ပံ့သည်။ သင့်မူရင်းအချက်အလက်၏ primary key သို့မဟုတ် ၎င်း၏ hash တန်ဖိုးကို သုံးပါ၊ အညွှန်းပြန်လုပ်သည့်အခါ ထပ်နေမှုမဖြစ်ဘဲ မှန်ကန်စွာ overwrite နိုင်မည်။

သတိပြုရန်

memory စီမံကို ဦးစွာ တွက်ပါ။ vector database သည် memory စားသည်။ ကြမ်းကြမ်း ခန့်မှန်းနည်းမှာ "vector အရေအတွက် × ဖက်ရှင် × 4 bytes" ပြီးမှ အညွှန်းနှင့် payload ၏ overhead ကို ပေါင်းသည်။ vector တစ်သန်း ၁၅၃၆ ဖက်ရှင်၊ မူရင်း vector တစ်ခုတည်းဖြင့် ခန့်မှန်း 6GB ဖြစ်သည်။ အချက်အလက်ပမာဏ များသည့်အခါ Qdrant ၏ quantization နှင့် on-disk သိုလှောင်မှုရွေးချယ်စရာများကို လေ့လာသင့်သည်။

ဖက်ရှင်မှားဖြည့်လျှင် ကယ်၍မရ။ collection ၏ vector ဖက်ရှင်ကို တစ်ကြိမ်တည်ဆောက်ပြီးလျှင် မပြောင်းနိုင်တော့ဘဲ ပြန်ဆောက်ရုံသာ ရှိသည်။ embedding မော်ဒယ်ပြောင်းသည့်အခါ အထူးနင်းမိလွယ်သည်။

Qdrant ကို ပင်မ database အဖြစ် မမှတ်ပါနှင့်။ ၎င်းသည် ရှာဖွေရေးအလွှာဖြစ်ပြီး၊ မူရင်းစာရွက်စာတမ်းနှင့် စီးပွားရေးအချက်အလက်ကို သင့်မူလ database တွင် သိမ်းသင့်သည်၊ Qdrant ၏ payload တွင် ရှာဖွေမှုနှင့် စစ်ထုတ်မှုလိုအပ်သည့် field များသာ ထည့်ပါ။ ရောနှောထားလျှင် နောက်ပိုင်း ထိန်းသိမ်းရ အလွန်ခက်မည်။

ကိုယ်တိုင်တည်ဆောက်မှု၏ လည်ပတ်မှုကုန်ကျစရိတ်ကို လျှော့မတွက်ပါနှင့်။ Docker ဖြင့် စတင်ရ လွယ်ကူသော်လည်း၊ backup၊ စောင့်ကြည့်ခြင်း၊ တိုးချဲ့ခြင်း၊ ဗားရှင်းမြှင့်ခြင်းတို့သည် လူစောင့်ရသည့်အရာများဖြစ်သည်။ အဖွဲ့တွင် လည်ပတ်ထိန်းသိမ်းသူ မရှိလျှင် Qdrant Cloud သို့မဟုတ် အခြား hosted ဖြေရှင်းချက်က ပိုတန်နိုင်သည်။

TheAI Academy သုံးသပ်ချက်

ကျွန်တော့်ကိုယ်ပိုင်အတွေ့အကြုံအရ၊ vector database ရွေးချယ်မှုသည် တကယ်တော့ ထင်သလောက် အရေးမကြီးပါ—Qdrant၊ Weaviate၊ Milvus ဤကုမ္ပဏီများသည် အခြေခံ အဆင်တူမှုရှာဖွေမှုတွင် ကွာခြားချက်အကန့်အသတ်ရှိပြီး၊ RAG အရည်အသွေးကို တကယ်ဆုံးဖြတ်သည်မှာ အပိုင်းခွဲနည်းဗျူဟာ၊ embedding မော်ဒယ်နှင့် rerank ဖြစ်သည်။

သို့သော် Qdrant ကို ရွေးရန် အကြောင်းရင်းတစ်ခု ရွေးရလျှင်၊ ကျွန်တော် စစ်ထုတ်မှုလုပ်ဆောင်ချက်ဟု ပြောမည်။ ၎င်း၏ must／should／must_not ဒီဇိုင်းသည် သန့်ရှင်း၊ အသိုက်ပေါင်းစပ်နိုင်၊ စွမ်းဆောင်ရည်ကိုလည်း လေးလေးနက်နက် ဒီဇိုင်းဆွဲထားသည် (အညွှန်းဆောက်ထားမှသာ)။ တကယ့်စီးပွားရေး RAG မြင်ကွင်းတွင် ခွင့်ပြုချက်စစ်ထုတ်ခြင်းနှင့် အချိန်ကာလစစ်ထုတ်ခြင်းသည် မဖြစ်မနေလိုအပ်ချက်ဖြစ်ပြီး၊ ဤအခါ စစ်ထုတ်စွမ်းရည်သည် "အပိုအမှတ်" မှ "မရှိမဖြစ်" သို့ ပြောင်းသွားသည်။

နောက်ထပ်လက်တွေ့အကျိုးတစ်ခုမှာ ကိုယ်တိုင်တည်ဆောက်ရ အခက်အခဲနည်းခြင်းဖြစ်သည်။ docker run တစ်ကြောင်းဖြင့် စတင်နိုင်ပြီး၊ Kubernetes မလို၊ မှီခိုဝန်ဆောင်မှုအစုအဝေးလည်း မလိုပါ။ စိတ်ကူးကို ဒေသတွင်း ဦးစွာ အတည်ပြုလိုသည့်အဖွဲ့အတွက် ဤ friction coefficient သည် အလွန်အရေးကြီးသည်။

သုံးသပ်ချက်: Qdrant သည် အမြန်ဆုံးမဟုတ်၊ လုပ်ဆောင်ချက်အများဆုံးလည်း မဟုတ်ပါ၊ သို့သော် ၎င်းသည် "စိတ်ကူးမှ အလုပ်လုပ်သည်အထိ" လမ်းအတိုဆုံး vector database များထဲမှ တစ်ခုဖြစ်သည်။ မြန်မာအဖွဲ့အများစုအတွက် ဤဂုဏ်သတ္တိသည် benchmark ကောင်းခြင်းထက် ပိုတန်ဖိုးရှိသည်။

မြန်မာဆော့ဖ်ဝဲရေးဆွဲသူများအတွက် အကြံပြုချက်: ပထမဆုံး RAG လုပ်လျှင် Docker ဖြင့် ဒေသတွင်း လုပ်ငန်းစဉ်တစ်ခုလုံးကို ဦးစွာ လည်ပတ်ပြီး၊ အချက်အလက်ပမာဏကို ထောင်ဂဏန်းအတွင်း ထိန်းကာ၊ အာရုံစိုက်မှုကို အပိုင်းခွဲခြင်းနှင့် ရှာဖွေမှုအရည်အသွေးတွင် ထားပါ၊ စွမ်းဆောင်ရည်ညှိရန် မလောပါနှင့်။ အရည်အသွေးခိုင်မာပြီးမှ အတိုင်းအတာအကြောင်း ဆွေးနွေးပါ။ embedding မော်ဒယ် သို့မဟုတ် ဒေသတွင်း LLM လည်ပတ်ရန် GPU လိုအပ်လျှင် ကျွန်တော်တို့၏ RunPod သင်ခန်းစာ ကို ကြည့်နိုင်ပါသည်။ ဖွံ့ဖြိုးရေးဆိုင်ရာ ကိရိယာများ ပိုမိုကြည့်လိုပါက ဆိုက်ပေါ်ရှိ AI ဖွံ့ဖြိုးရေးမူဘောင်နှင့် အခြေခံအဆောက်အအုံ အမျိုးအစားတွင် စုစည်းထားပါသည်။

အချက်အလက်ရင်းမြစ်

• Qdrant တရားဝင် Quickstart စာရွက်စာတမ်း
• Qdrant တရားဝင် စစ်ထုတ်မှုလုပ်ဆောင်ချက် စာရွက်စာတမ်း

（ဤဆောင်းပါးကို တရားဝင်စာရွက်စာတမ်းအရ စုစည်းထားပြီး၊ API syntax ကို တရားဝင်နောက်ဆုံးစာရွက်စာတမ်းအရ အခြေခံသည်။）