jusText 在短段落样本上的阈值断崖

ในเอกสารที่ยาวที่สุดของแต่ละย่อหน้าแค่ 151 ตัวอักษร jusText ถ้าใช้ค่าตั้งต้นจะคืนมาเป็น 0 ตัวอักษร ไปเลย ไม่ใช่แค่ดึงมาได้ไม่ครบ แต่เป็นสตริงว่างทั้งก้อน พอลดค่าหนึ่งลงนิดเดียวให้มีแค่ย่อหน้าเดียวข้ามเส้นได้ เอกสารชุดเดิมก็จะให้ผลเป็น 832 ตัวอักษร และถ้าลดต่อไป ผลก็ยังคงเป็น 832 เหมือนเดิม

กับชุดตัวอย่างนี้ พฤติกรรมของมันเลยดูเหมือน “หน้าผา” มากกว่า “ทางลาด” มาก ค่าตั้งต้นจะวางถูกฝั่งหรือเปล่า ก็ขึ้นอยู่กับความยาวย่อหน้าและการกระจายของข้อความเทมเพลตในคอร์ปัสเป้าหมาย

jusText คืออะไร และทำไมความหนาแน่นของคำถึงสำคัญ

เมื่อเทียบกับตัวแยกข้อความตัวอื่นในชุดทดสอบนี้ jusText พึ่งพา ความหนาแน่นของ stopwords ตามภาษา ชัดเจนเป็นพิเศษ บล็อกข้อความที่มีคำเชิงหน้าที่เยอะๆ เช่น the、and、of、was มีแนวโน้มจะเป็นเนื้อหาจริงมากกว่า แต่สัญญาณจากคำอย่างเดียวก็ไม่ใช่ตัวตัดสินสุดท้าย เพราะมันยังดูทั้งความยาวย่อหน้า ความหนาแน่นของลิงก์ ขอบเขตบล็อกจาก HTML ระยะห่างจากหัวข้อ ประเภทของบล็อกที่อยู่ติดกัน และการตัดสินรอบสองที่อิงบริบทด้วย

อ้างอิงทางการ: jusText 官方仓库。

เพราะตัวจำแนกต้องใช้ stopwords ตามภาษา jusText เลยแถม stopwords 100 ภาษา มาให้ในแพ็กเกจ จุดนี้เป็นความต่างที่เด่นมากในชุดเปรียบเทียบนี้ เพราะมันเน้นสัญญาณคำแบบผูกกับภาษาอย่างชัดเจน แต่การทดสอบครั้งนี้ไม่ได้วัดคุณภาพหลายภาษา

เวอร์ชันทดสอบ: 3.0.2, BSD 2-Clause, 822 GitHub stars. Python 3.14.2.

หน้าผานี้ชัดแค่ไหน

ตัวจำแนกของ jusText ทำงานสองรอบ รอบแรกไม่อิงบริบท แยกแต่ละย่อหน้าเป็น good、bad、short หรือ neargood ก่อน รอบที่สองค่อยเอาบริบทมาช่วย แล้วดัน neargood ให้เป็น good แต่มีเงื่อนไขว่าข้างๆ ต้องมีบล็อก good อยู่ก่อนแล้ว ย่อหน้าจะได้ good แบบเดี่ยวๆ ก็ต่อเมื่อความยาวเกิน length_high ซึ่งค่าตั้งต้นคือ 200 ตัวอักษร

ถ้าเป็นเอกสารที่ไม่มีแม้แต่ย่อหน้าเดียวเกิน 200 ตัวอักษร ก็จะไม่มีบล็อก “ตัวตั้งต้น” ให้ดันต่อ neargood ทั้งหมดเลยถูกมองเป็นข้อความเทมเพลต สุดท้ายทั้งหน้าเลยว่างเปล่า

ผมลองไล่ค่าตัวนี้กับตัวอย่างนี้แล้ว โดยย่อหน้าที่ยาวที่สุดมีแค่ 151 ตัวอักษร:

