สอนใช้ Firecrawl ฉบับสมบูรณ์: เปลี่ยนเว็บไซต์ใด ๆ ให้เป็น Markdown ที่ LLM อ่านเข้าใจ

ใครเคยทำ RAG ย่อมเข้าใจความหงุดหงิดแบบนั้น คุณใช้เวลาสองชั่วโมงเลือกโมเดล ตั้งฐานข้อมูลเวกเตอร์ สุดท้ายกลับมาติดที่ปัญหาโง่ ๆ ข้อหนึ่ง คือหน้าเว็บที่ดึงกลับมามีแถบเมนู มีโฆษณา มีแบนเนอร์ยินยอมคุกกี้ และครึ่งหนึ่งของหน้าดึงด้วย requests กลับมาได้แค่โครงเปล่า เพราะเนื้อหาถูกเรนเดอร์ด้วย JavaScript

Firecrawl คือเครื่องมือที่แก้ตรงส่วนนี้โดยเฉพาะ

Firecrawl คืออะไร

Firecrawl คือ API สำหรับดึงข้อมูลจากหน้าเว็บ ออกมาจาก Y Combinator ทางการวางตัวเองว่าเป็น "วิธีที่ง่ายที่สุดในการดึงบริบทจากเว็บ" คุณโยน URL เข้าไป มันคืน Markdown ที่สะอาดกลับมา โฆษณา เมนู สคริปต์ ถูกลบหมด เหลือแต่เนื้อหาที่มีความหมาย

ความต่างที่ใหญ่ที่สุดจากการเขียน crawler เองมีสองอย่าง หนึ่ง มันจัดการการเรนเดอร์ด้วย JavaScript คือรันหน้าให้เสร็จก่อนแล้วค่อยดึงเนื้อหา ซึ่งแก้สาเหตุการดึงล้มเหลวที่พบบ่อยที่สุดของเว็บไซต์สมัยใหม่ สอง ฟอร์แมตผลลัพธ์เป็นแบบที่ป้อนโมเดลภาษาขนาดใหญ่ได้เลย ไม่ต้องเขียนตรรกะทำความสะอาดอีกกอง

มันทำอะไรได้บ้าง

ปัจจุบันทางการมีเอนด์พอยต์เจ็ดแบบ แต่ละแบบตรงกับสถานการณ์การใช้ต่างกัน:

เอนด์พอยต์	ใช้ทำอะไร	การคิดพอยต์
Scrape	ดึงหน้าเดียว	หน้าละ 1 พอยต์
Crawl	ไล่ดึงทั้งเว็บไซต์แบบเวียนซ้ำ	หน้าละ 1 พอยต์
Map	ดึงโครงสร้างหน้าของเว็บไซต์อย่างรวดเร็ว	หน้าละ 1 พอยต์
Search	ค้นเว็บแล้วดึงเนื้อหากลับ	ทุก 10 ผลลัพธ์ 2 พอยต์
Interact	ทำอัตโนมัติบนเบราว์เซอร์ จัดการล็อกอินและการโต้ตอบ	นาทีละ 2 พอยต์
Monitor	ติดตามการเปลี่ยนแปลงของหน้า	ตรวจครั้งละ 1 พอยต์
Agent (พรีวิว)	ผสานกับ AI Agent	คิดราคาแบบไดนามิก ฟรีวันละ 5 ครั้ง

แพ็กเกจแบ่งเป็นหกระดับคือ Free, Hobby, Standard, Growth, Scale และ Enterprise แพ็กเกจฟรีให้เดือนละหนึ่งพันพอยต์ คำขอขนานสองรายการ คิดแบบจ่ายรายปีคำนวณได้ว่า Hobby ราวเดือนละ 16 ดอลลาร์สหรัฐ ได้ห้าพันพอยต์ Standard ราว 83 ดอลลาร์สหรัฐ ได้แสนพอยต์ Growth ราว 333 ดอลลาร์สหรัฐ ได้ห้าแสนพอยต์ Scale ราว 599 ดอลลาร์สหรัฐ ได้หนึ่งล้านพอยต์ แพ็กเกจแบบบริการตัวเองทั้งหมดรองรับการเติมพอยต์อัตโนมัติเป็นก้อนละห้าดอลลาร์เมื่อพอยต์หมด

วิธีใช้: จากสมัครจนถึงดึงครั้งแรก

ขั้นที่หนึ่ง: สมัครรับ API Key

สมัครที่ firecrawl.dev แพ็กเกจฟรีไม่ต้องใช้บัตรเครดิต หลังล็อกอินรับ API Key ได้ในแดชบอร์ด อย่าลืมเก็บไว้ในตัวแปรสภาพแวดล้อม อย่าเขียนตายตัวในโค้ด

ขั้นที่สอง: ดึงหน้าแรก

