Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEA

We praten verder over de projecten van de voorjaarshackathon DevDays, waaraan studenten van de masteropleiding deelnamen "Softwareontwikkeling / Software-engineering".

Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEA

Overigens willen wij graag lezers uitnodigen om mee te doen VK-groep masterstudenten. Daarin publiceren we het laatste nieuws over werving en studeren. Een filmpje van de open dag is ook te vinden in de groep. We herinneren je eraan: het evenement vindt plaats op 29 april, details online.

Telegram Desktop Voice Message Parser

Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEA

Idee auteur
Chorosjev Artjom

Team samenstelling

Khoroshev Artem – projectmanager/ontwikkelaar/QA
Eliseev Anton – bedrijfsanalist/marketingspecialist
Maria Kuklina – UI-ontwerper/ontwikkelaar
Bakhvalov Pavel – UI-ontwerper/ontwikkelaar/QA

Vanuit ons oogpunt is Telegram een ​​moderne en handige messenger, en de pc-versie is populair en open source, waardoor het mogelijk is om deze aan te passen. De client biedt behoorlijk rijke functionaliteit. Naast standaard sms-berichten bevat het spraakoproepen, videoberichten en spraakberichten. En het zijn deze laatste die soms ongemak voor de ontvanger met zich meebrengen. Het is vaak niet mogelijk om een ​​gesproken bericht te beluisteren terwijl u achter een computer of laptop zit. Er kan sprake zijn van omgevingsgeluid, het ontbreken van een koptelefoon of u wilt niet dat iemand de inhoud van het bericht kan horen. Dergelijke problemen doen zich vrijwel nooit voor als je Telegram op een smartphone gebruikt, omdat je hem, in tegenstelling tot een laptop of pc, gewoon naar je oor kunt brengen. Wij hebben geprobeerd dit probleem op te lossen.

Het doel van ons project bij DevDays was om de mogelijkheid toe te voegen om ontvangen gesproken berichten in tekst te vertalen naar de Telegram desktopclient (hierna Telegram Desktop genoemd).

Alle analogen van dit moment zijn bots waarnaar je een audiobericht kunt sturen en als antwoord een sms kunt ontvangen. Wij zijn hier niet zo blij mee: een bericht doorsturen naar een bot is niet zo handig; we willen graag native functionaliteit hebben. Bovendien is elke bot een derde partij die als tussenpersoon fungeert tussen de spraakherkennings-API en de gebruiker, en dit is op zijn minst onveilig.

Zoals eerder opgemerkt heeft Telegram-desktop twee belangrijke voordelen: bedieningsgemak en snelheid. En dat is geen toeval, want het is volledig in C++ geschreven. En omdat we besloten om nieuwe functionaliteit rechtstreeks aan de klant toe te voegen, moesten we deze in C++ ontwikkelen.

Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEAEr waren 4 mensen in ons team. Aanvankelijk waren twee mensen op zoek naar een geschikte bibliotheek voor spraakherkenning, één persoon bestudeerde de broncode van Telegram-desktop, een ander was bezig met het bouwproject Telegram Desktop. Later was iedereen bezig met het repareren van de gebruikersinterface en het opsporen van fouten.

Het leek erop dat het implementeren van de beoogde functionaliteit niet moeilijk zou zijn, maar zoals altijd deden zich problemen voor.

De oplossing voor het probleem bestond uit twee onafhankelijke deeltaken: het kiezen van een geschikt hulpmiddel voor spraakherkenning en het implementeren van een gebruikersinterface voor nieuwe functionaliteit.

Bij het kiezen van een bibliotheek voor stemherkenning moesten we meteen alle offline API’s laten varen, omdat taalmodellen veel ruimte in beslag nemen. Maar we hebben het over slechts één taal. Het werd duidelijk dat we gebruik zouden moeten maken van de online API. Later bleek dat de spraakherkenningsdiensten van giganten als Google, Yandex en Microsoft helemaal niet gratis zijn en dat we genoegen zullen moeten nemen met een proefperiode. Als gevolg hiervan werd voor Google Speech-To-Text gekozen, omdat u hiermee een token kunt krijgen voor het gebruik van de dienst, die een heel jaar geldig is.

Het tweede probleem dat we tegenkwamen houdt verband met enkele tekortkomingen van C++: een dierentuin van verschillende bibliotheken bij gebrek aan een gecentraliseerde repository. Het komt zo voor dat Telegram Desktop afhankelijk is van veel andere versiespecifieke bibliotheken. De officiële repository heeft instructie voor het samenstellen van het project. En ook een groot aantal openstaande issues over bijvoorbeeld bouwproblemen tijd и два. Alle problemen bleken verband te houden met het feit dat het build-script was geschreven voor Ubuntu 14.04, en om Telegram met succes te bouwen onder Ubuntu 18.04 moesten er wijzigingen worden aangebracht.