justext-length-threshold.json。

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

ก่อนจะโยงผลทั้งหมดไปที่ length_high ผมยังลองไล่ length_low อยู่ 4 ค่า แล้วเอาไปจับคู่กับ max_link_density อีก 2 ค่า รวมเป็น 8 ชุด ผลคือทั้งหมดเป็น 0 ไม่มีชุดไหนช่วยพยุงเนื้อหาในตัวอย่างนี้ได้เลย

ถ้ามองภาพรวมทั้งชุด 22 ตัวอย่าง รูปแบบนี้ก็ยังเหมือนเดิม: เมื่อ length_high=200 มีแค่ 2 จาก 22 ตัวอย่างที่มีผลลัพธ์ พอลดเป็น 150 ก็ขึ้นเป็น 9 ตัวอย่าง และถ้าลดเป็น 120 ก็ขึ้นเป็น 15 ตัวอย่าง

แต่มีสองเรื่องที่ไม่ควรอ่านผิด ประการแรก นี่ไม่ได้แปลว่า jusText แย่ เพราะบนหน้าเว็บข่าวภาษาธรรมชาติจริงๆ ด้วยค่าตั้งต้น มันดึงเนื้อหาสะอาดๆ ออกมาได้ถึง 1,190 ตัวอักษร เพราะย่อหน้าข่าวจริงมักยาวเกิน 200 ตัวอักษรตั้งแต่รอบแรกอยู่แล้ว ประการที่สอง มันก็ไม่ได้หมายความว่าค่าตั้งต้นผิดแน่ๆ มันแค่บอกว่าค่าตั้งต้นนี้สมมติว่าย่อหน้าต้องยาว และคุณต้องเช็กก่อนว่าคอร์ปัสของตัวเองเป็นแบบนั้นจริงไหม

อีกด้านของชุดตัวอย่างนี้: ค่าตั้งต้นรั่วข้อความเทมเพลตมากที่สุด

ในชุดตัวอย่างที่ติดป้ายกำกับนี้ ถ้าใช้ค่าตั้งต้น jusText จะมีอัตรา leakage ของข้อความเทมเพลตสูงที่สุด

sixway-scores.json。หนึ่งชุดตัวอย่าง หนึ่งตัวให้คะแนน แต่ละช่องมีการติดป้ายไม่ซ้ำกัน จึงย้อนคืนผลได้แม่นถึงระดับ substring matching。

47% ของข้อความเทมเพลตรั่วออกมา และมี token ปนเปื้อน 74 ตัว — leakage มากกว่า Readability ถึงสองเท่า และการปนเปื้อนก็เกินสองเท่าเหมือนกัน นี่คือผลวินิจฉัยภายใต้ค่าตั้งต้น ไม่ใช่อันดับถาวรของทุกสถานการณ์

leakage ที่เห็นสอดคล้องกับตรรกะในขั้นตอนที่ใช้บริบทชุดเดียวกับที่อธิบายหน้าผาไว้ด้านบน ถ้าประเภทของบล็อกและกฎเรื่องระยะอนุญาต neargood ก็อาจถูกดันขึ้นได้ ดังนั้นข้อความโปรโมชันหรือคอมเมนต์ที่ดูคล้าย正文 ถ้าไปติดกับเนื้อหาจริงก็อาจหลุดขอบได้ ผลในชุดนี้จึงบอกแค่ว่าบล็อกติดป้ายไหนรั่วบ้าง ส่วนกลไกจริงยังต้องอยู่ภายใต้กฎบริบทเฉพาะของ jusText

ค่า recall ของมันอยู่ที่ 0.8378 ติดอันดับท้ายๆ และความสูญเสียทั้งหมดมาจาก threshold ล้วนๆ: บนบทความที่มีแค่ 129 ตัวอักษร มันไม่ดึงอะไรออกมาเลย; บนหน้าที่มี 10 ย่อหน้าสั้นๆ ก็ไม่ดึงอะไร; และบนเอกสารที่แทบจะว่างเปล่า ก็ยังไม่มีผลลัพธ์เหมือนเดิม