วิธีง่ายที่สุดคือเอนด์พอยต์ Scrape โยน URL หนึ่ง ระบุว่าต้องการฟอร์แมต Markdown กลับมาก็เป็นเนื้อหาที่สะอาด ในทางปฏิบัติคุณจะได้สองอย่าง ฟิลด์ markdown คือเนื้อหาหลัก ฟิลด์ metadata มีข้อมูลอย่างชื่อเรื่อง คำอธิบาย ภาษา อย่างหลังมีประโยชน์มากตอนสร้างดัชนี อย่ามองข้าม

ขั้นที่สาม: ไล่ดึงทั้งเว็บไซต์

เอนด์พอยต์ Crawl จะเริ่มจาก URL ตั้งต้นที่คุณให้ แล้วไล่ตามลิงก์แบบเวียนซ้ำ ตรงนี้มีพารามิเตอร์ที่ต้องตั้งแน่ ๆ หลายตัว:

• เพดานจำนวนหน้า: ถ้าไม่ตั้ง เว็บไซต์ใหญ่ ๆ หนึ่งเว็บกินพอยต์ทั้งเดือนของคุณได้สบาย
• ข้อจำกัดเส้นทาง: ไล่ดึงเฉพาะใต้ /docs/ อย่าไปไล่บล็อกและหน้าแนะนำบริษัท
• กฎการยกเว้น: ตัดหน้าล็อกอิน หน้าผลการค้นหา ที่ไม่มีคุณค่าออก

นิสัยของผมคือใช้เอนด์พอยต์ Map ดูโครงสร้างเว็บไซต์ก่อนสักครั้ง ยืนยันจำนวนหน้ารวมว่าอยู่ในช่วงที่สมเหตุสมผล แล้วค่อยตัดสินว่าจะรัน Crawl หรือไม่ ขั้นนี้เลี่ยงอุบัติเหตุพอยต์ได้เกือบหมด

ขั้นที่สี่: ต่อเข้ากับเวิร์กโฟลว์ RAG ของคุณ

หลังได้ Markdown มา กระบวนการมาตรฐานคือ ตัดเป็นก้อน (chunking) แปลงเป็นเวกเตอร์ เก็บเข้าฐานข้อมูลเวกเตอร์ Markdown ของ Firecrawl รักษาลำดับชั้นของหัวข้อไว้ ซึ่งเป็นมิตรเป็นพิเศษกับกลยุทธ์ใช้หัวข้อเป็นขอบเขตการตัดก้อน เทียบกับ HTML ที่แปลงเป็นข้อความล้วนแล้วเละเป็นก้อนโคลน คุณภาพต่างกันมาก

เทคนิคขั้นสูง

Map ก่อน Crawl เสมอ นี่คือจุดที่ผมอยากเน้นที่สุด Map ใช้พอยต์น้อยมากก็บอกได้ว่าเว็บไซต์นี้มีกี่หน้า โครงสร้างเป็นอย่างไร การข้ามขั้นนี้ไปรัน Crawl ตรง ๆ คือวิธีเผาพอยต์ที่พบบ่อยที่สุด

ใช้การดึงแบบมีโครงสร้างแทนการเขียนพาร์เซอร์เอง Scrape รองรับการระบุ schema ให้โมเดลดึงเนื้อหาหน้าออกเป็นฟิลด์ที่คุณต้องการโดยตรง (เช่น ชื่อสินค้า ราคา สถานะสต็อก) ซึ่งเสถียรกว่าดึง Markdown กลับมาแล้วเขียน regular expression เอง โดยเฉพาะตอนหน้าเว็บเปลี่ยนดีไซน์

จำนวนขนานคือคอขวดจริง เวอร์ชันฟรีมีคำขอขนานแค่สองรายการ ดึงหนึ่งพันหน้าจะช้ามาก หากคุณกำลังพิสูจน์ต้นแบบ ดึงห้าสิบหน้ายืนยันว่ากระบวนการใช้ได้ก่อนก็พอ อย่าเริ่มด้วยการรันทั้งเว็บ

Monitor เหมาะกับการติดตามคู่แข่ง หากคุณต้องเฝ้าดูการเปลี่ยนแปลงของหน้าราคาหรือหน้าสินค้าของคู่แข่ง เอนด์พอยต์ Monitor สะดวกกว่าตั้งเวลารัน Scrape เอง และตรวจแต่ละครั้งคิดแค่พอยต์เดียว

ใช้ร่วมกับเครื่องมือสังเกตการณ์ หากเวิร์กโฟลว์ RAG ของคุณต่อกับ Helicone หรือ Langfuse อย่าลืมบันทึก URL ต้นทางที่ดึงมาไว้ด้วย ภายหลังเวลาไล่หาว่า "ทำไมโมเดลตอบผิด" แปดในสิบปัญหาอยู่ที่ข้อมูลต้นทาง ไม่ใช่โมเดล

