วางเอกสารเพื่อดูการแบ่ง RAG และต้นทุน embedding แบบสด ข้อความไม่ถูกอัปโหลด
เปรียบเทียบต้นทุน API ต่อคำขอและรายเดือนของ OpenAI, Anthropic และ Gemini พร้อมวันที่ตรวจราคา
เปิด →ประมาณ VRAM ที่ LLM ต้องใช้ และตรวจว่าพอดีกับ GPU ของคุณหรือไม่
เปิด →เปรียบเทียบข้อความสองชุดทีละบรรทัด คำ หรืออักขระ แสดงแบบเคียงข้างหรือรวม และเลือกไม่สนใจช่องว่าง/ตัวพิมพ์ได้
เปิด →ยังไม่มีความคิดเห็น มาเป็นคนแรกกันเลย!
RAG Chunk Visualizer ให้คุณวางเอกสารและเห็นทันทีว่ากลยุทธ์การแบ่ง (ขนาดคงที่ แบบเรียกซ้ำ ตามประโยค หัวข้อ Markdown) ตัดเอกสารเป็นชังก์อย่างไร: แต่ละชังก์ได้โทนสีสลับกัน ส่วนที่ซ้อนทับมีสีของตัวเอง และสถิติแสดงจำนวนชังก์ โทเค็นเฉลี่ยและมากที่สุด ความซ้ำซ้อน และชังก์ที่จบกลางประโยค เพิ่มโมเดล embedding และราคาเพื่อประมาณต้นทุน embedding และพื้นที่จัดเก็บในฐานข้อมูลเวกเตอร์
ไม่มีตัวเลขสากล ชังก์ใหญ่ทำให้หลายหัวข้อเบลอรวมเป็นเวกเตอร์เดียวและดึงข้อมูลได้แม่นยำน้อยลง ชังก์เล็กมากทำให้คำตอบกระจายหลายชิ้น จุดเริ่มต้นที่พบบ่อยคือชังก์ไม่กี่ร้อยโทเคนที่ซ้อนทับประมาณ 10% จากนั้นตรวจการดึงข้อมูลด้วยคำถามที่คุณถามจริงแล้วปรับจากตรงนั้น
การซ้อนทับให้ชังก์ข้างเคียงใช้ข้อความร่วมกันเล็กน้อย เพื่อไม่ให้ข้อมูลที่อยู่ตรงรอยต่อถูกตัดขาด ราคาที่ต้องจ่ายคือข้อความเดียวกันถูก embed และเก็บสองครั้ง ซึ่งเพิ่มต้นทุน embedding และพื้นที่เก็บเวกเตอร์โดยตรง สถิติ “ความซ้ำซ้อน” วัดสิ่งนี้พอดี
ขนาดคงที่ง่ายและคาดเดาได้มากที่สุดแต่อาจตัดประโยค การแยกแบบเรียกซ้ำลองย่อหน้า บรรทัด ประโยค และช่องว่างตามลำดับเพื่อให้อยู่ที่ขอบเขตธรรมชาติ และเป็นจุดเริ่มต้นทั่วไปที่ดี การแยกตามประโยคไม่เคยตัดกลางประโยค การแยกตามหัวข้อ Markdown เหมาะกับเอกสารที่มีโครงสร้าง คงบล็อกโค้ดไว้ครบ และบันทึกเส้นทางหัวข้อของแต่ละชังก์
เครื่องมือนี้ใช้กฎคร่าว ๆ (ประมาณ 4 อักขระ ≈ 1 โทเคนสำหรับภาษาอังกฤษ ประมาณ 1 อักขระ ≈ 1 โทเคนสำหรับ CJK) ส่วนโมเดล embedding แต่ละตัวมีโทเคไนเซอร์ของตัวเอง ตัวเลขจริงจึงต่างกัน ถือว่า “โทเคน (ประมาณ)” เป็นไม้บรรทัดเชิงเปรียบเทียบสำหรับเทียบการตั้งค่า หากต้องการตัวเลขที่แน่นอนหรือตรวจขีดจำกัดอินพุตของโมเดล ให้ยืนยันกับโทเคไนเซอร์ของโมเดลนั้น
พื้นที่เก็บ = ชังก์ × มิติเวกเตอร์ × ไบต์ต่อมิติ (4 สำหรับ float32, 2 สำหรับ float16, 1 สำหรับ int8, 1/8 สำหรับไบนารี) × ตัวคูณดัชนี + ชังก์ × เพย์โหลดต่อชังก์ ตัวคูณดัชนีแทนพื้นที่เพิ่มเติมที่ดัชนีค้นหาแบบประมาณอย่าง HNSW ต้องการนอกจากเวกเตอร์ดิบ โดยทั่วไปประมาณ 1.2 ถึง 2 ขึ้นกับพารามิเตอร์ ปรับได้
ไม่ การแยก สถิติ และการแสดงภาพทำงานในเบราว์เซอร์ของคุณทั้งหมด และไฟล์ .txt หรือ .md ที่โหลดถูกอ่านในเครื่องเท่านั้น เครื่องมือไม่เรียก API embedding ใด ๆ ต้นทุน embedding เป็นเพียงการคำนวณจากราคาที่คุณกรอก
แบ่งตามย่อหน้า → บรรทัด → ประโยค → ช่องว่าง โดยพยายามอยู่ที่ขอบเขตธรรมชาติ (เหมือนค่าเริ่มต้นของเฟรมเวิร์กยอดนิยม)
ทับซ้อน 17%
| ลำดับ | โทเค็น | อักษร | ตัวอย่าง |
|---|---|---|---|
| 1 | 68 | 269 | # Retrieval-augmented generation Retrieval-augmented generation (RAG) combines a search step with a language model. Documents are split into chunks, each chunk· จบกลางประโยค |
| 2 | 84 | 309 | ## Why chunking matters If chunks are too large, a single vector blurs several topics together. If they are too small, the answer may be spread across chunks t· จบกลางประโยค |
| 3 | 112 | 171 | ## 中文與日本語の例 檢索增強生成會先把長文件切成較小的區塊，再把區塊轉成向量。區塊太大會混入多個主題；區塊太小又可能把答案拆散。検索拡張生成では、文書を適切な大きさに分割することが重要です。 ```python chunks = splitter.split_text(document) print(len(c· จบกลางประโยค |
พื้นที่เพิ่มของดัชนี ANN (เช่น HNSW) เทียบกับเวกเตอร์ดิบ โดยทั่วไปประมาณ 1.2–2 เท่าขึ้นกับพารามิเตอร์
มิติเอ็มเบดดิงและขีดจำกัดอินพุตมาจากเอกสารหรือคอนฟิกโมเดลของแต่ละผู้ให้บริการ (ตรวจสอบเมื่อ 2026-10-20)
โทเค็นเป็นค่าประมาณ (ภาษาอังกฤษประมาณ 4 ตัวอักษร = 1 โทเค็น CJK ประมาณ 1 ตัวอักษร = 1 โทเค็น) ใช้ tokenizer ของโมเดลเอ็มเบดดิงของคุณเพื่อตัวเลขที่แน่นอน ทุกอย่างประมวลผลในเบราว์เซอร์ของคุณและข้อความไม่ถูกอัปโหลด