รายการ stopwords ตามภาษา

ยังมี stopwords อื่นอีก 99 ภาษา

justext.get_stoplists() จะคืนมาเป็น 100 ภาษา ตัวจำแนกนี้ออกแบบมาให้กำหนดตามภาษาโดยตรง ไม่ใช่แค่แปลง heuristic ภาษาอังกฤษให้เป็นอย่างอื่น การเปลี่ยนภาษาแค่ส่งพารามิเตอร์เข้าไปตัวเดียวก็พอ:

import justext
paragraphs = justext.justext(html, justext.get_stoplist("Czech"))
text = "\n".join(p.text for p in paragraphs if not p.is_boilerplate)

trafilatura และ goose3 ก็มีพฤติกรรมที่เกี่ยวข้องกับภาษาเหมือนกัน แต่การประเมินครั้งนี้ไม่ได้ให้คะแนนตัวแยกใดๆ บน ground truth ที่ไม่ใช่ภาษาอังกฤษ ชุด stopwords 100 ภาษาใน jusText ทำให้มันเหมาะกับงานประเมินหลายภาษา แต่แค่มีรายการนี้ ก็ยังสรุปไม่ได้ว่าคุณภาพการแยกในภาษาต่างๆ ดีแค่ไหน หรือคู่แข่งแย่กว่าจริงหรือไม่

API ของมันเรียบง่ายมาก: มีแค่สองฟังก์ชัน กับค่าคงที่ที่ปรับได้ 9 ตัว — length_low 70, length_high 200, stopwords_low 0.30, stopwords_high 0.32, max_link_density 0.20, max_heading_distance 200 และการจัดการ encoding โครงสร้างชัด อ่านง่าย และ signature ก็ระบุไว้ตรงไปตรงมา

การติดตั้งและความเร็ว

pip install justext จะดึงมาแค่ 3 แพ็กเกจ — น้อยที่สุดในชุดเปรียบเทียบนี้ — ใช้พื้นที่ 22.4 MiB และติดตั้งเสร็จในไม่ถึงสองวินาที

อ้างอิงทางการ: jusText บน PyPI。

install-and-import.json。แต่ละไลบรารีถูกวางใน virtual environment ว่างแยกกันคนละชุด。

3 แพ็กเกจ, 22.4 MiB ถือว่าเบามากในชุดนี้ และค่า median extraction ที่ 0.56 ms ก็ใกล้กับ trafilatura ที่ 0.51 ms มาก การวัดในสภาพแวดล้อมนี้ไม่ได้แยกการใช้ดิสก์ตามชนิดไฟล์ จึงบอกไม่ได้ว่า stopwords กินพื้นที่ไปเท่าไร

สถานะการดูแล แบบดูอย่างระวัง

ตัวชี้วัด “การดูแลแบบเริ่มเก่า” ที่ใช้ตรงนี้คือครั้งสุดท้ายที่ push ใน repo และครั้งสุดท้ายที่ปล่อยบน PyPI ซึ่งทั้งคู่เกิดขึ้นเมื่อ 2025-02-25 นั่นคือก่อนเวลาทดสอบประมาณสิบเจ็ดเดือน ทั้งหมดมี 8 releases, 91 forks, 9 issues ที่ยังไม่ปิด และ repo ก็ไม่ได้ถูก archive

ตัว classifier ใน PyPI ระบุรองรับ Python สูงสุดแค่ 3.9 แต่ตอนผมรันบน 3.14.2 มันยังติดตั้งได้ เปิดใช้งานได้ ใช้เวลา import 0.777 วินาที และดึงข้อมูลสำเร็จ 19 จาก 22 ตัวอย่าง โดยไม่มี exception เลย

