Firecrawl အပြည့်အစုံ သင်ခန်းစာ - website တိုင်းကို LLM နားလည်တဲ့ Markdown အဖြစ် ပြောင်းလိုက်ပါ
RAG ဒါမှမဟုတ် AI agent လုပ်ရာမှာ အချိန်အကုန်ဆုံးက model ရွေးတာ မဟုတ်ဘဲ web data ကို သန့်စင်ဖို့ပါ။ Firecrawl က Scrape, Crawl, Map, Search စတဲ့ endpoint ခုနစ်မျိုး ပေးပြီး၊ တစ်လိုင်း ခေါ်လိုက်ရုံနဲ့ သန့်ရှင်းတဲ့ Markdown ပြန်ပေးပါတယ်။ ဒီဆောင်းပါးက အခမဲ့ quota ကနေ point ဘယ်လိုတွက်သလဲ အထိ ပြောပြီး၊ သူများ website ကို scrape မလုပ်ခင် သတိထားရမယ့် ဥပဒေ နယ်နိမိတ်ကို ရှင်းပြထားပါတယ်။
RAG လုပ်ဖူးသူတိုင်း ဒီစိတ်ပျက်စရာကို နားလည်ပါတယ် - model ရွေးဖို့၊ vector database သတ်မှတ်ဖို့ နှစ်နာရီ ကုန်ပြီးမှ၊ ရူးမိုက်တဲ့ ပြဿနာတစ်ခုမှာ တင်နေတယ် - scrape လုပ်ပြန်လာတဲ့ web page ထဲမှာ navigation bar၊ ကြော်ငြာ၊ Cookie consent banner ပါနေတယ်၊ ပြီးတော့ page တစ်ဝက်လောက်ကို requests နဲ့ scrape လုပ်ပြန်လာတော့ အခွံဗလာ တစ်ခုပဲ ရတယ်၊ ဘာလို့လဲဆိုတော့ content က JavaScript က render လုပ်ထုတ်တာ ဖြစ်လို့ပါ။
Firecrawl ဟာ ဒီအပိုင်းကို အထူး ဖြေရှင်းတဲ့ tool ပါ။
Firecrawl ဆိုတာ ဘာလဲ
Firecrawl ဟာ web data extraction API တစ်ခုဖြစ်ပြီး Y Combinator ကနေ ထွက်လာကာ တရားဝင် အနေအထားက "internet ကနေ context ရယူဖို့ အလွယ်ကူဆုံး နည်းလမ်း" ပါ။ URL တစ်ခု ထည့်လိုက်ရင် သန့်ရှင်းတဲ့ Markdown တစ်ခု ပြန်ပေးတယ် - ကြော်ငြာ၊ navigation၊ script အားလုံး ရှင်းလင်းပြီး၊ အဓိပ္ပာယ်ရှိတဲ့ content ကိုသာ ချန်ထားပါတယ်။
ကိုယ်တိုင် crawler ရေးတာနဲ့ အကြီးမားဆုံး ကွာခြားချက် နှစ်ခု ရှိပါတယ်။ ပထမ၊ သူက JavaScript rendering ကို ကိုင်တွယ်တယ်၊ ဆိုလိုတာက page ကို အရင် run ပြီးမှ content ကို scrape လုပ်တာဖြစ်ပြီး၊ ဒါက ခေတ်မီ website တွေရဲ့ အဖြစ်များဆုံး scrape ကျရှုံးမှု အကြောင်းရင်းကို ဖြေရှင်းပေးပါတယ်။ ဒုတိယ၊ သူ့ရဲ့ output format က large language model စားဖို့ ဖြစ်လို့ cleaning logic တွေ ပုံစံအများကြီး ထပ်ရေးစရာ မလိုပါ။
သူ ဘာတွေ လုပ်နိုင်လဲ
တရားဝင်အနေနဲ့ endpoint ခုနစ်မျိုး ပေးထားပြီး၊ တစ်ခုစီက မတူတဲ့ အသုံးပြုမှု အခြေအနေနဲ့ ကိုက်ညီပါတယ် -
| endpoint | အသုံးပြုမှု | point တွက်ချက်မှု |
|---|---|---|
| Scrape | page တစ်ခုတည်း scrape | page တစ်ခု ၁ point |
| Crawl | website တစ်ခုလုံး recursive crawl | page တစ်ခု ၁ point |
| Map | website ရဲ့ page structure အမြန်ရယူ | page တစ်ခု ၁ point |
| Search | internet search ပြီး content ပြန်ရယူ | ရလဒ် ၁၀ ခု ၂ point |
| Interact | browser automation၊ login နဲ့ interaction ကိုင်တွယ် | မိနစ်တစ်မိနစ် ၂ point |
| Monitor | page ပြောင်းလဲမှု ခြေရာခံ | စစ်ဆေးမှုတစ်ကြိမ် ၁ point |
| Agent (preview) | AI agent integration | dynamic pricing၊ တစ်နေ့ ၅ ကြိမ် အခမဲ့ |
Plan ကို Free, Hobby, Standard, Growth, Scale နဲ့ Enterprise ခြောက်ဆင့် ခွဲထားပါတယ်။ အခမဲ့ plan က တစ်လ တစ်ထောင် point၊ concurrent request နှစ်ခု။ နှစ်စဉ်ကြေး တွက်ချက်ရင် Hobby က တစ်လ ၁၆ ဒေါ်လာလောက်နဲ့ ၅၀၀၀ point ပါ၊ Standard က ၈၃ ဒေါ်လာလောက်နဲ့ point တစ်သိန်း၊ Growth က ၃၃၃ ဒေါ်လာလောက်နဲ့ point ငါးသိန်း၊ Scale က ၅၉၉ ဒေါ်လာလောက်နဲ့ point တစ်သန်းပါ။ self-service plan အားလုံးက point ကုန်တဲ့အခါ ၅ ဒေါ်လာ တစ်ယူနစ်နဲ့ auto top-up ကို support လုပ်ပါတယ်။
ဘယ်လိုသုံးမလဲ - register ကနေ ပထမဆုံး scrape အထိ
ပထမအဆင့် - register လုပ်ပြီး API key ယူပါ
firecrawl.dev မှာ register လုပ်ပါ၊ အခမဲ့ plan က credit card မလိုပါ။ login ဝင်ပြီးရင် dashboard မှာ API key ရနိုင်ပြီး၊ environment variable ထဲ သိမ်းဖို့ မမေ့ပါနဲ့၊ code ထဲ hard-code မလုပ်ပါနဲ့။
ဒုတိယအဆင့် - ပထမဆုံး page ကို scrape လုပ်ပါ
အလွယ်ဆုံး အသုံးပြုနည်းက Scrape endpoint ဖြစ်ပြီး URL တစ်ခု ထည့်၊ Markdown format လိုကြောင်း သတ်မှတ်လိုက်ရင် သန့်ရှင်းတဲ့ content ပြန်လာပါတယ်။ လက်တွေ့မှာ အရာနှစ်ခု ရပါတယ် - markdown field က ကိုယ်ထည်၊ metadata field က title, description, language စတဲ့ အချက်အလက်တွေ ပါဝင်ပါတယ်။ နောက်တစ်ခုက index တည်ဆောက်ရာမှာ အသုံးဝင်လို့ လျစ်လျူ မရှုပါနဲ့။
တတိယအဆင့် - website တစ်ခုလုံး crawl
Crawl endpoint က သင်ပေးတဲ့ starting URL ကနေ စပြီး link တွေကို recursive follow လုပ်ပါတယ်။ ဒီမှာ သတ်မှတ်ရမယ့် parameter အနည်းငယ် ရှိပါတယ် -
- page အများဆုံး - မသတ်မှတ်ရင် website ကြီးတစ်ခုက သင့်ရဲ့ တစ်လစာ point တစ်ခုလုံးကို လွယ်လွယ်နဲ့ ကုန်စေနိုင်တယ်
- path ကန့်သတ်ချက် -
/docs/အောက်က content ပဲ crawl၊ blog နဲ့ ကုမ္ပဏီ မိတ်ဆက်ဆီ မသွားစေနဲ့ - exclusion rule - login page, search result page လို တန်ဖိုးမရှိတဲ့ page တွေ ဖယ်ထုတ်
ကျွန်တော့် အကျင့်က Map endpoint နဲ့ website structure ကို အရင်တစ်ခါ ကြည့်ပြီး၊ page စုစုပေါင်း သင့်တင့်တဲ့ range အတွင်း ရှိမရှိ သေချာမှ Crawl run မလား ဆုံးဖြတ်တာပါ။ ဒီအဆင့်က point မတော်တဆ ကုန်ခြင်း အများစုကို ရှောင်ရှားနိုင်ပါတယ်။
စတုတ္ထအဆင့် - သင့်ရဲ့ RAG process ထဲ ချိတ်ဆက်ပါ
Markdown ရပြီးနောက် standard process က - chunking, vectorize, vector database ထဲ သိမ်း။ Firecrawl ရဲ့ Markdown က heading hierarchy ကို ထိန်းသိမ်းထားလို့ heading နဲ့ chunk boundary လုပ်တဲ့ strategy အတွက် အထူး ဖော်ရွေပါတယ် - HTML ကို plain text ပြောင်းပြီးနောက် ရွှံ့တစ်တုံးလို ဖြစ်တာနဲ့ ယှဉ်ရင် quality က အများကြီး ကွာပါတယ်။
အဆင့်မြင့် နည်းလမ်းများ
Map အရင်၊ Crawl နောက်၊ အမြဲ။ ဒါက ကျွန်တော် အလေးအနက် ပြောချင်တဲ့ အချက်ပါ။ Map က point အနည်းငယ်နဲ့ ဒီ website မှာ page ဘယ်နှစ်ခု ရှိသလဲ၊ structure ဘယ်လိုလဲ ပြောပြနိုင်ပါတယ်။ ဒီအဆင့် ကျော်ပြီး တိုက်ရိုက် Crawl လုပ်တာက point ကုန်တဲ့ အဖြစ်များဆုံး နည်းလမ်းပါ။
structured extraction နဲ့ ကိုယ်တိုင် parse ရေးတာကို အစားထိုးပါ။ Scrape က schema သတ်မှတ်တာကို support လုပ်ပြီး၊ model ကို page content မှ သင်လိုချင်တဲ့ field (ဥပမာ ကုန်ပစ္စည်းနာမည်၊ ဈေးနှုန်း၊ stock status) အဖြစ် တိုက်ရိုက် extract ခိုင်းနိုင်ပါတယ်။ ဒါက Markdown scrape ပြီးမှ regular expression ကိုယ်တိုင်ရေးတာထက် ပိုတည်ငြိမ်ပါတယ်၊ အထူးသဖြင့် page redesign ဖြစ်တဲ့အခါ။
concurrency က တကယ့် bottleneck ပါ။ အခမဲ့ version မှာ concurrent request နှစ်ခုပဲ ရှိလို့ page တစ်ထောင် scrape လုပ်တာ အရမ်း နှေးပါလိမ့်မယ်။ prototype validation လုပ်နေရင် ငါးဆယ် page အရင် scrape ပြီး process အလုပ်လုပ်မလုပ် သေချာရုံ လုပ်ပါ၊ အစကတည်းက site တစ်ခုလုံး မ run ပါနဲ့။
Monitor က competitor tracking အတွက် သင့်တော်ပါတယ်။ ပြိုင်ဘက်ရဲ့ pricing page ဒါမှမဟုတ် product page ပြောင်းလဲမှုကို စောင့်ကြည့်ချင်ရင် Monitor endpoint က ကိုယ်တိုင် schedule ဆွဲပြီး Scrape run တာထက် ပိုသက်သာပြီး၊ စစ်ဆေးမှုတစ်ကြိမ်ကို ၁ point ပဲ တွက်ပါတယ်။
observability tool နဲ့ တွဲသုံးပါ။ သင့်ရဲ့ RAG process မှာ Helicone ဒါမှမဟုတ် Langfuse ချိတ်ထားရင်၊ scrape လုပ်တဲ့ source URL ကိုပါ မှတ်ထားဖို့ မမေ့ပါနဲ့။ နောက်ပိုင်း "model က ဘာလို့ အဖြေ မှားလဲ" စစ်ဆေးတဲ့အခါ ပြဿနာ ၈၀ ရာခိုင်နှုန်းက source data မှာဖြစ်ပြီး model မှာ မဟုတ်ပါ။
သတိပြုရန်
ဥပဒေ နယ်နိမိတ်ကို အရင် စဉ်းစားထားပါ။ ဒါက ကျွန်တော် ထင်တဲ့ အရေးကြီးဆုံး အပိုင်းပါ။ Firecrawl tool ကိုယ်တိုင်က ကြားနေဖြစ်ပေမဲ့၊ scrape လုပ်တဲ့ လုပ်ဆောင်ချက်ရဲ့ ဥပဒေ တာဝန်က သုံးစွဲသူအပေါ်မှာ ရှိပါတယ်။ target website ရဲ့ robots.txt နဲ့ terms of service ကို လိုက်နာပါ၊ commercial အသုံးပြုမှုဆိုရင် copyright နဲ့ database right ကို အထူး သတိထားပါ။ သူများ content ကို အစုလိုက် scrape လုပ်ပြီး ကိုယ့် product ထဲ ထည့်တာက risk မနိမ့်ပါ။ သံသယ ရှိရင် ဥပဒေ အကြံဉာဏ် ရယူပါ၊ "ဘယ်သူမဆို scrape လုပ်နေတာပဲ" ဆိုတဲ့ စိတ်ဓာတ်နဲ့ မလုပ်ပါနဲ့။
point ကုန်ကျမှုကို ကြိုတင်တွက်ဖို့ ခက်ပါတယ်။ ၃၀ page လောက်ပဲ ရှိပုံရတဲ့ document website တစ်ခုက pagination နဲ့ parameter combination ကြောင့် ၃၀၀ page အဖြစ် ဖြန့်ထွက်နိုင်ပါတယ်။ page အများဆုံး သတ်မှတ်တာက မဖြစ်မနေ ကိုယ့်ကို ကာကွယ်တာပါ။
website တိုင်း scrape လို့ မရပါ။ login လိုတာ၊ တင်းကြပ်တဲ့ anti-scraping mechanism ရှိတာ၊ ဒါမှမဟုတ် automatic access ကို ရှင်းရှင်း တားမြစ်တဲ့ website တွေမှာ Interact endpoint က interaction အခြေအနေ တစ်ချို့ ကိုင်တွယ်နိုင်ပေမဲ့ အစွမ်းကုန် မဟုတ်ပါ။ scrape မရတဲ့ website တွေ့ရင် တစ်ဖက်က တမင် တားထားတာ ဟုတ်မဟုတ် အရင် စစ်ဆေးပါ - ဟုတ်ရင် အဲဒါက သင့်ကို scrape မလုပ်ဖို့ ပြောနေတာပါ။
output quality ကို စစ်ဆေးဖို့ လိုအပ်နေဆဲပါ။ Markdown conversion က website အများစုမှာ ကောင်းကောင်း အလုပ်လုပ်ပေမဲ့၊ layout ထူးဆန်းတဲ့ page (table များ၊ ရှုပ်ထွေးတဲ့ nested structure) တွေမှာ ပုံပျက်နိုင်ပါတယ်။ index မတည်ဆောက်ခင် ကျပန်း ၁၀ page စစ်ဆေးပြီး content ပြည့်စုံမှု သေချာစေပါ။
TheAI Academy သုံးသပ်ချက်
Firecrawl ရဲ့ positioning က အလွန် ရှင်းလင်းပြီး၊ နည်းနည်း ငြီးငွေ့စရာ ကောင်းလောက်အောင်တောင် ရှင်းပါတယ် - သူက "web page ကို သန့်ရှင်းတဲ့ text အဖြစ်" ပြောင်းတဲ့ ဒီ ခက်ခဲတဲ့အလုပ်ကို API အဖြစ် ထုပ်ပိုးထားတာဖြစ်ပြီး တခြား ရည်မှန်းချက် မရှိပါ။
ဒါပေမဲ့ ဒါက သူ အသုံးဝင်တဲ့ အကြောင်းရင်းပါ။ RAG လုပ်သူတိုင်း သိတာက အချိန်အကုန်ဆုံးက model ရွေးတာ ဒါမှမဟုတ် parameter ချိန်တာ ဘယ်တုန်းကမှ မဟုတ်ဘဲ data preprocessing ဖြစ်တယ်။ ဒီအပိုင်းကို outsource လုပ်လိုက်ရင် သင့်ရဲ့ အချိန်ကို တကယ် ကွာခြားစေတဲ့ နေရာမှာ သုံးနိုင်ပါတယ်။
သုံးသပ်ချက် - သူ ရောင်းတာက technology မဟုတ်ဘဲ crawler ကို ထိန်းသိမ်းစရာ မလိုတော့တဲ့ အဲဒီ တနင်္ဂနွေ ရက်တွေပါ။
Myanmar developer များအတွက် တိကျတဲ့ အကြံပြုချက် သုံးချက် ရှိပါတယ်။ ပထမ၊ အခမဲ့ တစ်ထောင် point နဲ့ process တစ်ခုလုံးကို အရင် run ပြီးမှ ငွေပေးဖို့ စဉ်းစားပါ၊ ဒီ quota က prototype validate လုပ်ဖို့ လုံလောက်ပါတယ်။ ဒုတိယ၊ "Map အရင် Crawl နောက်" ဆိုတဲ့ အကျင့်ကို မွေးပါ၊ ဒီ လုပ်ဆောင်ချက် တစ်ခုက point ဖြုန်းတီးမှု အများစုကို ချွေတာနိုင်ပါတယ်။ တတိယ၊ အရေးကြီးဆုံးက - Crawl မနှိပ်ခင် တစ်ဖက် website ရဲ့ robots.txt နဲ့ terms of service ကို ငါးမိနစ် အရင် ကြည့်ပါ။ technically လုပ်လို့ရတိုင်း ဥပဒေအရ လုပ်လို့ရတယ်လို့ မဆိုလိုပါ။
developer tool ပိုသိချင်ရင် AI developer tool directory မှာ ရှာနိုင်ပြီး၊ prompt template ကို ကိုးကားပြီး သင့်ရဲ့ data extraction prompt ကို ဒီဇိုင်းဆွဲနိုင်ပါတယ်။
မေးလေ့ရှိသောမေးခွန်းများ
အခမဲ့ quota က prototype လုပ်ဖို့ လုံလောက်လား
တစ်လ တစ်ထောင် point က page တစ်ထောင်လောက် scrape လုပ်နိုင်ပြီး prototype တည်ဆောက်ခြင်းနဲ့ process validate လုပ်ဖို့ လုံလောက်ပါတယ်။ ကန့်သတ်ချက်က concurrent request နှစ်ခုပဲ ရှိလို့ အစုလိုက် scrape လုပ်ရင် အရမ်း နှေးမှာပါ။ ငါးဆယ်ကနေ တစ်ရာ page အရင် scrape ပြီး quality သေချာမှ upgrade လုပ်မလား ဆုံးဖြတ်ဖို့ အကြံပြုပါတယ်။
ကိုယ်တိုင် crawler ရေးတာနဲ့ ယှဉ်ရင် ဘယ်အချိန် သုံးသင့်လဲ
structure တည်ငြိမ်တဲ့ website တစ်နှစ်ခုပဲ scrape လုပ်ရင် ကိုယ်တိုင်ရေးတာ ပိုသက်သာပါတယ်။ ဒါပေမဲ့ website များစွာ၊ JavaScript rendering နဲ့ anti-scraping mechanism ကို ရင်ဆိုင်ရတဲ့အခါ maintenance cost မြန်မြန် တက်လာပါတယ်။ engineer တွေ လစဉ် crawler ပြင်ဖို့ အချိန်ကုန်နေတာ တွေ့ရင် အဲဒါ ပြောင်းသင့်တဲ့ အချိန်ပါပဲ။
သူများ website ကို scrape လုပ်တာ တရားဝင်လား
tool က ကြားနေဖြစ်ပြီး တာဝန်က သုံးစွဲသူမှာ ရှိပါတယ်။ target website ရဲ့ robots.txt နဲ့ terms of service ကို လိုက်နာပါ၊ commercial အသုံးပြုမှုဆိုရင် copyright နဲ့ database right ကို အထူး သတိထားပါ။ ကိစ္စတိုင်းမှာ ဒေသန္တရ ဥပဒေ ကွဲပြားလို့ သံသယရှိရင် ဥပဒေ အကြံဉာဏ် ရယူပါ။
ဘာလို့ Map ကို အရင်သုံးပြီးမှ Crawl ကို သုံးရမလဲ
Map က point အနည်းငယ်နဲ့ website မှာ page ဘယ်နှစ်ခု ရှိသလဲ၊ structure ဘယ်လိုလဲ ပြောပြနိုင်ပါတယ်။ ဒီအဆင့် ကျော်ပြီး တိုက်ရိုက် Crawl လုပ်ရင် pagination ဒါမှမဟုတ် parameter combination ကြောင့် မျှော်လင့်ထားတာထက် အများကြီး ပိုတဲ့ page တွေ crawl မိပြီး တစ်ခါတည်း လစဉ် point ကုန်သွားနိုင်ပါတယ်။