- กล่าวถึงประสบการณ์การพัฒนา เว็บเสิร์ชเอนจินบนพื้นฐานของเอ็มเบดดิง 300 ล้านรายการ ภายใน 2 เดือน โดยมีจุดตั้งต้นจาก คุณภาพของเสิร์ชเอนจินที่ถดถอย และความก้าวหน้าของโมเดลเอ็มเบดดิงที่อิง Transformer
- ใช้อินฟราสตรักเจอร์และอัลกอริทึมสมรรถนะสูง เช่น คลัสเตอร์ GPU 200 ชุด, distributed crawler ขนาดใหญ่, RocksDB และ HNSW เพื่อทำให้ การค้นหาแบบเข้าใจภาษาธรรมชาติแบบเรียลไทม์ เป็นจริง
- มุ่งสู่ การตอบคำถามตามเจตนา แทนการจับคู่คีย์เวิร์ด พร้อมประยุกต์ใช้เทคนิค NLP/ML หลากหลายแบบ เช่น normalization, chunking, statement chaining เพื่อการพาร์สเอกสารและการรักษาบริบท
- แนะนำการออกแบบ distributed system ขนาดใหญ่ ในแต่ละชั้น เช่น pipeline, storage, service mesh, vector index รวมถึงแนวทางแก้คอขวดและการเพิ่มประสิทธิภาพต้นทุน
- สุดท้ายอธิบายว่าระบบได้กลายเป็นเสิร์ชเอนจินแบบปรับแต่งเฉพาะบุคคลที่มี latency ต่ำมาก, กระจายศูนย์ขนาดใหญ่ และมีความแม่นยำสูง
ภาพรวมและแรงจูงใจ
- ผู้เขียนตัดสินใจสร้างเสิร์ชเอนจินขึ้นใหม่ตั้งแต่ต้น ท่ามกลางปัญหาคุณภาพของเสิร์ชเอนจินที่ลดลง, SEO spam, การเพิ่มขึ้นของคอนเทนต์ที่ไม่เกี่ยวข้อง และในช่วงเวลาที่ โมเดลเอ็มเบดดิงที่อิง Transformer มีความสามารถในการเข้าใจภาษาธรรมชาติสูงขึ้น
- ข้อจำกัดของเสิร์ชเอนจินแบบเดิมเกิดจากการขาด ความสามารถในการเข้าใจคำถามในระดับมนุษย์ และการจับคู่แบบง่าย ๆ ที่อิงคีย์เวิร์ด
- เป้าหมายคือ การจัดอันดับตามเจตนา ที่ช่วยให้คอนเทนต์คุณภาพดีขึ้นมาอยู่ด้านบนได้เสมอ และยังสำรวจผลลัพธ์ส่วนลึกของ long tail ได้อย่างทั่วถึง
- กระบวนการสร้างเว็บเสิร์ชเอนจินครอบคลุมหลายศาสตร์ ทั้ง computer science, ภาษาศาสตร์, ontology, NLP, ML, distributed systems และ performance engineering
- โปรเจ็กต์นี้คือความท้าทายในการเริ่มต้นคนเดียวโดยไม่มีอินฟราสตรักเจอร์หรือประสบการณ์ล่วงหน้า และสร้างเสิร์ชเอนจินแบบใหม่ทั้งหมดให้เสร็จภายใน 2 เดือน
โครงสร้างระบบโดยรวม
- สร้าง text embedding จำนวน 300 ล้านรายการบนคลัสเตอร์ GPU 200 ชุดโดยอิง SBERT
- crawler หลายร้อยเครื่องทำงานพร้อมกัน เก็บข้อมูลได้ 50,000 หน้า/วินาที และสร้างดัชนีรวม 280 ล้านรายการ
- จัดเก็บและทำดัชนีด้วยการ shard RocksDB และ HNSW บนเครื่องที่มี 200 คอร์, RAM 4TB และ SSD 82TB
- กำหนดเวลาแฝงรวมของการตอบสนองต่อ query ไว้ที่ประมาณ 500ms
- โครงสร้างและลำดับการทำงานโดยรวมแยกเป็นส่วน crawler, pipeline, storage, ดัชนีเวกเตอร์เอ็มเบดดิง, service mesh และส่วน front/back-end
การทดลองและการปรับปรุงการค้นหาบนพื้นฐานเอ็มเบดดิง
Neural Embedding Playground
- การค้นหาด้วยโมเดลเอ็มเบดดิงอย่าง SBERT ได้รับการยืนยันผ่านการทดลองว่ามี ความเข้าใจ query และความแม่นยำที่เป็นธรรมชาติมากกว่า การค้นหาแบบยึดคีย์เวิร์ดเดิม
- สามารถทำความเข้าใจเจตนาของ query จากบริบทและระดับประโยค แล้วดึงคำตอบที่เกี่ยวข้องจริงออกมาได้
ตัวอย่างการค้นหาแบบดั้งเดิม vs. การค้นหาแบบนิวรัล
- การค้นหาแบบเดิม: ผลลัพธ์มีความสุ่ม และเน้นการตรงกันของคีย์เวิร์ด
- การค้นหาแบบเอ็มเบดดิง: เข้าใจบริบทและเจตนาของคำถาม พร้อมให้ผลลัพธ์ที่เน้นประโยคแกนหลักหรือแนวคิดที่ถูกต้อง
- สำหรับการผสมแนวคิดที่ซับซ้อน, คำถามแบบแฝง/ผสม และ query ที่มีสัญญาณด้านคุณภาพ สามารถค้นหาคำตอบที่ถูกต้องบนพื้นฐานของ ความหมาย ได้
การพาร์สเว็บเพจและการทำ normalization
-
ตั้งเป้าดึงเฉพาะ องค์ประกอบข้อความเชิงความหมาย จาก HTML และทำ normalization เพื่อตัด noise อย่างเลย์เอาต์หรือองค์ประกอบควบคุมออก
-
รักษาโครงสร้างของตารางตามมาตรฐานอย่าง WHATWG, MDN โดยรองรับ p, table, pre, blockquote, ul, ol, dl เป็นต้น
-
ลบองค์ประกอบ chrome ของหน้าเว็บ เช่น เมนู, navigation, ความคิดเห็น และอินเทอร์เฟซ ออกทั้งหมด
-
ใช้กฎพิเศษรายเว็บไซต์ (เช่น en.wikipedia.org) เพื่อแก้ปัญหาการดึงข้อมูลมากเกินไปหรือน้อยเกินไป
-
ยังสามารถใช้ structured data เชิงความหมาย (เช่น meta, OpenGraph, schema.org) เพื่อสร้าง knowledge graph และปรับปรุง ranking ได้ด้วย
Chunking และการรักษาบริบท
การทำ chunking ระดับประโยค
- เพื่อก้าวข้ามข้อจำกัดของโมเดลเอ็มเบดดิง จึงใช้ การทำ chunking แบบอิงประโยค แทนการใช้ทั้งหน้าเว็บ
- ระหว่างทำ chunking มีการใช้ spaCy sentencizer เพื่อแยกขอบเขตประโยคอย่างแม่นยำ โดยคำนึงถึงกรณีต่าง ๆ เช่น ขอบเขตประโยคตามธรรมชาติ, ไวยากรณ์, คำย่อ, URL และสำนวนไม่เป็นทางการ
การรักษาและการเชื่อมโยงบริบท
- วิเคราะห์ ความสัมพันธ์พึ่งพาระหว่างประโยค, heading, paragraph, table ฯลฯ แล้วนำข้อมูลบริบทมาเชื่อมรวมกับเอ็มเบดดิงด้วย
- ตัวอย่างเช่น โครงสร้างตารางก็ถูกแทรกโดยเชื่อม heading/ข้อกำหนดระดับบนอย่างต่อเนื่อง เพื่อไม่ให้ความหมายของแต่ละแถวสูญหาย
การเชื่อมประโยค (Statement Chaining)
- ใช้ DistilBERT classifier วิเคราะห์ประโยคหนึ่งร่วมกับประโยคก่อนหน้า เพื่อทำ การตรวจสอบการพึ่งพาบริบทและการดึง chain โดยอัตโนมัติ
- ตอนสร้างเอ็มเบดดิง จะรวมประโยคที่เป็นตัวพึ่งพาระดับบนทั้งหมดเข้าไปด้วย เพื่อเพิ่มความสามารถในการรักษาบริบท
ผลการใช้งานต้นแบบ
- จากการทดลอง query ใช้งานจริงหลากหลายในสภาพแวดล้อม sandbox พบว่าได้ การตอบคำถามที่แม่นยำกว่ามาก (ตรงบริบท) เมื่อเทียบกับวิธีเดิม
- แม้จะเป็นกรณีคีย์เวิร์ดไม่ตรง, การละคำ, อุปมา หรือคำถามแบบผสม แอปก็ยังเข้าใจเจตนาและจับคู่กับประโยคบริบทที่ถูกต้องได้ พร้อมทั้งค้นพบความรู้และความสัมพันธ์ที่ซ่อนอยู่ได้อย่างมีประสิทธิภาพ
เว็บครอว์เลอร์ขนาดใหญ่ (อิงโหนด)
- พิจารณาทั้งเรื่องเสถียรภาพและประสิทธิภาพหลายด้าน เช่น work stealing สำหรับกระจายงาน, การควบคุม concurrency/traffic รายโดเมน, การตรวจสอบ DNS/URL/header
- crawler ใช้ Promise แบบ asynchronous I/O, กลไกที่ทนต่อ DDoS, การจัดการทรัพยากร (หน่วยความจำ, delay, backoff) และการตรวจจับโดเมนที่มี noise
- ดำเนินการเสริมความเข้มแข็งในการกรอง URL ซ้ำซ้อน/ผิดปกติ ผ่าน URL normalization, การจำกัด protocol และ port/user info รวมถึง canonicalization
Pipeline (distributed task queue)
- จัดการสถานะของแต่ละหน้าผ่าน PostgreSQL และในช่วงแรกใช้ polling/transaction โดยตรง
- เมื่อเข้าสู่สภาพแวดล้อม distributed ขนาดใหญ่ (crawler หลายพันตัว) เกิดปัญหาเรื่องการสเกลและคอขวดของคิว/lock จึงเปลี่ยนไปใช้ coordinator แบบ in-memory ที่พัฒนาด้วย Rust เพื่อจัดการสถานะคิว
- โครงสร้าง task ประกอบด้วย indexing หลายรูปแบบ เช่น ดัชนีบนพื้นฐาน hash map, binary heap, domain group, random poll และการสลับตำแหน่งด้วย
swap_remove - ใช้หน่วยความจำเพียงระดับ 100B ต่อ task ทำให้เซิร์ฟเวอร์ 128GB สามารถรองรับได้ถึง 1B task
- หลังจากนั้นยังพัฒนา queue แบบ open source ที่ใช้ RocksDB แทน SQS และรองรับ 300,000 ops/วินาทีบน 1 โหนด
การออกแบบ storage (Oracle → PostgreSQL → RocksDB)
- ระยะแรกใช้ Oracle Cloud (egress/พื้นที่จัดเก็บต้นทุนต่ำ) และภายหลังใช้ PostgreSQL (TOAST) แต่ก็เจอ ข้อจำกัดด้านการขยายการเขียนและประสิทธิภาพ
- ด้วยลักษณะของ PostgreSQL เช่น MVCC, write amplification และ WAL จึงเกิดคอขวดเมื่อทำ INSERT แบบขนานจำนวนมาก และสุดท้ายเปลี่ยนไปใช้ RocksDB ซึ่งเป็น KV store
- ใช้ความสามารถของ RocksDB เช่น การเก็บ blob แยกต่างหาก (BlobDB), ไฟล์ SST, multi-thread และ hash indexing เพื่อดึงสมรรถนะสูงสุดของ NVMe SSD
- ขยายเป็น 64 RocksDB shard โดยแต่ละ shard route ด้วย
xxHash(key)และใช้การ serialize ด้วย Serde+MessagePack - ในที่สุดรองรับการประมวลผล 200,000 ops/วินาทีจากไคลเอนต์หลายพันตัว (crawler/parser/vectorizer) พร้อมจัดเก็บ meta และ blob แยกกันพร้อมบีบอัด
Service mesh และเครือข่าย
- เมื่อโครงสร้างพื้นฐานขยายตัว จึงออกแบบบนพื้นฐาน mTLS+HTTP2 เพื่อรองรับ การค้นหา service instance อัตโนมัติและความปลอดภัยในการสื่อสาร
- ใช้ใบรับรองที่อิง root CA ในแต่ละ node, ใช้การ serialize ด้วย MessagePack โดยตรง และพัฒนา internal DNS, CoreDNS และ client SDK แบบ custom
- แม้เคยมีประสบการณ์ใช้ VPN อย่าง ZeroTier และ Tailscale มาก่อน แต่ด้วยปัญหาด้านเครือข่าย, ประสิทธิภาพ และการปฏิบัติการ จึงเลือก HTTP+mTLS ด้วยตนเอง
- รวมการจัดการผ่าน system service control (
systemd + cgroup + journald) เพื่อให้ทั้งเบาและเป็นมาตรฐานมากขึ้น
Pipeline สำหรับสร้างเอ็มเบดดิงบน GPU ขนาดใหญ่
- ในช่วงแรกใช้ OpenAI API และย้ายไปยังสภาพแวดล้อม GPU สมรรถนะสูงอย่าง Runpod ในภายหลังเพราะปัญหาด้านต้นทุน
- pipeline แยกแต่ละ stage แบบ asynchronous ทำให้ใช้ GPU ได้เกิน 90% และสร้าง embeddings ได้ 100,000 รายการ/วินาทีบน GPU 250 ตัว
- ใช้ Rust pipeline และ Python inference แล้วทำ IPC ผ่าน named pipe พร้อม backpressure แบบมีโครงสร้างเพื่อปรับทรัพยากรอัตโนมัติ
การทำ vector indexing (HNSW/sharding)
- ใช้ อัลกอริทึม HNSW สำหรับ vector search บนหน่วยความจำ และใช้ ANN (Approximate Nearest Neighbor) เพื่อให้ได้ latency ต่ำมาก
- เมื่อถึงขีดจำกัดของ RAM จึงทำการ shard แบบกระจายเท่า ๆ กันตามโหนด (64 โหนด) โดยแต่ละ shard ค้นหาแบบขนานด้วย HNSW index ของตัวเอง
- เนื่องจาก HNSW ต้องใช้ RAM จำนวนมากและมีข้อจำกัดด้าน live update จึงย้ายไปใช้ vector DB แบบ open source ที่อิงดิสก์ชื่อ CoreNN ในที่สุด
- CoreNN สามารถค้นหา 3B embeddings ได้อย่างแม่นยำสูงแม้บนโหนดเดี่ยวที่มี RAM 128GB
UX ของเสิร์ชเอนจินและการปรับ latency
- UX ของเสิร์ชเอนจินให้ความสำคัญกับ การตอบสนองแบบฉับไว (ไม่มี load indicator, ใช้ SSR แบบดั้งเดิม)
- ใช้ Cloudflare Argo ฯลฯ เพื่อเข้าใกล้ edge PoP และเลือกใช้ HTTP/3 เพื่อลด latency การส่งข้อมูลให้ต่ำที่สุด
- เตรียมข้อมูลทั้งหมดตั้งแต่ระดับ app server เพื่อลด API roundtrip รายจุด และตอบกลับหน้าที่ถูก minify และบีบอัดแล้วในทันที
สรุปนี้อธิบายอย่างเป็นรูปธรรมว่าเว็บเสิร์ชเอนจินขนาดใหญ่ที่ใช้เทคโนโลยีล่าสุดด้านการประมวลผลภาษาธรรมชาติและ ML สามารถถูกสร้างแบบ end-to-end ภายใน 2 เดือนได้อย่างไร พร้อมครอบคลุมประเด็นสำคัญด้านการออกแบบและการเพิ่มประสิทธิภาพทั้งในระดับระบบ อัลกอริทึม และอินฟราสตรักเจอร์
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
น่าทึ่งที่โมเดล embedding รุ่นล่าสุดของ OpenAI ให้ต้นทุนสำหรับ batch inference ต่ำมากที่ $0.0001 ต่อ 1 ล้านโทเคน พอลองคำนวณดูแล้วแม้จะทำ embedding ให้ 1 พันล้านหน้า ๆ ละ 1,000 โทเคน ก็ยังเสียรวมแค่ $100 เท่านั้น ถ้ารัน inference เองบน GPU แบบ spot ของ Runpod จะยังแพงกว่านี้ราว 100 เท่า ยังไม่รวมค่า API อื่น ๆ เลย เลยอดสงสัยไม่ได้ว่านี่อาจเป็นกลยุทธ์แบบ honeypot ของ OpenAI เพื่อดึงข้อมูลต้นทางที่เฉพาะทางตามโดเมนหรือเปล่า
ตอนท้ายบทความพูดถึงการเพิ่มข้อมูลจาก Common Crawl คิดว่าข้อมูลการจัดอันดับที่อิง web graph ของทีมเราน่าจะช่วยได้มากในการเลือกว่าจะ crawl หน้าไหน น่าสนใจดีที่ได้เห็นตัวอย่างระดับใหญ่แบบนี้ และก็แปลกใจที่ vector database คุ้มค่าต้นทุนกว่าที่คิด
ขอชื่นชมจากใจจริง บทความก็เรียบเรียงได้ดีอย่างน่าทึ่ง เห็นด้วยว่าหัวใจของ search engine คือข้อมูลที่ผ่านการคัดและกรองมาแล้วอย่างดี (ใส่ขยะเข้าไปก็ได้ขยะออกมา) และยิ่งทำให้รู้สึกอีกครั้งว่าแม้แต่ในการฝึก LLM ข้อมูลคุณภาพสูงปริมาณน้อยก็สำคัญกว่าในท้ายที่สุด เลยอดสงสัยไม่ได้ว่าถ้าให้ LLM ตรวจทุกคอนเทนต์เพื่อสร้าง search engine จะได้ประสิทธิภาพขนาดไหน
น่านับถือจริง ๆ การเอาเทคโนโลยีมากขนาดนี้มาประกอบให้ทำงานร่วมกันได้เป็นเรื่องใหญ่ คิดว่าคุณค่าชี้ขาดของ search engine อยู่ที่ตัว ranking algorithm จริง ๆ ยังไม่ค่อยเข้าใจว่าในโปรเจกต์นี้ LLM ถูกใช้กับ ranking อย่างไร เทคนิคจัดอันดับแบบเก่าอย่างหนึ่งคือเก็บข้อมูลการค้นหาแล้วคลิกของผู้ใช้จริง ซึ่งก็คือข้อมูล train แบบคำค้นของมนุษย์ → ลิงก์ที่คลิก แค่มีคลิกไม่กี่ครั้งอันดับก็ดีขึ้นอย่างเห็นได้ชัด ถ้าเอาข้อมูลนี้เข้า neural net ก็สามารถแปลงเป็นปัญหา classification เพื่อปรับ ranking ได้ และยิ่งมีคนคลิกมากน้ำหนักก็ยิ่งสูง
พูดได้แค่ว่าน่าทึ่งจริง ๆ และมันทำงานได้ดีพอตัว ถ้าสมมติว่ามีคน 10,000 คนสมัครเดือนละ $5 แล้วครอบคลุมค่าใช้จ่ายได้ search engine ที่ชุมชนช่วยกันสนับสนุนก็ดูไม่ใช่เรื่องเพ้อฝันนัก
สำหรับคนที่รู้จัก encoder-only LLM ก็ชัดเจนว่า Google แทบจะจบแล้ว ที่ Google ยังยืนอยู่ได้เพราะการ crawl เว็บทั้งโลกและทำดัชนีให้สดใหม่ตลอดนั้นใช้เวลานาน ถ้าองค์กรเปิดอย่าง Common Crawl หรือบริการแบบเสียเงินแก้ปัญหาเว็บครอลแบบเรียลไทม์ได้ กำแพงป้องกันที่ Google สร้างมา 25 ปีก็จะพังลง และการค้นหาก็จะถูกทำให้เสมอภาคมากขึ้น
ยิ่งไปกว่านั้น ตอนนี้เรากำลังเห็นการแทนที่ฟังก์ชันต่าง ๆ ของ big tech แบบเรียลไทม์อยู่แล้ว และด้วยโมเดล อุปสรรคทางเทคโนโลยีของบริษัทต่าง ๆ ก็ลดลงมาก
ไม่เคยจินตนาการมาก่อนเลยว่าคนคนเดียวจะสร้างอะไรไปได้ไกลขนาดนี้ ดูเหมือนห่างจาก search engine เชิงพาณิชย์ไม่มากแล้ว อาจจะถึงขั้นอยู่ในระยะที่ Google ต้องตามด้วยซ้ำ แค่ $50,000 ต่อปีก็ทำได้แล้วนี่ถูกจนน่าเหลือเชื่อ ถึงขั้นอยากส่ง seed money ให้เดี๋ยวนี้เลย
เป็นโปรเจกต์ที่เจ๋งมาก ลองถามคำถามที่ search engine ดัง ๆ มักให้ผลไม่ดีนักเหมือนกัน เช่น ตัวเลือกจอ ultrawide ความละเอียดสูงที่น่าแนะนำ แต่ที่นี่ก็ยังมีอาการที่หน้า meta ซึ่งเก่งแค่จัดอันดับขนาดใหญ่ขึ้นมาก่อนหน้าที่มีข้อมูลเชิงลึกจริง ๆ ดูเหมือนจะยึดติดกับ ranking มากเกินไป ถ้าฉันจะหาคำตอบเองก็คงคัด hardware forum กับ blog สักสองสามแห่งมาเทียบสเปก ข้อดีข้อเสียอย่างละเอียด สำหรับกรณีพิเศษแบบนี้ การให้คะแนนสูงกับเว็บที่อ้างอิงข้อมูลเฉพาะเจาะจงน่าจะสมเหตุสมผลกว่า เพราะในมุมผู้ใช้ ฉันอยากเห็นแหล่งข้อมูลต้นทางที่ใช้ในการวิเคราะห์ แต่ search engine จริง ๆ มักไม่ได้ยกหลักฐานจากล่างขึ้นบนแบบนี้
คิดว่าเจ๋งมาก ตอนแรกกะว่าจะลองแทนทั้งหมดด้วยสิ่งนี้เลย แม้อาจจะเสียเวลาไปบ้างแต่ก็จะลองค้นหลาย ๆ แบบแล้วกลับมาเล่าความเห็นให้ฟัง โดยรวมมันพาไปในทางที่เกือบถูกอยู่มาก แต่ยังไม่ถึง 100% เช่น ตอนพยายามหา fediverse ด้วยคำว่า lemmy กลับได้หน้าของ liberapay ขึ้นมา ขอให้ทำตามที่สัญญาไว้เรื่องเชื่อมกับ Common Crawl และอยากให้ดูแหล่งอื่นอย่าง archive.org ด้วย มีเงินหลายพันล้านไหลเข้าอุตสาหกรรม AI แต่หวังว่าการทดลองแบบนี้จะเดินหน้าและสำเร็จได้จริง ไม่ว่าจะด้วยการระดมทุนจากชุมชนหรือการแชร์งานกัน ตรงไปตรงมาคือหลายคนเริ่มเหนื่อยกับสภาพเกือบผูกขาดของ search engine ตอนนี้ เท่าที่รู้ Ecosia ก็กำลังเตรียม search engine ของตัวเองอยู่เหมือนกัน หวังว่าจะร่วมมือกับโปรเจกต์นี้หรือได้ความช่วยเหลือจากมัน ฉันอยากได้ search engine แบบ decentralized จริง ๆ เข้าใจว่าการทำ open source ยังลังเลเพราะเรื่องความยั่งยืน แต่ก็อึดอัดที่เห็นเงินมหาศาลถูกใช้ไปแทบไร้ความหมาย ทั้งที่โปรเจกต์นี้มีศักยภาพมาก เลยหวังจริง ๆ ว่าจะ open source มัน เชื่อว่าชุมชนสุดท้ายจะหาวิธีทำให้ยั่งยืนได้ผ่าน crowdfunding หรือวิธีอื่น ๆ ยังอ่านโพสต์ไม่จบด้วยซ้ำ แต่ตื่นเต้นเกินกว่าจะรอเลยไปลองใช้ก่อน ตัวบทความเองก็ลงลึกมากและคิดว่าวิธีแบบนี้น่าจะเป็นประโยชน์อ้างอิงให้คนอื่นได้มาก พูดตามตรงมันเหมือนเวทมนตร์ และไม่ได้รู้สึกตื่นเต้นกับโปรเจกต์อะไรตั้งแต่ต้นจนจบแบบนี้มานานแล้ว เข้าใจว่าการทำ open source ยาก และก็รู้ภูมิหลังว่าอยู่ในประเทศโลกที่สาม แต่ฉันยินดีบริจาคเงินตัวเองสัก $50 จริง ๆ ขนาดคนที่ไม่เคยจ่ายเงินออนไลน์สักครั้งอย่างฉันยังอยากสนับสนุนขนาดนี้ เพราะงั้นหวังว่าจะใช้ Common Crawl และทำสิ่งนี้ร่วมกับชุมชนจริง ๆ ขอเป็นกำลังใจให้ทั้งโปรเจกต์และเส้นทางอาชีพอย่างจริงใจ
เป็นหนึ่งในบทความที่ให้มุมมองลึกซึ้งที่สุดที่ได้อ่านช่วงนี้ ชอบมากที่อธิบายรายละเอียดทั้งองค์ประกอบที่เลือกใช้เพื่อลดต้นทุนและจุดที่ประหยัดได้จริง แม้จะโฟกัสที่ neural search แต่ก็อยากรู้ว่าเคยลอง hybrid search ที่ผสม BM-25 + embedding หรือไม่ และอยากถามด้วยว่า reranking model แบบไหนที่มีประโยชน์และมีประสิทธิภาพที่สุด
เป็นประสบการณ์ที่เล่าได้น่าสนใจมาก ฉันเองก็กำลังพัฒนาของคล้าย ๆ กันเพื่อใช้ค้นหาธุรกิจ เลยเจอความท้าทายคล้ายกันเยอะ หลายคนคิดว่าการ crawl/process/index ทำได้ง่าย แต่การทำให้คุ้มค่าต้นทุนในระดับใหญ่เป็นอีกเรื่องโดยสิ้นเชิง ขอยกย่อง wilsonzlin อยากคุยแลกเปลี่ยนเรื่องพวกนี้ด้วย คนที่สร้างสิ่งแบบนี้เองตั้งแต่ต้นจนจบมีน้อยมากจริง ๆ