ดังนั้น metadata อาจจะล้าหลังไป 5 เวอร์ชัน Python แต่ตัวโปรแกรมยังรันได้ ความต่างตรงนี้สำคัญมาก: repo ที่เงียบไม่ได้แปลว่า ใช้ไม่ได้ มันแค่เป็นสัญญาณเรื่อง การสนับสนุน เท่านั้น สำหรับไลบรารีที่แกนหลักคือ “วิธีการที่เผยแพร่ตั้งแต่ปี 2011 + ชุดคำ” สถานะ “ทำงานเสร็จแล้ว” ก็ถือว่าเป็นสภาพที่สมเหตุสมผล เพราะส่วนที่เปลี่ยนได้มีไม่มาก และ stopwords ก็ไม่ได้เก่าล้าหลังง่ายเหมือนวิธีเลี่ยงระบบ anti-bot

แต่ความเงียบของ repo ก็แปลว่า ถ้าคุณเจอบั๊ก ก็ต้องแก้เองหรือ fork เอง และถ้ามองร่วมกับ issue ที่ยังค้างอยู่ 9 รายการ มันก็ไม่ได้ดูเหมือนโปรเจกต์ที่ถูกปัญหาทับถมจนใช้ไม่ได้

หน่วยความจำ และมันรับมือกับ HTML ที่เสียหายยังไง

ตรงนี้แยกสองเรื่องออกจากกันเพื่อวัด

ภาพรวมการทดสอบภาระที่ใหญ่กว่า ดูได้ที่ การเปรียบเทียบหน่วยความจำและ HTML ที่เสียหายในสิบไลบรารี。

Peak resident memory วัดด้วย /usr/bin/time -l โดยเปิดโปรเซสใหม่ทุกครั้ง — ค่า import ขั้นต่ำหมายถึงต้นทุนตอนโหลดไลบรารีแล้วอยู่นิ่งๆ ส่วน peak จะรวมขนาดของเอกสารเข้าไปด้วย

memory-results.json。baseline ของ Python กับ Node เปรียบเทียบกันตรงๆ ไม่ได้ เพราะตัว interpreter เองก็ถูกรวมอยู่ด้วยทั้งคู่。

import ขั้นต่ำของ jusText คือ 30.3 MiB และบนตัวอย่าง 10 MB นี้ peak อยู่ที่ 431.2 MiB หรือประมาณ 14.2 เท่าของ import ขั้นต่ำ และยังเท่ากับ RSS แบบสัมบูรณ์ราว 43.1 เท่าของขนาดอินพุต แต่ตัวอย่างเดี่ยวกับโปรเซสเดี่ยวก็ยังไม่พอจะสรุปเส้นโค้งการสเกลทั่วไปได้ และ baseline ของ Python กับ Node ก็ยังเอามาเทียบกันตรงๆ ไม่ได้อยู่ดี

HTML ที่เสียหาย: มีเอกสาร 12 ชิ้นที่เสียอย่างละแบบ — แท็กไม่ปิด, inline element ซ้อนผิด, attribute ที่มีช่องว่างแต่ไม่ใส่เครื่องหมายคำพูด, closing tag เกินมา, ไม่มี <html> เลย, มี attribute ซ้ำ, เอกสารถูกตัดกลางแท็ก, entity ผิด, <script> ไม่ปิด, ประกาศ charset ปลอม, คอมเมนต์ที่มี markup และการซ้อนลึก 600 ชั้น — บวกกับ 2 ชิ้นที่ปกติแต่ขนาดเดียวกัน การออกแบบแบบนี้จำเป็น เพราะถ้าแค่ “ไม่คืนค่าอะไรเลย” มันจะมีความหมายก็ต่อเมื่อไลบรารีเงียบกับเอกสารปกติด้วยเหมือนกัน