Het in elkaar zetten van Telegram Desktop zelf duurt behoorlijk lang: op een laptop met een Intel Core i5-7200U duurt de volledige montage (vlag -j 4) met alle afhankelijkheden ongeveer drie uur. Hiervan wordt ongeveer 30 minuten besteed aan het koppelen van de client zelf (later bleek dat in de Debug-configuratie het koppelen ongeveer 10 minuten duurt), maar de koppelingsfase moet elke keer na het aanbrengen van wijzigingen worden herhaald.

Ondanks de problemen zijn we erin geslaagd het bedachte idee te implementeren en bij te werken script bouwen voor Ubuntu 18.04. Een demonstratie van het werk is te zien op link. We voegen ook verschillende animaties toe. Naast alle gesproken berichten is een knop verschenen waarmee je het bericht naar tekst kunt vertalen. Door met de rechtermuisknop te klikken, kunt u bovendien de taal opgeven die voor de uitzending wordt gebruikt. Door link client beschikbaar om te downloaden.

Opslagplaats.

Het bleek naar onze mening een goede Proof of Concept van functionaliteit die voor veel gebruikers handig zou zijn. We hopen dit in toekomstige releases van Telegram Desktop te zien.

Verbeterde natuurlijke taalondersteuning in IntelliJ IDEA

Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEA

Idee auteur

Tankov Vladislav

Team samenstelling

Tankov Vladislav (teamleider, werkzaam met LanguageTool en IntelliJ IDEA)
Nikita Sokolov (werkt met LanguageTool en maakt gebruikersinterface)
Khvorov Alexander (werken met LanguageTool en optimaliseren van de prestaties)
Sadovnikov Alexander (ondersteuning voor het parseren van opmaaktalen en code)

We hebben voor IntelliJ IDEA een plug-in ontwikkeld die verschillende teksten (commentaar en documentatie, letterlijke regels in code, tekst opgemaakt in Markdown of XML-markup) controleert op grammaticale, spelling- en stilistische nauwkeurigheid (in het Engels heet dit proeflezen).

Het idee van het project was om de standaard spellingcontrole IntelliJ IDEA uit te breiden naar de schaal van Grammatica, om een ​​soort Grammatica binnen IDE te maken.

Je kunt zien wat er is gebeurd link.

Welnu, hieronder zullen we in meer detail praten over de mogelijkheden van de plug-in, evenals de moeilijkheden die zich voordeden tijdens de creatie ervan.

Motivatie

Er zijn veel producten ontworpen voor het schrijven van tekst in natuurlijke talen, maar documentatie en codecommentaar worden meestal in ontwikkelomgevingen geschreven. Tegelijkertijd zijn IDE's uitstekend in het opsporen van fouten in code, maar zijn ze slecht geschikt voor teksten in natuurlijke talen. Dit maakt het heel gemakkelijk om fouten te maken in grammatica, interpunctie of stijl zonder dat de ontwikkelomgeving hierop wijst. Het is van het grootste belang om een ​​fout te maken bij het schrijven van de gebruikersinterface, omdat dit niet alleen de begrijpelijkheid van de code zal beïnvloeden, maar ook de gebruikers van de ontwikkelde applicatie zelf.

Een van de meest populaire en ontwikkelde ontwikkelomgevingen is IntelliJ IDEA, evenals IDE's gebaseerd op het IntelliJ Platform. IntelliJ Platform heeft al een ingebouwde spellingcontrole, maar deze verwijdert zelfs de eenvoudigste grammaticale fouten niet. We hebben besloten om een ​​van de populaire systemen voor natuurlijke taalanalyse te integreren in IntelliJ IDEA.

uitvoering

Hackathon DevDays'19 (deel 2): ​​parser voor audioberichten voor Telegram- en grammaticacontrole in IntelliJ IDEAWe hebben onszelf niet de taak gesteld om ons eigen tekstverificatiesysteem te creëren, dus hebben we een bestaande oplossing gebruikt. De meest geschikte optie bleek te zijn LanguageTool. Dankzij de licentie konden we het vrij gebruiken voor onze doeleinden: het is gratis, geschreven in Java en open-source. Daarnaast ondersteunt het 25 talen en is het al ruim vijftien jaar in ontwikkeling. Ondanks zijn openheid is LanguageTool een serieuze concurrent van betaalde oplossingen voor tekstverificatie, en het feit dat het lokaal kan werken is letterlijk de killer feature.