ข้อควรระวัง

เส้นทางกฎหมายต้องคิดให้ชัดก่อน นี่คือส่วนที่ผมคิดว่าสำคัญที่สุด ตัว Firecrawl เองเป็นกลาง แต่ความรับผิดชอบทางกฎหมายของการดึงข้อมูลอยู่ที่ผู้ใช้ ต้องปฏิบัติตาม robots.txt และเงื่อนไขบริการของเว็บไซต์เป้าหมาย การใช้เชิงพาณิชย์ยิ่งต้องระวังเรื่องลิขสิทธิ์และสิทธิในฐานข้อมูล กฎหมายลิขสิทธิ์ของไทยมีข้อกำหนดชัดเจนเรื่องการทำซ้ำ การดึงเนื้อหาคนอื่นมาทั้งก้อนใส่ในผลิตภัณฑ์ของตัวเองความเสี่ยงไม่ต่ำ เมื่อมีข้อสงสัยให้ขอความเห็นทางกฎหมาย อย่าคิดแบบ "เดี๋ยวใคร ๆ ก็ดึงกันทั้งนั้น"

การใช้พอยต์ประเมินล่วงหน้ายาก เว็บไซต์เอกสารที่ดูเหมือนมีแค่สามสิบหน้า อาจขยายเป็นสามร้อยหน้าเพราะการแบ่งหน้าและการรวมพารามิเตอร์ การตั้งเพดานจำนวนหน้าเป็นการป้องกันตัวที่จำเป็น

ไม่ใช่ทุกเว็บไซต์จะดึงได้ เว็บไซต์ที่ต้องล็อกอิน มีกลไกกันบอทเข้มงวด หรือห้ามการเข้าถึงอัตโนมัติชัดเจน เอนด์พอยต์ Interact จัดการสถานการณ์การโต้ตอบได้ส่วนหนึ่ง แต่ไม่ใช่ยาสารพัดนึก เจอเว็บที่ดึงไม่ได้ ตรวจก่อนว่าเจ้าของตั้งใจกันหรือไม่ ถ้าใช่ นั่นคือเขากำลังบอกคุณว่าอย่าดึง

คุณภาพผลลัพธ์ยังต้องสุ่มตรวจ การแปลงเป็น Markdown ทำได้ดีบนเว็บไซต์ส่วนใหญ่ แต่หน้าที่จัดวางพิเศษ (ตารางจำนวนมาก โครงสร้างซ้อนซับซ้อน) อาจเพี้ยนได้ ก่อนสร้างดัชนีสุ่มตรวจสักสิบหน้าก่อน ยืนยันว่าเนื้อหาครบถ้วน

ความเห็นจาก TheAI Academy

จุดยืนของ Firecrawl ชัดเจนมาก ชัดจนออกจะน่าเบื่อ มันก็แค่ห่อหุ้มงานหนักอย่าง "แปลงหน้าเว็บเป็นข้อความสะอาด" ให้เป็น API ไม่มีความทะเยอทะยานอื่น

แต่นี่แหละคือเหตุผลที่มันใช้ดี คนทำ RAG ต่างรู้ดีว่าสิ่งที่กินเวลามากที่สุดไม่เคยเป็นการเลือกโมเดลหรือปรับพารามิเตอร์ แต่คือการเตรียมข้อมูลก่อนประมวลผล จ้างส่วนนี้ออกไปข้างนอก เวลาของคุณจะได้ทุ่มลงในจุดที่สร้างความแตกต่างจริง ๆ

ความเห็น: สิ่งที่มันขายไม่ใช่เทคโนโลยี แต่คือวันหยุดสุดสัปดาห์ที่คุณไม่ต้องมานั่งซ่อม crawler อีกต่อไป

คำแนะนำที่เป็นรูปธรรมสำหรับนักพัฒนาในไทยมีสามข้อ หนึ่ง ใช้พอยต์ฟรีหนึ่งพันรันทั้งกระบวนการให้ผ่านก่อนค่อยพิจารณาจ่ายเงิน โควตานี้พอสำหรับพิสูจน์ต้นแบบ สอง สร้างนิสัย "Map ก่อน Crawl" การกระทำเดียวนี้ประหยัดพอยต์ที่สูญเปล่าไปได้เกินครึ่ง สาม และสำคัญที่สุด ก่อนกด Crawl ใช้เวลาห้านาทีดู robots.txt และเงื่อนไขบริการของเว็บไซต์เป้าหมายก่อน ทำได้ในทางเทคนิค ไม่ได้แปลว่าทำได้ในทางกฎหมาย

เครื่องมือสำหรับนักพัฒนาเพิ่มเติมหาได้ที่ ไดเรกทอรีเครื่องมือสำหรับนักพัฒนา AI และดู เทมเพลตพรอมป์ เพื่อออกแบบพรอมป์การดึงข้อมูลของคุณ