justext ไม่โยน exception เลยใน 14 ตัวอย่าง, คืนค่าว่างใน 13 ตัวอย่าง และบน damaged samples ที่มี mark คงอยู่ 33 ตัว ก็หาเจอกลับมาได้ 0 ตัว (malformed-results.json) ตัวอย่างปกติที่สั้นก็คืน 0 ตัวอักษรเหมือนกัน ส่วนตัวอย่างปกติที่ยาวตัวเดียวคืออันที่ได้ผลลัพธ์ไม่ว่าง โดยคืนมา 1,333 ตัวอักษร เอกสารที่เสียทั้ง 12 ชิ้นยังคงว่างทั้งหมด และกรณี <script> ที่ไม่ปิดถูกตัดออกจากการให้คะแนนการอยู่รอดของ mark ดังนั้นสิ่งที่การทดสอบนี้ชี้คือความทนของ parser — ไม่มี exception — แต่ยังสรุปไม่ได้ว่าความเงียบเกิดจาก HTML เสีย หรือเกิดจาก threshold เรื่องขนาดที่วัดไว้ก่อนหน้านี้แล้ว

ข้อดีและข้อเสีย

ข้อดี: มี stopwords 100 ภาษา และตัวจำแนกก็ออกแบบมารอบชุดคำพวกนี้จริงๆ ไม่ใช่เอากฎอังกฤษมาแปลงเฉยๆ ในชุดเปรียบเทียบนี้ใช้แพ็กเกจน้อยที่สุด แค่ 3 ตัว ความเร็ว extraction median 0.56 ms มีค่าคงที่ปรับแต่งที่ชัดเจน 9 ตัว BSD 2-Clause แม้ metadata ของ classifier จะหยุดที่ Python 3.9 แต่มันก็รันสะอาดบน Python 3.14 ได้

ข้อเสีย: ในการทดสอบสังเคราะห์รอบนี้ มันมี leakage ของข้อความเทมเพลตสูงที่สุดภายใต้ค่าตั้งต้น: 47% และ token ปนเปื้อน 74 ตัว ชุดตัวอย่างที่ย่อหน้าสั้นถ้าไม่มีอันไหนข้าม length_high จะได้สตริงว่างกลับมาเลย ค่า recall บนชุดนี้อยู่ที่ 0.8378 และ repo ครั้งล่าสุดที่มีการ push กับปล่อย release ก็เกิดตั้งแต่ก่อนเวลาทดสอบสิบเจ็ดเดือน ดังนั้นความเป็นภาระการดูแลต้องเอามาคิดด้วย

เหมาะกับใคร ไม่เหมาะกับใคร

เหมาะจะประเมิน jusText: ถ้าคอร์ปัสของคุณเป็นหลายภาษา เพราะชุด stopwords ที่ระบุชัดและมีจำนวนมากคือคุณสมบัติจริงของมัน การทดสอบครั้งนี้แม้จะนับ stopwords 100 ภาษา แต่ไม่ได้วัดคุณภาพหลายภาษา และมันก็เหมาะกับงานที่ต้องการ dependency แค่ 3 แพ็กเกจ และพร้อมจะคุม threshold เองแบบชัดเจน

ไม่แนะนำให้ใช้: ถ้าคุณจะป้อนผลลัพธ์เข้าโมเดลแบบ token-based แล้ว 74 token ที่ปนเปื้อนนั้นแพงกว่า goose3 กับ newspaper4k ที่เป็น 0 มาก ถ้าหน้าเว็บส่วนใหญ่ของคุณเป็นย่อหน้าสั้นๆ — เช่น product intro, list page, changelog, FAQ — ก็ไม่ค่อยเหมาะ เว้นแต่คุณจะปรับ length_high ไว้แล้ว หรือถ้าข้อกำหนดด้าน compliance หรือ procurement ต้องการ dependency ที่ยังดูแลอยู่จริงๆ ก็ไม่ค่อยตอบโจทย์ ถึงโค้ดจะรันได้ แต่ข้อจำกัดนี้ก็ยังเป็นข้อจำกัดจริง

