Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEA

เรายังคงพูดคุยเกี่ยวกับโครงการของ DevDays Hackathon ฤดูใบไม้ผลิซึ่งนักศึกษาหลักสูตรปริญญาโทเข้าร่วม “การพัฒนาซอฟต์แวร์ / วิศวกรรมซอฟต์แวร์”.

Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEA

โดยทางเราอยากจะเชิญชวนผู้อ่านให้เข้าร่วม กลุ่มนักศึกษาปริญญาโท VK. ในนั้นเราจะเผยแพร่ข่าวสารล่าสุดเกี่ยวกับการรับสมัครและการศึกษา สามารถดูวิดีโอจากวันเปิดได้ในกลุ่ม เราขอเตือนคุณว่า: รายละเอียดกิจกรรมจะมีขึ้นในวันที่ 29 เมษายน ออนไลน์.

ตัวแยกวิเคราะห์ข้อความเสียงของโทรเลขเดสก์ท็อป

Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEA

ผู้เขียนความคิด
โคโรเชฟ อาร์เต็ม

โครงสร้างคำสั่ง

Khoroshev Artem – ผู้จัดการโครงการ/ผู้พัฒนา/QA
Eliseev Anton – นักวิเคราะห์ธุรกิจ/ผู้เชี่ยวชาญด้านการตลาด
Maria Kuklina – นักออกแบบ/นักพัฒนา UI
Bakhvalov Pavel – ผู้ออกแบบ/นักพัฒนา UI/QA

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

เป้าหมายของโครงการของเราที่ DevDays คือการเพิ่มความสามารถในการแปลข้อความเสียงที่ได้รับเป็นข้อความไปยังไคลเอ็นต์เดสก์ท็อป Telegram (ต่อไปนี้จะเรียกว่า Telegram Desktop)

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

ตามที่ระบุไว้ก่อนหน้านี้ telegram-desktop มีข้อดีที่สำคัญสองประการ: ความสะดวกและความเร็วในการทำงาน และนี่ไม่ใช่เรื่องบังเอิญ เพราะมันเขียนด้วยภาษา C++ ทั้งหมด และเนื่องจากเราตัดสินใจที่จะเพิ่มฟังก์ชันใหม่ให้กับไคลเอนต์โดยตรง เราจึงต้องพัฒนามันด้วยภาษา C++

Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEAในทีมของเรามี 4 คน ในตอนแรก คนสองคนกำลังค้นหาไลบรารีที่เหมาะสมสำหรับการรู้จำเสียง คนหนึ่งกำลังศึกษาซอร์สโค้ดของ Telegram-desktop อีกคนกำลังปรับใช้โปรเจ็กต์ build Telegram Desktop. ต่อมา ทุกคนยุ่งอยู่กับการแก้ไข UI และการดีบัก

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

การแก้ปัญหาประกอบด้วยงานย่อยสองงานแยกกัน: การเลือกเครื่องมือการรู้จำเสียงพูดที่เหมาะสม และการนำ UI ไปใช้สำหรับฟังก์ชันการทำงานใหม่

เมื่อเลือกไลบรารีสำหรับการจดจำเสียง เราต้องละทิ้ง API ออฟไลน์ทั้งหมดทันที เนื่องจากโมเดลภาษาใช้พื้นที่มาก แต่เรากำลังพูดถึงเพียงภาษาเดียว เห็นได้ชัดว่าเราจะต้องใช้ API ออนไลน์ ต่อมาปรากฎว่าบริการรู้จำเสียงของยักษ์ใหญ่เช่น Google, Yandex และ Microsoft นั้นไม่ได้ฟรีเลย และเราจะต้องพอใจกับช่วงทดลองใช้งาน ด้วยเหตุนี้จึงเลือก Google Speech-To-Text เนื่องจากช่วยให้คุณได้รับโทเค็นสำหรับการใช้บริการซึ่งจะคงอยู่ตลอดทั้งปี

ปัญหาที่สองที่เราพบนั้นเกี่ยวข้องกับข้อบกพร่องบางประการของ C++ ซึ่งเป็นสวนสัตว์ของห้องสมุดต่างๆ ในกรณีที่ไม่มีพื้นที่เก็บข้อมูลแบบรวมศูนย์ มันเกิดขึ้นที่ Telegram Desktop ขึ้นอยู่กับไลบรารี่เฉพาะเวอร์ชันอื่น ๆ ที่เก็บข้อมูลอย่างเป็นทางการมี การแนะนำ เพื่อประกอบโครงการ และยังมีประเด็นที่เปิดอยู่จำนวนมากเกี่ยวกับปัญหาการสร้างอีกด้วย เวลา и สอง. ปัญหาทั้งหมดเกี่ยวข้องกับการที่สคริปต์บิลด์เขียนขึ้นสำหรับ Ubuntu 14.04 และเพื่อให้สร้างโทรเลขภายใต้ Ubuntu 18.04 ได้สำเร็จ จะต้องมีการเปลี่ยนแปลง

