หน้าแรก / บล็อก / วิศวกรรม

เราลบตัวแยกวิเคราะห์รายจ่ายภาษาธรรมชาติ

29 สิงหาคม 2569 · อ่าน 6 นาที · Dimesum Engineering

ตัวแยกวิเคราะห์แบบกฎอยู่ได้หนึ่งสัปดาห์ ประโยคธรรมดาสี่ประโยคลงเงินให้ผิดคน และกฎการปฏิเสธข้อเดียวก็มาแทนกองตัวกันทั้งหมด

เราลบตัวแยกวิเคราะห์ที่เพิ่งเขียนเสร็จทิ้งไป ความพยายามครั้งแรกของ Dimesum ในการแยกวิเคราะห์รายจ่ายจากภาษาธรรมชาติคือเอนจินกฎเกณฑ์ และประโยคธรรมดาสี่ประโยคก็ทำให้มันต้องเลิกใช้ dinner 12-08 400 ถูกอ่านเป็น ฿12 ravioli 600 ดึงสมาชิกชื่อ Ravindra เข้ามาในการหาร kirana 500 เรียกเก็บกับสมาชิกชื่อ Kiran และ refund -483.50 กลายเป็นการเรียกเก็บ ฿483.50

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

ประโยคสี่ประโยคทำให้ตัวแยกวิเคราะห์แบบกฎจบลง

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

สองในสี่กรณีคือบั๊กเดียวกันที่สวมเสื้อผ้าต่างกัน การจับคู่แบบคลุมเครือไม่อาจแยกอาหารจานหนึ่งออกจากบุคคล หรือแยกร้านค้าออกจากบุคคลได้ เพราะในระดับตัวอักษร ravioli กับ Ravindra ดูคล้ายกันจริง ๆ หากบังคับให้จับคู่คำนำหน้ายาวขึ้น คุณก็จะทำให้ ravi พังไป ซึ่งเป็นกรณีที่ตัวจับคู่นี้มีไว้เพื่อจัดการ

ทุกตัวกันที่คุณเพิ่มทำให้เกิดรูปประโยคใหม่อีกสองแบบ

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

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

สิ่งที่ส่งออกไปคือตัวเลขหนึ่งตัวและการปฏิเสธ

amount_only คือขั้นลดระดับของเอกสารออกแบบ AI ของเราที่ถูกนำไปทำตามตัวอักษร ขั้นนั้นเขียนไว้ว่า "ฟอร์มธรรมดาพร้อมการเติมล่วงหน้าด้วยรีเจ็กซ์จำนวนเงินฝั่งไคลเอนต์" ดังนั้นขั้นนี้จึงคืนค่าจำนวนเงินและไม่มีอะไรอื่น ไม่มีคำอธิบาย ไม่มีหมวดหมู่ ไม่มีผู้จ่าย ไม่มีผู้ร่วม ไม่มีการยกเว้น มันไม่มีต้นทุนและไม่เรียกใครเลย จึงเป็นเหตุผลที่การทดสอบและ CI รันกับมัน

ความกำกวมคือการปฏิเสธ ไม่ใช่การตัดสินเสมอ

กฎทั้งหมดอยู่ในฟังก์ชันเดียวชื่อ extract_amount_minor ตัวเลขจะกลับมาก็ต่อเมื่อข้อความมีตัวเลือกเพียงตัวเดียวเท่านั้น ดังนั้น order 90210 dinner 400 และ flat 402 rent 15000 จึงคืนค่าว่างเปล่าแทนที่จะเลือกผู้ชนะ ตัวเลขที่ระบุสกุลเงินถือว่าชัดเจนแม้จะอยู่ข้างตัวเลขเปล่า จึงเป็นเหตุผลที่ split 3 ways ฿1,200 ยังอ่านได้เป็น ฿1,200

ตัวเลขที่ติดลบถือว่าไม่มีจำนวนเงินเลย ไม่ใช่ค่าสัมบูรณ์ของมัน -500 minus 200 และ (500) แบบนักบัญชี ล้วนกลับมาว่างเปล่า เพราะฟิลด์นี้คือการเรียกเก็บ และการเก็บตัวเลขไว้แต่ทิ้งเครื่องหมายทำให้เงินชี้ไปในทางตรงข้ามกับข้อความ วงเล็บนับก็ต่อเมื่อปิดล้อมที่ตัวเลขนั้นเอง ดังนั้น (500 each) จึงยังเป็นข้อความในวงเล็บ