ถ้าจะใช้มัน อย่าคัดลอกค่าเริ่มต้นตรงๆ และอย่าใช้ percentile rule แบบทื่อๆ ควรเอาชุดตัวอย่างที่มีป้ายกำกับเล็กๆ ไปไล่ปรับ length_high เอง ลองทุก threshold ที่เป็นไปได้ แล้วดูทั้ง article recall และ template text precision การลดเกณฑ์อาจช่วยกู้ย่อหน้าสั้นได้ แต่ก็อาจดึงบล็อกข้างเคียงที่ไม่ต้องการติดขึ้นมาด้วย

โฮสต์ API ควรวางตรงไหน

jusText ทำงานกับ HTML ที่คุณมีอยู่แล้ว เหมือนกับไลบรารีทั้งหมดในงานเปรียบเทียบนี้ มันไม่ได้ไปดึงเว็บเอง ไม่ render JavaScript และไม่จัดการเลเยอร์ anti-bot ให้

การเทียบชุดตัวอย่างเดียวกันในตัวแยกหกตัว ดูได้ที่ การเปรียบเทียบการสกัดบทความหกไลบรารี。

บริการแบบ hosted สำหรับ scraping / rendering / extraction อย่าง Thunderbit ครอบคลุมอีกชั้นของความรับผิดชอบ ตรงนี้เราไม่ได้ benchmark Thunderbit ความต่างคือฝั่งนี้เป็น “การจำแนก正文จาก HTML ที่มีอยู่แล้ว” ส่วนอีกฝั่งคือ “บริการที่รับ URL แล้วไปเอาและจัดการให้ครบ” บทความนี้ไม่ได้ให้คะแนนคุณภาพภายใต้มาตรวัดเดียวกัน

พูดตรงๆ กว่านั้น: stopwords หลายภาษาของ jusText เป็นความสามารถจริง และฟรี ถ้าปัญหาของคุณคือ “ต้องการเก็บเว็บหลายภาษา” ไม่ใช่ “ต้องการจำแนก正文หลายภาษา” นั่นก็เป็นคนละโจทย์กันแล้ว

ถ้าอยากดูภาพรวมที่กว้างกว่า ลองดู เว็บ scraping API แบบสรุป สำหรับทาง hosted และ ภาพรวม open-source scraper สำหรับสาย self-hosted ถ้าผลลัพธ์สุดท้ายต้องส่งเข้าโมเดล วิธีแปลง HTML เป็น Markdown ใน Python มักเป็นจุดที่ทำให้ความแม่นยำหายไปมากที่สุด

ทดลองใช้ฟรี Thunderbit สำหรับการดึงข้อมูลเว็บ

ควรใช้ jusText ไหม?

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

stopwords 100 ภาษาในตัวเป็นจุดแข็งที่มีตัวตนจริง แต่รอบนี้ไม่ได้ทดสอบความแม่นยำหลายภาษา ส่วน threshold แบบหน้าผานั้นจูนได้ และจะยอมลดลงได้แค่ไหน ก็ต้องดูจาก recall กับ template text precision บนตัวอย่างที่มีป้ายกำกับของคุณเอง

บนชุดตัวอย่างสังเคราะห์ภาษาอังกฤษนี้ ถ้าใช้ค่าตั้งต้น newspaper4k ไม่รั่ว token ของข้อความเทมเพลตที่ติดป้ายกำกับเลย และกู้คืน unit บทความได้ 0.9865 มันเป็นตัวเลือกเปรียบเทียบที่ดีสำหรับงานแบบนี้ แต่ก็ยังเอาไปแทนทุกกรณีไม่ได้

ทดลองใช้ฟรี Thunderbit สำหรับการดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

