สร้างระบบค้นหาเอกสารวิจัยทรงพลังด้วย Hugging Face: เบื้องหลัง Papers with Code

สร้างระบบค้นหาเอกสารวิจัยทรงพลังด้วย Hugging Face: เบื้องหลัง Papers with Codeการเข้าถึงงานวิจัยทางวิทยาศาสตร์เป็นสิ่งสำคัญยิ่งในยุคปัจจุบัน โดยเฉพาะอย่างยิ่งสำหรับวงการ AI ที่มีการพัฒนาอย่างรวดเร็ว การมีระบบค้นหาที่มีประสิทธิภาพจึงเป็นหัวใจหลักที่ช่วยให้นักวิจัยและผู้ที่สนใจสามารถค้นหาข้อมูลที่เกี่ยวข้องได้อย่างรวดเร็ว ทั้งผ่านเว็บไซต์หรือเครื่องมือ command-line Papers with Code (PwC) คือหนึ่งในแพลตฟอร์มที่มุ่งมั่นทำให้งานวิจัย AI เป็นที่เข้าถึงได้ง่ายขึ้น ด้วยการพัฒนาระบบค้นหาที่ผสานจุดแข็งของเทคนิคการค้นหาแบบดั้งเดิมและแบบใช้เวกเตอร์เข้าด้วยกันทำไมการค้นหางานวิจัยจึงแตกต่าง?การค้นหางานวิจัยนั้นซับซ้อนกว่าการค้นหาข้อความทั่วไป เพราะระบบที่ดีควรจะสามารถ:ค้นหาชื่อเรื่องหรือรหัส arXiv ที่ถูกต้องได้เข้าใจความหมายของคำถาม เช่น "small language models for code generation" แม้ว่าคำเหล่านั้นจะไม่ได้ปรากฏอยู่ด้วยกันในเอกสารจดจำคำค้นที่ต้องการนำทาง เช่น "the original BERT paper"รองรับชื่อเรื่องที่ไม่สมบูรณ์ หรือการพิมพ์ผิดพลาดตอบสนองได้อย่างรวดเร็ว แม้ในขณะที่โมเดลกำลังเริ่มทำงาน (cold start) หรือไม่พร้อมให้บริการชั่วคราวระบบค้นหาแบบ Hybrid: ผสานจุดแข็งสองโลกPapers with Code เลือกใช้ ระบบค้นหาแบบ Hybrid ซึ่งเป็นการผสมผสานระหว่าง:Keyword Search: ค้นหาคำที่ตรงกันอย่างแม่นยำVector Search (Semantic Search): ค้นหาคำที่มีความหมายใกล้เคียงกัน แม้จะใช้คำต่างกันการทำงานร่วมกันนี้ช่วยให้ได้ผลลัพธ์ที่ครอบคลุมและแม่นยำกว่าการใช้เทคนิคใดเทคนิคหนึ่งเพียงอย่างเดียว นอกจากนี้ ยังสามารถใช้ Reranker (Cross-encoders) เพื่อปรับปรุงคุณภาพผลลัพธ์ให้ดียิ่งขึ้นไปอีก แม้ว่าจะต้องแลกมาด้วยภาระงานและเวลาในการตอบสนองที่เพิ่มขึ้นก็ตามสถาปัตยกรรมเบื้องหลัง: Hugging Face Services คือหัวใจสำคัญPapers with Code อาศัยฐานข้อมูล PostgreSQL เป็นหลัก โดยใช้ความสามารถ Full-text search ของ PostgreSQL เป็นพื้นฐานในการค้นหาแบบ Lexical และใช้ pgvector เพื่อเพิ่มความสามารถในการค้นหาเชิงความหมาย (Semantic Recall) โดยใช้ Reciprocal Rank Fusion (RRF) ในการรวมผลลัพธ์จากทั้งสองส่วนในการสร้าง Dense Embeddings นั้น Hugging Face ได้เข้ามามีบทบาทสำคัญผ่าน 3 บริการหลัก:Hugging Face Jobs: ให้การประมวลผล GPU ที่ยืดหยุ่นสำหรับการสร้าง Embeddings ให้กับคลังเอกสารทั้งหมดHugging Face Storage Buckets: ทำหน้าที่เป็นจุดพักข้อมูลที่ทนทานและน่าเชื่อถือ ระหว่างฐานข้อมูล, การทดลอง, และ JobsHugging Face Inference Endpoints: ให้บริการ Embeddings ที่มีความหน่วงต่ำ (Low-latency) สำหรับการค้นหาแบบ Real-time และการอัปเดตข้อมูลปัจจุบัน ระบบนี้ได้สร้าง Embeddings ให้กับเอกสารวิจัยมากกว่า 110,000 ฉบับ ที่รวบรวมมาจาก arXiv และ Daily Papersการแบ่งกระบวนการ: Offline Corpus Build และ Online Search Serviceเพื่อประสิทธิภาพสูงสุด ระบบถูกแบ่งออกเป็นสองส่วนหลัก:Offline Corpus Build: เป็นงานที่ต้องการทรัพยากรสูง เน้นปริมาณการประมวลผล (Throughput-oriented) ดำเนินการผ่าน Jobs โดยผลลัพธ์ที่ได้จะถูกจัดเก็บอย่างถาวรใน BucketsOnline Search Service: ส่วนนี้จะทำเฉพาะขั้นตอนการสร้าง Embedding สำหรับ Query เท่านั้น โดยให้บริการผ่าน Inference Endpoint ที่ได้รับการป้องกันอย่างดี เพื่อให้การค้นหาออนไลน์มีความรวดเร็วการแยกส่วนนี้ทำให้ระบบมีความยืดหยุ่น ทรงพลัง และรวดเร็ว หาก Inference Endpoint มีปัญหา ระบบจะกลับไปใช้ Full-text retrieval โดยอัตโนมัติการกำหนดสัญญา Embedding ที่เข้มงวดปัญหาที่พบบ่อยในการสร้าง Embedding คือการเปลี่ยนแปลงของโมเดล, การสลับ Prompt ระหว่าง Query กับ Document, การตัด Vector ที่ต่างกัน, หรือ Abstract ที่อัปเดตแล้วไม่ตรงกับ Vector ที่เก็บไว้เพื่อป้องกันปัญหานี้ รูปแบบของ Embedding ถูกปฏิบัติดูแลเสมือนเป็น API ที่มีการเวอร์ชัน (Versioned API) โดยเอกสารแต่ละฉบับจะถูกเข้ารหัสด้วยข้อมูลสำคัญ เช่น:ชื่อ Repository ของโมเดล และ Revision ที่แน่นอนมิติของ Outputเวอร์ชันของ Input Formatการระบุว่าเป็น Query หรือ Documentวิธีการ NormalizationHash ของเนื้อหา (ชื่อเรื่องและ Abstract)ใน Production ปัจจุบัน ใช้โมเดล Qwen/Qwen3-Embedding-0.6B ที่ถูก Pin ไว้ที่ Revision ที่แน่นอน ด้วย Vector ขนาด 256 มิติ ที่ผ่านการ L2-normalized มาแล้ว การเลือกโมเดลนี้ทำได้โดยอาศัยข้อมูลจาก MTEB leaderboard ซึ่งเป็น Benchmark ชั้นนำสำหรับการเปรียบเทียบโมเดล Embeddingโมเดล Qwen3 ยังมีความสามารถใหม่ๆ ที่น่าสนใจ:Dynamic Embedding Size (Matryoshka Representation Learning - MRL): สามารถกำหนดขนาด Embedding แบบไดนามิกได้ ทำให้สามารถแลกเปลี่ยนระหว่างคุณภาพของผลลัพธ์ กับค่าใช้จ่ายด้านความเร็วและพื้นที่จัดเก็บ ใน Papers with Code เลือกใช้ขนาด 256 มิติ เพื่อความรวดเร็วในการค้นหาInstruction Prompt: สามารถระบุ Prompt ได้ โดยโมเดล Qwen รองรับ Document Prompt (สำหรับ Embedding เอกสาร) และ Query Prompt (สำหรับ Embedding คำถามของผู้ใช้)สัญญาการ Embedding นี้ครอบคลุมตั้งแต่การ Export, การประมวลผลผ่าน GPU, การส่งเข้า PostgreSQL, ไปจนถึงการดึงข้อมูลมาใช้ในการค้นหาออนไลน์Jobs: แปลงฐานข้อมูลให้เป็นคลัง Vectorการสร้าง Embedding สำหรับคลังเอกสารทั้งหมดเป็นงานแบบ Batch ที่ต้องการ GPU เป็นระยะเวลาสั้นๆ แต่ต้องการ Throughput สูง และไม่ควรใช้ทรัพยากรอย่างต่อเนื่องเมื่อไม่ใช้งาน Hugging Face Jobs จึงเหมาะสมกับลักษณะงานนี้ โดย Jobs จะถูกกำหนดด้วยคำสั่ง (Command), ประเภทฮาร์ดแวร์ (Hardware Flavor), และอาจรวมถึง Docker Imageกระบวนการสร้างคลังเอกสารเริ่มต้นด้วยการ Export ข้อมูลเอกสารล่าสุดจาก Snapshot ของ PostgreSQL แบบ Repeatable-read Exporter จะทำการ Stream ข้อมูลเป็นแถว แทนที่จะโหลดทั้งหมดเข้าหน่วยความจำ จากนั้นจะเขียนเป็นไฟล์ JSONL แบบมีขอบเขต (Bounded) และสร้าง Manifest ที่ระบุจำนวนแถวและ ChecksumDirectory ของ Run ที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable Run Directory) จะถูก Sync ไปยัง Storage Bucket ส่วนตัว และ Mount เข้ากับ Job (เช่น l4x1 ที่มี NVIDIA L4 GPU 24GB VRAM) โดยจากมุมมองของ Worker มันจะทำหน้าที่เหมือนระบบไฟล์ทั่วไป:ตรวจสอบ Manifest และ Checksum ของทุก Shardโหลดโมเดล Revision ที่ Pin ไว้เรียงลำดับข้อความตามความยาวเพื่อลด Paddingเรียกใช้ encode_document เป็น Batchลดขนาด Batch ลงอัตโนมัติหาก GPU เต็มตัด Matryoshka Representation ให้เหลือ 256 มิติ และ Normalizeเขียน Parquet Shard แบบ Float16 อย่าง Atomicบันทึกข้อมูล Throughput, เวอร์ชั่นแพ็คเกจ, ฮาร์ดแวร์, VRAM สูงสุด, จำนวนแถว, และ Checksum ของ Outputแต่ละ Shard ที่ประมวลผลเสร็จสมบูรณ์จะมี Marker ของตัวเอง ทำให้ Job ที่เริ่มใหม่สามารถข้ามงานที่ทำเสร็จแล้วไปได้ ซึ่งมีประโยชน์มากสำหรับคลังเอกสารขนาดใหญ่ในการทดลองกับเอกสาร 5,000 ฉบับ Qwen Job สามารถสร้าง Embedding ได้ประมาณ 75 ฉบับต่อวินาที ที่มิติ 1024 บน L4 GPU และสามารถสร้างผลลัพธ์เดียวกันที่มิติ 512 และ 256 เพื่อเปรียบเทียบ Trade-off ด้านพื้นที่จัดเก็บและการดึงข้อมูลBuckets: ตัวเชื่อมประสานระบบStorage Buckets คือ Object Storage แบบ S3-like ที่สามารถเปลี่ยนแปลงได้บน Hub ซึ่งปรับแต่งมาเพื่องาน AI โดยเฉพาะ สามารถเข้าถึงผ่าน Path hf://buckets/... และ Mount แบบ Read-write ใน Jobs ได้โดยไม่ต้องสร้าง Integration เพิ่มเติมสำหรับ Papers with Code, Buckets ไม่ได้เป็นเพียงที่เก็บ Vector แต่เป็น "ขอบเขต" ระหว่าง 3 ระบบที่มีวงจรชีวิตต่างกัน:ฐานข้อมูล Production Export ข้อมูลต้นฉบับJobs แบบชั่วคราว (Ephemeral) รับข้อมูลและสร้าง VectorImporter ตรวจสอบความถูกต้องก่อนที่จะนำเข้าสู่ Search Indexการจัดระเบียบ Artifacts จะอยู่ภายใต้ Prefix ของ Run ที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable Run Prefixes) แม้ว่า Buckets จะเปลี่ยนแปลงได้ แต่การกำหนดให้ Run ID ไม่ถูกเขียนทับ และ Artifacts ทุกชิ้นมี Manifest และ Checksum ทำให้ได้คุณสมบัติที่สำคัญ:Reproducibility: สามารถย้อนรอยการสร้างฐานข้อมูลไปยัง Snapshot, Model Revision, และ Artifacts ที่แน่นอนได้Safe Retries: Jobs สามารถทำงานต่อจาก Shard ที่ทำเสร็จแล้วใน Prefix เดิมได้Cheap Experiments: การทดลองกับโมเดลหรือมิติต่างๆ สามารถใช้ Snapshot ข้อมูลนำเข้าที่ผ่านการตรวจสอบแล้วร่วมกันได้Controlled Rollout: การนำ Generation ใหม่เข้าใช้งาน จะไม่เปิดใช้งานทันที แต่จะมีการตรวจสอบความครอบคลุมและสร้าง Index ก่อนSimple Rollback: Generation ก่อนหน้าและ Artifacts จะยังคงอยู่ จนกว่า Generation ใหม่จะได้รับการพิสูจน์ว่าเสถียรหลังจากการตรวจสอบ Schema, Checksum, มิติ, Normalization, ID ของเอกสารที่ไม่ซ้ำกัน, และ Hash ของเนื้อหา Importer จะทำการโหลด Vector เข้าสู่ PostgreSQL จากนั้นจะสร้าง HNSW Index สำหรับ Generation ใหม่ และจะทำการ Mark ให้เป็น Active แบบ Atomic เมื่อเอกสารปัจจุบันที่มีสิทธิ์ทั้งหมดถูกครอบคลุมแล้วInference Endpoints: นำ Semantic Search มาสู่ Request Pathการสร้าง Embedding สำหรับคลังเอกสารทั้งหมดทำโดย Jobs แต่ Papers with Code มีการเปลี่ยนแปลงอยู่เสมอ เช่น เอกสารใหม่, การแก้ไข Abstract, หรือเวอร์ชัน arXiv ใหม่การเรียกใช้ GPU Job สำหรับข้อมูลที่เปลี่ยนแปลงเพียงไม่กี่แถวจะทำให้เกิด Overhead ในการเริ่มต้นและจัดการที่ไม่จำเป็น ด้วยเหตุนี้ จึงมีกระบวนการ Incremental แบบรายชั่วโมงที่คัดเลือกข้อมูลที่เปลี่ยนแปลงสำหรับคำถามของผู้ใช้ (User Query) จะต้องถูกสร้าง Embedding ณ เวลาที่ทำการค้นหา โดยใช้โมเดลเดียวกันกับที่ใช้ในการสร้าง Embedding เอกสาร เรา Deploy โมเดลที่ Pin ไว้เป็น Authenticated Inference Endpoint ซึ่งให้บริการโดย Text Embeddings Inference (TEI) Endpoint จะรับข้อความ Query และส่งคืน Vector ขนาด 256 มิติ ที่ Normalize แล้ว โดยใช้ Query Prompt ของโมเดลAPI จะทำการค้นหาแบบ Cosine-distance จาก Generation ที่ Active ใน pgvector HNSW Index ช่วยให้การค้นหารวดเร็ว ในการทดลองกับเอกสาร 5,000 ฉบับ Qwen Index ขนาด 256 มิติ สามารถทำ Recall@20 ได้ 0.9955 เทียบกับการค้นหาแบบ Exact โดยมี Latency การค้นหา HNSW อยู่ที่ 1.31 ms (p50) และ 2.21 ms (p95) นอกจากนี้ Table และ Index ยังใช้พื้นที่เพียงประมาณ 27% ของเวอร์ชัน 1024 มิติ โดยยังคงระดับ ANN Recall ใกล้เคียงกันEndpoint นี้ถูกตั้งค่าให้มี Replica สูงสุดเพียง 1 ตัว และสามารถ Scale to Zero ได้เมื่อไม่มีการใช้งาน ซึ่งช่วยประหยัดค่าใช้จ่าย แต่ก็หมายความว่าต้องมีการออกแบบแอปพลิเคชันให้รองรับ Cold Start ได้Client ที่ทำการ Query จึงมีพฤติกรรมที่เข้มงวด:ตั้งค่า Timeout 1 วินาทีจำกัด Concurrency แบบ Non-blockingตรวจสอบมิติ, ความถูกต้อง, และ Norm ของ Responseมี Cache สั้นๆ โดยใช้ Query และ Embedding Generation เป็น Keyมี Circuit Breaker เมื่อเกิดความล้มเหลวซ้ำๆไม่บันทึกข้อความ Query ดิบๆ ใน Log แต่จะบันทึกเป็น Fingerprint ที่ Normalize แล้วหาก Endpoint กำลัง Scale Up, หมดเวลา, คืนค่า Vector ที่ผิดปกติ, หรือไม่มี Concurrency เพียงพอ ระบบจะข้ามการค้นหาแบบ Semantic ไปยังการค้นหาแบบ Lexical ทันที ผู้ใช้จึงยังคงได้รับผลลัพธ์ แทนที่จะต้องรอให้ Dependency ที่ไม่เสถียรพร้อมใช้งานInference Endpoints ทำงานได้อย่างน่าเชื่อถือ และมาพร้อมกับ Dashboard ที่แสดง Analytics ที่สำคัญได้อย่างรวดเร็วHybrid Retrieval: แกร่งกว่าเมื่อรวมกันสำหรับการ Query แต่ละครั้ง:Lexical Branch: ดึง Candidate ได้สูงสุด 50 รายการโดยใช้ PostgreSQL Full-text search แบบถ่วงน้ำหนักSemantic Branch: ดึง Candidate ได้สูงสุด 50 รายการจาก pgvectorผลลัพธ์จากทั้งสองส่วนจะถูกรวมเข้าด้วยกันด้วย Reciprocal Rank Fusion (RRF) แบบถ่วงน้ำหนัก:$score(d) = \sum{r \in \{\text{lexical, semantic}\}} \frac{wr}{k + \text{rank}_r(d)}$RRF เป็นวิธีที่เรียบง่ายและแข็งแกร่ง เพราะเป็นการhttps://huggingface.co/blog/pwc-search