สกุลเงินเป็นตัวกำหนดการคำนวณ

หน่วยย่อยคือรูปแบบเดียวที่เงินใช้ใน Dimesum ดังนั้นขั้นนี้จึงแปลงด้วยตารางเลขชี้กำลัง ISO 4217 แทนการคูณด้วย 100 แบบตายตัว เงินเยนของญี่ปุ่นไม่มีหน่วยย่อยเลย และการคูณ 100 ทำให้ใบเสร็จ ¥1,200 พองขึ้นร้อยเท่า ตัวเลขที่ละเอียดกว่าหน่วยเล็กที่สุดของสกุลเงินจะถูกปฏิเสธแทนที่จะปัดเศษ เพราะการปัดเศษจำนวนเงินที่คนพิมพ์เข้ามาคือการสร้างตัวเลขขึ้นเอง

คำบอกจำนวนแบบอินเดียเป็นส่วนหนึ่งของการเขียนตัวเลข ไม่ใช่ส่วนหนึ่งของการเข้าใจประโยค 1.2k 2 lakh และ 500/- ล้วนถอดค่าได้ เช่นเดียวกับ 1,200 อะไรก็ตามที่เกินจำนวนสูงสุดของบัญชีจะกลับมาว่างเปล่า ดังนั้นตัวเลขที่พิมพ์ผิดจึงทำให้ฟิลด์หนึ่งว่างแทนที่จะทำให้จำนวนเต็มล้นในขั้นถัดไป

ขั้นที่ใช้งานจริงไม่เคยผ่านเกณฑ์ใช้งานที่ 0.6

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

ขั้นนี้ยังรายงานว่าไม่มีพรอมป์เลย ทั้ง prompt_id และ prompt_version กลับมาเป็น null เพราะขั้นนี้ไม่ได้อ่านพรอมป์ใด การตั้งชื่อพรอมป์จะทำให้ผลการประเมินทุกอย่างถูกยกให้เวอร์ชันพรอมป์ที่ขั้นนี้ไม่เคยเห็น และชุดเครื่องมือประเมินคือเครื่องมือเดียวที่ได้รับอนุญาตให้เลื่อนขั้นขึ้นเป็นข้อเสนอแนะแบบแตะครั้งเดียว ที่ความแม่นยำ 95% สำหรับจำนวนเงินและผู้ร่วมพร้อมกัน

มีอีกสองขั้นที่ถูกประกาศไว้และไม่มีขั้นใดใช้งานได้ ขั้น cheap-fast มีอะแดปเตอร์ Groq สำหรับ openai/gpt-oss-120b แต่ไม่มีคีย์ ส่วนขั้นกลางไม่มีอะแดปเตอร์ การเลือกอย่างใดอย่างหนึ่งล้มเหลวตั้งแต่เริ่มระบบ ไม่ใช่ตอนที่ผู้ใช้ร้องขอครั้งแรก เพราะ LLM คิดเงินต่อการเรียกหนึ่งครั้ง และการพึ่งพาที่มีค่าใช้จ่ายต้องล้มเหลวแบบปิดไว้ก่อน

ไม่มีอะไรบันทึกอัตโนมัติ ช่องว่างจึงมีต้นทุนเพียงแตะครั้งเดียว

ช่องว่างเปล่ามีต้นทุนน้อยมากก็เพราะไม่มีการบันทึกใดใน Dimesum ที่เขียนเงินได้ การบันทึกสร้างข้อเสนอแนะ คนยืนยันมัน และการยืนยันคือสิ่งที่สร้างรายจ่าย การตัดสินใจ D5 ในบรีฟระบุกฎนี้ และ .go-arch-lint.yml บังคับใช้มัน บริบทการรับข้อมูลถูกปฏิเสธไม่ให้พึ่งพา expense หรือ ledger ใด ๆ ดังนั้นการบันทึกจึงไม่อาจบันทึกสมุดรายวันได้แม้โดยบังเอิญ CI ทำให้การ import ล้มเหลว ซึ่งเราตรวจสอบด้วยการเพิ่มเข้าไปหนึ่งครั้ง

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