ทำไม jusText ถึงคืนค่าเป็นสตริงว่าง ไม่ยอมดึงมาบางส่วน?
ตัวจำแนกมันทำงานสองรอบ ย่อหน้าจะได้ good เองก็ต่อเมื่อยาวเกิน length_high (ค่าตั้งต้น 200 ตัวอักษร) จากนั้นรอบที่สองค่อยดันบล็อก neargood ที่อยู่ติดกันขึ้นมา ถ้าไม่มีสักย่อหน้าที่เกินเกณฑ์ ก็จะไม่มี “seed” ให้เริ่ม ผลคือ candidate ทั้งหมดกลายเป็นข้อความเทมเพลต ดังนั้นผลลัพธ์เลยว่าง นี่เป็นพฤติกรรมที่ออกแบบไว้ตั้งแต่ต้น ไม่ใช่ว่ามันหาได้แค่ครึ่งเดียว

jusText เลิกดูแลแล้วหรือยัง?
ครั้งล่าสุดที่มีการ push ใน repo และปล่อยบน PyPI คือ 2025-02-25 ซึ่งห่างจากเวลาทดสอบ 17 เดือน และ classifier metadata บน PyPI ก็ระบุไว้ถึงแค่ Python 3.9 แต่ตอนรันบน Python 3.14.2 มันติดตั้งและทำงานได้ปกติ ไม่มี error และมี issue ค้างอยู่ 9 รายการ ไม่ได้เยอะจนชี้ว่ามันพัง แต่อ่านเป็นสัญญาณความเสี่ยงด้านการดูแลได้ดี ไม่ใช่หลักฐานว่าฟังก์ชันใช้ไม่ได้ สิ่งที่อาจเกิดขึ้นจริงคือคุณอาจต้องแก้ bug เอง

ทำไมมันรั่วข้อความเทมเพลตมากกว่า Readability?
ในชุดตัวอย่างนี้ บล็อกข้างเคียงที่ดูคล้าย正文สามารถข้ามขอบเขตการแสดงผลได้ภายใต้กฎบริบทเริ่มต้น การจะถูกดันขึ้นหรือไม่ ขึ้นกับประเภทบล็อก ระยะห่าง และบริบท ไม่ใช่การยกทุกเพื่อนบ้านขึ้นอัตโนมัติ ผลที่วัดได้คือ ภายใต้ค่าตั้งต้นมีข้อความเทมเพลตรั่ว 47% และเกิด token ปนเปื้อน 74 ตัว

จะเปลี่ยนเป็นภาษาอื่นยังไง?
justext.justext(html, justext.get_stoplist("German")) get_stoplists() จะคืนภาษาที่รองรับทั้งหมด 100 ภาษา stopwords คือ input ด้านคำที่ผูกกับภาษาในตัวจำแนกนี้ และยังใช้ร่วมกับความยาวย่อหน้า ความหนาแน่นลิงก์ การแบ่งบล็อกจาก HTML ระยะห่างจากหัวข้อ และบริบทของบล็อกข้างเคียงด้วย การเปลี่ยนภาษา input ไม่ได้แปลว่าคุณตรวจคุณภาพการแยกภาษาเยอรมันได้อัตโนมัติ

อะไรที่ไม่ได้ทดสอบในที่นี้?
ไม่ได้ทดสอบหน้าเว็บจริงในโลกจริง — ทั้งหมดเป็นตัวอย่างที่มีป้ายกำกับและควบคุมได้ และไม่ได้ทดสอบคุณภาพการทำงานหลายภาษาแม้ว่าไฮไลต์ใหญ่ของไลบรารีนี้จะเป็นจุดนั้นก็ตาม เราแค่นับจำนวน stopwords 100 ภาษาเท่านั้น เรื่องขอบเขตของ encoding ก็ไม่ได้ลงลึก แม้ jusText จะมีพารามิเตอร์ encoding、default_encoding และ enc_errors ให้ใช้ และ max_heading_distance กับ threshold ของ stopwords อีกสองตัวก็ถูกปล่อยไว้ที่ค่าเริ่มต้นตลอดการทดสอบ