Telegram Desktop ใช้เวลาในการประกอบค่อนข้างนาน: บนแล็ปท็อปที่มี Intel Core i5-7200U การประกอบแบบสมบูรณ์ (แฟล็ก -j 4) โดยการอ้างอิงทั้งหมดจะใช้เวลาประมาณสามชั่วโมง ในจำนวนนี้การเชื่อมโยงไคลเอนต์ใช้เวลาประมาณ 30 นาที (ต่อมาปรากฏว่าในการกำหนดค่า Debug การเชื่อมโยงใช้เวลาประมาณ 10 นาที) แต่ต้องทำซ้ำขั้นตอนการเชื่อมโยงทุกครั้งหลังจากทำการเปลี่ยนแปลง

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

พื้นที่เก็บข้อมูล

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

การสนับสนุนภาษาธรรมชาติที่ได้รับการปรับปรุงใน IntelliJ IDEA

Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEA

ผู้เขียนความคิด

ทันคอฟ วลาดิสลาฟ

โครงสร้างคำสั่ง

Tankov Vladislav (หัวหน้าทีม ทำงานร่วมกับ LanguageTool และ IntelliJ IDEA)
Nikita Sokolov (ทำงานกับ LanguageTool และการสร้าง UI)
Khvorov Alexander (ทำงานร่วมกับ LanguageTool และเพิ่มประสิทธิภาพ)
Sadovnikov Alexander (รองรับการแยกวิเคราะห์ภาษามาร์กอัปและโค้ด)

เราได้พัฒนาปลั๊กอินสำหรับ IntelliJ IDEA ที่จะตรวจสอบข้อความต่างๆ (ความคิดเห็นและเอกสารประกอบ บรรทัดตัวอักษรในโค้ด ข้อความที่จัดรูปแบบใน Markdown หรือมาร์กอัป XML) เพื่อความถูกต้องทางไวยากรณ์ การสะกด และโวหาร (ในภาษาอังกฤษเรียกว่าการพิสูจน์อักษร)

แนวคิดของโปรเจ็กต์นี้คือการขยายการตรวจการสะกดมาตรฐาน IntelliJ IDEA ให้เป็นระดับ Grammarly เพื่อสร้าง Grammarly ภายใน IDE

คุณสามารถเห็นสิ่งที่เกิดขึ้น ลิงค์.

ด้านล่างนี้เราจะพูดถึงรายละเอียดเพิ่มเติมเกี่ยวกับความสามารถของปลั๊กอินรวมถึงปัญหาที่เกิดขึ้นระหว่างการสร้าง

แรงจูงใจ

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

หนึ่งในสภาพแวดล้อมการพัฒนาที่ได้รับความนิยมและพัฒนามากที่สุดคือ IntelliJ IDEA เช่นเดียวกับ IDE ที่ใช้แพลตฟอร์ม IntelliJ แพลตฟอร์ม IntelliJ มีเครื่องตรวจการสะกดในตัวอยู่แล้ว แต่ไม่สามารถกำจัดข้อผิดพลาดทางไวยากรณ์ที่ง่ายที่สุดได้ เราตัดสินใจรวมระบบวิเคราะห์ภาษาธรรมชาติยอดนิยมระบบหนึ่งเข้ากับ IntelliJ IDEA

การดำเนินงาน

Hackathon DevDays'19 (ตอนที่ 2): ตัวแยกวิเคราะห์ข้อความเสียงสำหรับการตรวจสอบโทรเลขและไวยากรณ์ใน IntelliJ IDEAเราไม่ได้กำหนดหน้าที่ในการสร้างระบบการตรวจสอบข้อความของเราเอง ดังนั้นเราจึงใช้โซลูชันที่มีอยู่ ตัวเลือกที่เหมาะสมที่สุดกลายเป็น LanguageTool. ใบอนุญาตอนุญาตให้เราใช้งานได้อย่างอิสระตามวัตถุประสงค์ของเรา: เป็นบริการฟรี เขียนด้วยภาษา Java และโอเพ่นซอร์ส นอกจากนี้ยังรองรับ 25 ภาษาและได้รับการพัฒนามานานกว่าสิบห้าปี แม้จะเปิดให้บริการอย่างเปิดกว้าง แต่ LanguageTool ก็เป็นคู่แข่งสำคัญในด้านโซลูชันการตรวจสอบข้อความที่ต้องชำระเงิน และความจริงที่ว่ามันสามารถทำงานได้ในพื้นที่นั้นถือเป็นฟีเจอร์ที่ยอดเยี่ยมอย่างแท้จริง

รหัสปลั๊กอินอยู่ใน ที่เก็บบน GitHub. โครงการทั้งหมดเขียนด้วย Kotlin พร้อมด้วย Java เพิ่มเติมเล็กน้อยสำหรับ UI ในระหว่างแฮ็กกาธอน เราจัดการเพื่อใช้การรองรับ Markdown, JavaDoc, HTML และ Plain Text หลังจากแฮ็กกาธอน การอัปเดตครั้งใหญ่ได้เพิ่มการรองรับ XML, ตัวอักษรสตริงใน Java, Kotlin และ Python และการตรวจสอบการสะกด