De plug-incode is binnen opslagplaatsen op GitHub. Het hele project is geschreven in Kotlin met een kleine toevoeging van Java voor de gebruikersinterface. Tijdens de hackathon zijn we erin geslaagd ondersteuning te implementeren voor Markdown, JavaDoc, HTML en Plain Text. Na de hackathon voegde een grote update ondersteuning toe voor XML, letterlijke tekenreeksen in Java, Kotlin en Python, en spellingcontrole.

Moeilijkheden

Al snel realiseerden we ons dat als we elke keer alle tekst ter inspectie aan LanguageTool doorgeven, de IDEA-interface vastloopt bij min of meer serieuze tekst, omdat de inspectie zelf de UI-stroom blokkeert. Het probleem is opgelost via de controle `ProgressManager.checkCancelled` - deze functie genereert een uitzondering als IDEA van mening is dat het tijd is om de inspectie af te breken.

Dit elimineerde de bevriezingen volledig, maar het is onmogelijk om te gebruiken: het verwerken van de tekst duurt erg lang. Bovendien verandert in ons geval meestal een heel klein deel van de tekst en willen we de resultaten op de een of andere manier in de cache opslaan. Dat is precies wat wij deden. Om niet elke keer alles te controleren, hebben we de tekst deterministisch in stukken gesplitst en alleen de stukken gecontroleerd die veranderd waren. Omdat de teksten groot kunnen zijn en we de cache niet wilden laden, hebben we niet de teksten zelf opgeslagen, maar hun hashes. Hierdoor kon de plug-in zelfs bij grote bestanden soepel werken.

LanguageTool ondersteunt meer dan 25 talen, maar het is onwaarschijnlijk dat één gebruiker ze allemaal nodig heeft. Ik wilde de mogelijkheid bieden om op verzoek bibliotheken voor een specifieke taal te downloaden (als je dit in de gebruikersinterface aanvinkt). We hebben dit zelfs geïmplementeerd, maar het bleek te ingewikkeld en onbetrouwbaar. In het bijzonder moesten we LanguageTool laden met een nieuwe set talen met behulp van een aparte classloader, en deze vervolgens zorgvuldig initialiseren. Bovendien bevonden alle bibliotheken zich in een gebruikers-.m2-repository, en bij elke start moesten we hun integriteit controleren. Uiteindelijk hebben we besloten dat als gebruikers problemen hadden met de grootte van de plug-in, we een aparte plug-in zouden aanbieden voor een aantal van de meest populaire talen.

Na de hackathon

De hackathon eindigde, maar het werk aan de plug-in werd voortgezet met een kleiner team. Ik wilde tekenreeksen, opmerkingen en zelfs taalconstructies ondersteunen, zoals namen van variabelen en klassen. Momenteel wordt dit alleen ondersteund voor Java, Kotlin en Python, maar we hopen dat deze lijst nog zal groeien. We hebben een heleboel kleine bugs opgelost en zijn beter compatibel geworden met de ingebouwde spellingcontrole van Idea. Daarnaast zijn XML-ondersteuning en spellingcontrole verschenen. Dit alles is te vinden in de tweede versie, die we onlangs hebben gepubliceerd.

Wat is het volgende?

Zo'n plug-in kan niet alleen nuttig zijn voor ontwikkelaars, maar ook voor technische schrijvers (die bijvoorbeeld vaak met XML in een IDE werken). Elke dag moeten ze met natuurlijke taal werken, zonder dat ze een assistent hebben in de vorm van redacteurtips over mogelijke fouten. Onze plug-in biedt dergelijke tips en doet dit met een hoge mate van nauwkeurigheid.
We zijn van plan de plug-in te ontwikkelen, zowel door nieuwe talen toe te voegen als door een algemene benadering te verkennen voor het organiseren van tekstcontrole. Onze onmiddellijke plannen omvatten de implementatie van stilistische profielen (reeksen van regels die een stijlgids voor tekst definiëren, bijvoorbeeld “schrijf niet bijvoorbeeld, maar schrijf de volledige vorm”), het uitbreiden van het woordenboek en het verbeteren van de gebruikersinterface (in het bijzonder: we willen de gebruiker niet alleen de mogelijkheid geven een woord te negeren, maar het ook aan het woordenboek toe te voegen, met vermelding van de woordsoort).

Bron: www.habr.com

Voeg een reactie