ความยากลำบาก

เรารู้ได้อย่างรวดเร็วว่าหากเราป้อนข้อความทั้งหมดไปที่ LanguageTool เพื่อตรวจสอบทุกครั้ง อินเทอร์เฟซ IDEA จะหยุดทำงานบนข้อความที่จริงจังไม่มากก็น้อย เนื่องจากการตรวจสอบจะบล็อกโฟลว์ UI เอง ปัญหาได้รับการแก้ไขแล้วด้วยการตรวจสอบ `ProgressManager.checkCancelled` - ฟังก์ชันนี้จะส่งข้อยกเว้นหาก IDEA เชื่อว่าถึงเวลาที่ต้องยกเลิกการตรวจสอบ

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

LanguageTool รองรับมากกว่า 25 ภาษา แต่ไม่น่าเป็นไปได้ที่ผู้ใช้คนใดคนหนึ่งจะต้องการภาษาทั้งหมด ฉันต้องการให้โอกาสในการดาวน์โหลดไลบรารีสำหรับภาษาใดภาษาหนึ่งเมื่อมีการร้องขอ (หากคุณทำเครื่องหมายใน UI) เราได้นำสิ่งนี้ไปใช้แล้ว แต่กลับกลายเป็นว่าซับซ้อนเกินไปและไม่น่าเชื่อถือ โดยเฉพาะอย่างยิ่ง เราต้องโหลด LanguageTool ด้วยชุดภาษาใหม่โดยใช้ classloader แยกต่างหาก จากนั้นจึงเริ่มต้นภาษาอย่างระมัดระวัง ในเวลาเดียวกัน ไลบรารีทั้งหมดอยู่ในพื้นที่เก็บข้อมูล .m2 ของผู้ใช้ และในแต่ละการเริ่มต้น เราต้องตรวจสอบความสมบูรณ์ของไลบรารีเหล่านั้น ท้ายที่สุด เราตัดสินใจว่าหากผู้ใช้มีปัญหากับขนาดของปลั๊กอิน เราจะจัดเตรียมปลั๊กอินแยกต่างหากสำหรับภาษายอดนิยมหลายภาษา

หลังจากแฮ็กกาธอน

Hackathon สิ้นสุดลงแล้ว แต่การทำงานกับปลั๊กอินยังคงดำเนินต่อไปกับทีมที่แคบกว่า ฉันต้องการสนับสนุนสตริง ความคิดเห็น และแม้แต่โครงสร้างภาษา เช่น ชื่อตัวแปรและคลาส ขณะนี้รองรับเฉพาะ Java, Kotlin และ Python เท่านั้น แต่เราหวังว่ารายการนี้จะเพิ่มขึ้น เราได้แก้ไขข้อบกพร่องเล็กๆ น้อยๆ มากมายและเข้ากันได้กับเครื่องตรวจตัวสะกดในตัวของ Idea มากขึ้น นอกจากนี้ ยังมีการรองรับ XML และการตรวจตัวสะกดอีกด้วย ทั้งหมดนี้สามารถพบได้ในเวอร์ชันที่สองซึ่งเราเผยแพร่เมื่อเร็ว ๆ นี้

ทำอะไรต่อไป

ปลั๊กอินดังกล่าวมีประโยชน์ไม่เพียง แต่สำหรับนักพัฒนาเท่านั้น แต่ยังสำหรับนักเขียนด้านเทคนิคด้วย (ซึ่งมักจะใช้งานได้เช่นกับ XML ใน IDE) ทุกวันพวกเขาต้องทำงานด้วยภาษาที่เป็นธรรมชาติ โดยไม่ต้องมีผู้ช่วยในรูปแบบของเคล็ดลับเกี่ยวกับข้อผิดพลาดที่อาจเกิดขึ้น ปลั๊กอินของเราให้คำแนะนำดังกล่าวและดำเนินการด้วยความแม่นยำสูง
เราวางแผนที่จะพัฒนาปลั๊กอินทั้งโดยการเพิ่มภาษาใหม่และโดยการสำรวจแนวทางทั่วไปในการจัดการตรวจสอบข้อความ แผนเร่งด่วนของเราประกอบด้วยการใช้โปรไฟล์โวหาร (ชุดกฎที่กำหนดแนวทางสไตล์สำหรับข้อความ เช่น "อย่าเขียน เช่น แต่เขียนแบบเต็ม") ขยายพจนานุกรมและปรับปรุงอินเทอร์เฟซผู้ใช้ (โดยเฉพาะ เราต้องการให้โอกาสผู้ใช้ไม่เพียงแค่เพิกเฉยต่อคำศัพท์ แต่เพื่อเพิ่มลงในพจนานุกรมเพื่อระบุส่วนของคำพูด)

ที่มา: www.habr.com

เพิ่มความคิดเห็น