EP1810277A1 - Procede de construction distribuee d'un modele de reconnaissance vocale , dispositif, serveur et programmes d'ordinateur pour mettre en uvre un tel procede - Google Patents

Procede de construction distribuee d'un modele de reconnaissance vocale , dispositif, serveur et programmes d'ordinateur pour mettre en uvre un tel procede

Info

Publication number
EP1810277A1
EP1810277A1 EP05815123A EP05815123A EP1810277A1 EP 1810277 A1 EP1810277 A1 EP 1810277A1 EP 05815123 A EP05815123 A EP 05815123A EP 05815123 A EP05815123 A EP 05815123A EP 1810277 A1 EP1810277 A1 EP 1810277A1
Authority
EP
European Patent Office
Prior art keywords
server
modeling
entity
modeled
parameters
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05815123A
Other languages
German (de)
English (en)
Inventor
Denis Jouvet
Jean Monne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1810277A1 publication Critical patent/EP1810277A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/06—Creation of reference templates; Training of speech recognition systems, e.g. adaptation to the characteristics of the speaker's voice
    • G10L15/063—Training
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/28—Constructional details of speech recognition systems
    • G10L15/30—Distributed recognition, e.g. in client-server systems, for mobile phones or network applications

Definitions

  • the present invention relates to the field of embedded speech recognition, and more particularly the field of the manufacture of voice recognition models used in the context of embedded recognition.
  • a user terminal practicing on-board recognition captures a voice signal to be recognized from the user. It compares it with predetermined recognition patterns stored in the user terminal each corresponding to a word (or a sequence of words) to recognize, among them, the word (or sequence of words) that has been pronounced by the user . Then he performs an operation according to the recognized word.
  • the embedded recognition avoids the transfer delays occurring in the case of centralized or distributed recognition and due to network exchanges between the user terminal and a server then performing all or part of the recognition tasks.
  • Embedded discovery is especially effective for speech recognition tasks such as the custom directory.
  • the model of a word is a set of information representing several ways of pronouncing the word (accentuation / omission of certain phonemes and / or variety of speakers etc.). Models can also model, not a word, but a sequence of words. It is possible to manufacture the model of a word, from an initial representation of the word, this initial representation being able to be textual (string of characters) or still vocal. In some cases, the models corresponding to the vocabulary
  • the templates are fabricated on a server and then downloaded to the user terminal.
  • the document EP 1 047 046 describes an architecture comprising a user terminal, comprising an on-board recognition module, and a server connected by a communication network.
  • the user terminal captures an entity to be modeled, for example a contact name intended to be stored in a voice directory of the user terminal. Then it sends to the server data representative of the contact name.
  • the server determines from these data a reference model representative of the contact name (for example a Markov model) and communicates it to the user terminal, which stores it in a reference model lexicon associated with the speech recognition module. .
  • this architecture involves the transmission to the user terminal of all the parameters of the reference model for each contact name to be registered, which implies a large number of data to be transmitted, and therefore significant communication costs and delays.
  • the present invention aims to propose a solution not having _3Q_ such disadvantages ⁇
  • the invention proposes a method of distributed construction of a voice recognition model of an entity to be modeled.
  • the model is intended to be used by a device with a built models and a reference database storing modeling elements.
  • the device is able to communicate with a server via a communication link.
  • the method comprises at least the following steps: the device obtains the entity to be modeled;
  • the device transmits data representative of the entity on the communication link destined for the server;
  • the server receives the data to be modeled and carries out a processing to determine from these data a set of modeling parameters indicating modeling elements;
  • the server transmits on the communication link destined for the device the modeling parameters
  • the device receives the modeling parameters and determines the voice recognition model of the entity to be modeled according to at least the modeling parameters and at least one modeling element stored in the reference base and indicated in the transmitted modeling parameters;
  • the device stores the voice recognition model of the entity to be modeled in the base of built models.
  • the device is an on-board voice recognition user terminal.
  • the invention thus makes it possible to benefit from the power of resources available on a server and thus not to be limited during the first stages of the construction of the model by memory dimension constraints specific to the device, for example a user terminal, while by limiting the amount of data transferred over the network.
  • the transferred data do not correspond to the complete model corresponding to the entity to be modeled, but to information that will enable the device to build the complete model, by relying on a generic knowledge base-stored-in- the device:
  • the invention makes it possible, by centralized evolution, maintenance and / or updating operations, carried out on the knowledge bases of the server, to make the devices benefit from these evolutions.
  • the invention proposes a device capable of communicating with a server via a communication link. He understands :
  • a reference database storing modeling elements
  • the device is adapted to implement the steps of a method according to the first aspect of the invention which are incumbent on the device, to form the model of the entity to be modeled;
  • the device is a user terminal for performing embedded voice recognition using on-board voice recognition means adapted to compare data representative of an audio signal to be recognized captured by the user terminal, to speech recognition patterns stored in the user terminal.
  • the invention proposes a server for performing a part of recognition model manufacturing tasks.
  • the server includes: means for receiving, via the communication link, data to be modeled transmitted by the device;
  • the server is further adapted to implement the steps of a method according to the first aspect of the invention which is the responsibility of the server.
  • the invention proposes a computer program for creating speech recognition models from an entity to be modeled, executable by a processing unit of a device intended to perform on-board voice recognition.
  • This user program comprises instructions for performing the steps, which are the responsibility of the device, of a method according to the first aspect of the invention, during a program execution by the processing unit.
  • the invention provides a computer program for forming speech recognition models, executable by a processing unit of a server and comprising instructions for executing the steps, which are the responsibility of the server, of a method according to the first aspect of the invention, during a program execution by the processing unit.
  • FIG. 1 represents a system comprising a user terminal and a server in an implementation mode of the invention
  • FIG. 2 represents a lexical graph determined from the character string ⁇ ⁇ cPetit "by a server in one embodiment of the invention
  • FIG. 3 represents a lexical graph determined from the "small” character string, taking into account the contexts by a server in one embodiment of the invention
  • FIG. 4 represents an acoustic modeling graph determined from the string "Small" by a server in one embodiment of the invention.
  • FIG. 1 represents a user terminal 1, which comprises a voice recognition module 2, a lexicon 5 storing recognition patterns, a model making module 6 and a reference base 7.
  • the reference base 7 stores elements of modelization. These elements were previously provided in a configuration step of the base 7 of the terminal, factory or download.
  • each contact name in the directory is associated with a respective recognition model stored in the lexicon 5, which thus includes the set of recognizable contact names.
  • the corresponding signal is captured using a microphone 3 and supplied at the input of the recognition module 2.
  • This module 2 implements a recognition algorithm analyzing the signal (for example by performing an acoustic analysis to determine a sequence of frames and associated cepstral coefficients) and determining if it corresponds to one of the recognition models stored in lexicon 5.
  • the user terminal 1 dials the phone number stored in the voice directory in association with the name of the recognized contact.
  • the models stored in the lexicon 5 are for example Markov models corresponding to the names of the contacts. It is recalled that a model probability density and a Markov chain. It allows the calculation of the probability of an observation X for a given message m.
  • the manufacture of the recognition models stored in the lexicon 5 is distributed between the user terminal 1 and a server 9.
  • the server 9 and the user terminal 1 are connected by a bidirectional link 8.
  • the server 9 comprises a module 10 for determining modeling parameters and a plurality of bases 11 comprising rules of the lexical and / or syntactic and / or acoustic type and / or knowledge relating in particular to the variants depending on the languages, the accents , exceptions in the field of proper names etc.
  • the plurality of bases 11 thus makes it possible to obtain the set of possible pronunciation variants of an entity to be modeled, when such modeling is desired.
  • the user terminal 1 is adapted to obtain an entity to be modeled 15 (in the case considered here: the "PETIT" contact name) provided by the user, for example in textual form, via keys included in the terminal. user 1.
  • entity to be modeled 15 in the case considered here: the "PETIT" contact name
  • the user terminal 1 then establishes a data mode connection via the communication link 8, and sends the server 9 via this link 8 the character string "Small” corresponding to the word "PETIT”. .
  • the server 9 receives the character string and performs processing using the module 10 and the plurality of bases 11, to output a set of modeling parameters indicating modeling elements.
  • the server 9 sends the modeling parameters to the user terminal 1.
  • the user terminal 1 receives these modeling parameters that indicate modeling elements, extracted from the reference base 7
  • the reference base 7 includes a recognition pattern for each phoneme, for example a Markov model.
  • the module 10 for determining modeling parameters of the server 9 is adapted to determine a phonetic graph corresponding to the string of characters received. Using the plurality of bases 11, it thus determines from the received character string, the different possible pronunciations of the word. Then he represents each of these pronunciations in the form of a succession of phonemes. Thus, from the "Small" character string received, the module 10 of the server determines the two following pronunciations: p.e.t.i. or p.t.i, depending on whether the mute e is pronounced or not. These variants correspond to respective successions of phonemes, represented jointly in the form p. (e I ()). t. i or by the phonetic graph shown in FIG.
  • the server 9 then returns to the user terminal 1 a set of modeling parameters describing these variants.
  • the exchange is for example the following: Terminal -> Server: "Small” Server -> Terminal: p. (e I ()). t. i.
  • the user terminal When the user terminal receives these modeling parameters describing phoneme sequences, it constructs the model of the word "PETIT" from the phonetic graph, and Markov models stored in the modeling element database for each of the phonemes / p /, / e /, / t /, / i /. Then he stores the Markov model thus constructed for the contact name "PETIT" in lexicon 5.
  • the reference base 7 of the user terminal 1 can store sets of phoneme models for several languages.
  • the server 10 also transmits an indication on the game to use.
  • the exchange will for example be of the type:
  • Terminal -> Server "Small"
  • the server 9, using the plurality of bases 11, detects and takes into account the language of "supposed” origin of the name. He thus generates relevant variants of pronunciation for this one (see “Generating proper name pronunciation variants for automatic recognition", by K. Bartkova, Proceedings ICPhS'2003, 15 th International Congress of Phonetic Sciences, Barcelona, Spain, 3- August 9, 2003, pp 1321-1324).
  • the module 10 for determining modeling parameters of the server 9 is adapted to take into account, in addition, the contextual influences, that is to say the 1 phonemes which preceding and following the current phoneme, as shown in Figure 3.
  • the module 10 in one embodiment can then send modeling parameters describing the phonetic graph taking into account the contexts.
  • the reference base 7 comprises the Markov models of the phonemes taking into account the contexts.
  • niodes_-de_ -Setting - in- Oedomain- of - the invention - can "î ⁇ pTés ⁇ ntêf of 'pronunciations as a succession of phonetic units other than phonemes, eg polyphonic (Contd several phonemes) or sub-phonetic units which take into account, for example, the separation between the holding and the explosion of the plosives.
  • the base 7 comprises respective models of such phonetic units.
  • the server takes into account the contexts.
  • it is the terminal that will take into account the contexts for the modeling, on the basis of a lexical description (for example a standard lexical graph simply indicating the phonemes) transmitted by the server, of the entity to be modeled.
  • the module 10 of the server 9 is adapted to determine, from the information sent by the terminal relating to the entity to be modeled, an acoustic modeling graph.
  • Such an acoustic modeling graph determined by the module 10 from the phonetic graph obtained from the string "Petit” is represented in FIG. 4. This graph is the support of the model of
  • Circles, numbered 1 to 14, represent the states of the chain of
  • the D labels designate the probability density functions, which model the spectral shapes that are observed on a signal and that result from an acoustic analysis.
  • the Markov chain constrains the temporal order in which these spectral forms must be observed. We consider here that the densities of probabilities are associated with the states of the Markov chain (in another embodiment, the densities are associated with the transitions).
  • the upper part of the graph corresponds to the pronunciation variant p.e.t.i
  • the lower part corresponds to the variant p .t.i.
  • Dp1, Dp2, Dp3 denote three densities associated with the phoneme / p /.
  • De1, De2, De3 denote the three densities associated with the phoneme IeI; Dtl, JDt2, D_t3-müsignent- three densities associated to ⁇ ⁇ phc7ré7 ⁇ T ⁇ "7t /" èTD ⁇ 1 'Di2,
  • Di3 denote the three densities associated with the phoneme IM.
  • the choice of three states and densities by phoneme acoustic model (corresponding respectively to the beginning, the middle and the end of the phoneme) is common, but not unique. Indeed, one can use more or less states and densities for each model of phoneme.
  • Each density is in fact made up of a weighted sum of several Gaussian functions defined on the space of the acoustic parameters (space corresponding to the measurements made on the signal to be recognized).
  • some Gaussian functions of some densities are schematically represented.
  • Dp1 for example:
  • the server 9 is adapted to transmit to the user terminal 1 information from the acoustic modeling graph determined by the module 10, which provides the list of successive transitions between states and indicates for each state. the identifier of the associated density.
  • the exchange is for example of the type: Terminal -> Server: "Small"
  • the first block of information transmitted between the ⁇ Transitions-15 Graph> and ⁇ / Transitions-Graph> tags thus describes all 28 transitions of the acoustic graph, with each starting state and each arrival state.
  • ⁇ / Density States> describes the association of the densities with the states of the graph, by specifying the pairs state / identifier of associated density.
  • the reference base 7 has the parameters of the probability densities associated with the received identifiers. These parameters are parameters of description and / or precision of the densities.
  • the received density identifier Dp1 For example, from the received density identifier Dp1, it provides the weighted sum describing the density, as well as the value of the weighting coefficients and the parameters of the Gaussians involved in the summation.
  • the user terminal 1 When the user terminal 1 receives the modeling parameters described above, it extracts the base 7 parameters densities 30. probability associés- to the identifiers listed in the "block ⁇ ⁇ Eîàts-Oe ⁇ siFés>, and builds the model of the word "SMALL" from these density parameters and modeling parameters. Then he stores the model thus constructed for the contact name "PETIT" in lexicon 5.
  • the server 9 is adapted to transmit to the user terminal 1 information from the acoustic modeling graph determined by the module 10, which provides, in addition to the list of successive transitions between states and the identifier of the associated density for each state as before, the definition of densities according to the Gaussian functions.
  • the server 9 sends to the user terminal 1, in addition to the two blocks of information described above, a block of additional information transmitted between the tags ⁇ Densities-
  • Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Gaussian Weights Gaussian Gaussian Weights , Dp2, ..., Di3 of the graph are to be described:
  • the reference base 7 has parameters describing the Gaussian associated with the received identifiers.
  • the user terminal When the user terminal receives the modeling parameters described above, it constructs the model of the word "PETIT" from these paj; aji ⁇ èjres_et ⁇ pj ⁇ r_cjtaii_5aussienne - indicated - in-the-bloe - ⁇ - Densities-
  • Gaussian> from the parameters stored in the reference base 7.
  • the server knows the state of the reference base 7 of the terminal 1 and knows how to determine what is stored or not in the base 7. It is adapted to provide only the description of the phonetic graph when it determines that the models of the phonemes present in the phonetic graph are stored in the base 7. For the phonemes whose models are not described in the base 7, it determines the acoustic modeling graph. It supplies the user terminal 1 with the information of the ⁇ Transitions-Graph> and ⁇ Density-state> blocks relating to the densities that it determines as known from the base 7. It furthermore provides the information of the ⁇ Gaussian-Density> block relating to the density not defined in the base 7 of the user terminal.
  • the server 9 does not know the contents of the reference base 7 of the user terminal 1, and the latter is adapted, in the event that it receives information from the server 9 comprising an identifier of a data element.
  • modeling for example a probability density or a Gaussian
  • the reference base 7 does not include the parameters of the modeling element thus identified, to send a request to the server 9 to obtain these missing parameters in order to determine the modeling element and enrich the baseline.
  • the server 9 can search among the modeling units that it knows to be available in the reference base 7, which resemble "those most required by a new model to be constructed corresponding to a different language. In this case, it can adapt the modeling parameters to be transmitted to the user terminal 1 to describe as much as possible the model or a modeling element absent from the base 7 and required by the user terminal, as a function of the modeling elements stored in the complementary to ⁇ transfer and store in the terminal.
  • the example described above corresponds to the provision by the user terminal of the entity to be modeled in text form, for example via the keyboard.
  • Other modes of input or recovery of the entity to be modeled can be implemented according to the invention.
  • the entity to be modeled is retrieved by the user terminal 1 from a received call identifier (display name / number).
  • the entity to be modeled is captured by the user terminal 1 from one or more examples of pronunciation of the contact name by the user.
  • the user terminal 1 transmits to the server 9 these examples of the entity to be modeled (either directly in acoustic form, or after an analysis 0 determining acoustic parameters, for example cepstral coefficients).
  • the server 9 is then adapted, from the received data, to determine a phonetic graph and / or an acoustic modeling graph (directly from the data for example in a monolocutor type approach or after the determination of the phonetic graph), and send the modeling parameters to the user terminal 1.
  • the terminal uses these modeling parameters (which in particular indicate modeling elements described in the base 7) and the model elements thus indicated 0 and available in the base 7, to construct the model
  • the user terminal 1 is adapted to optimize the lexicon of the models constructed, by factoring any redundancies. This operation consists in determining the parts common to several models stored in the lexicon 5 (for example the identical beginning or end of the word). It makes it possible to avoid unnecessarily duplicating calculations during the decoding phase and thus to save the computing resource.
  • the factorization of the models can concern words, complete sentences or portions of sentences.
  • the factoring step is CL - performed.
  • parJe-server, ⁇ for example-from-a-list of words ⁇ sent " by " the terminal, or from a new word to model sent by the terminal and a list of words stored at the server and known by the server as listing words whose templates are stored in the terminal.
  • the server sends information relating to the common factors thus determined.
  • the user terminal 1 is adapted to send to the server 9, in addition to the entity to be modeled, additional information, for example the indication of the language used, so that the server performs a certain task. phonetic analysis accordingly, and / or the characteristics of the phonetic units to be provided or the acoustic models to be used, or the indication of the accent or any other characterization of the speaker allowing generation of pronunciation or modeling variants adapted to this speaker (note that this information can be stored on the server, if it can automatically identify the calling terminal) etc.
  • the solution according to the invention applies to all kinds of embedded recognition applications, the voice directory application indicated above being mentioned only as an example.
  • the lexicon 5 described above has recognizable contact names; however, it may have common names and / or recognizable phrases.
  • Transmissions from the server can be in the form of sending blocks of data in response to a particular request from the terminal, or by sending blocks with tags similar to those presented above.
  • the examples described above correspond to the implementation of the invention within a user terminal.
  • the co ⁇ struction of models-reGonnaissanee- is distributedernon ⁇ not ⁇ e ⁇ itre server cm and a user terminal, but between a server and a gateway adapted to be connected to several user terminals, for example a residential gateway, within the same home (residential gateway).
  • This configuration allows to pool the construction of the models.
  • voice recognition is performed either exclusively by the user terminal (the models constructed are transmitted to it by the gateway), or by the gateway, or by both in the case of a terminal. distributed recognition.
  • the present invention therefore makes it possible advantageously to take advantage of multiple databases of knowledge of the server (for example multilingual) for the constitution of models, bases which can not, for reasons of memory capacity, be installed on a device of the user terminal or gateway type while limiting the amount of information to be transmitted over the communication link between the device and the server.
  • the invention also allows greater ease of implementation of model determination evolutions, since it suffices to perform the maintenance, updating and evolution operations on the server's bases, and not on each other. device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Artificial Intelligence (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé de construction distribuée d'un modèle de reconnaissance vocale destiné à être utilisé par un dispositif (1) comportant une base (5) de modèles et une base de référence (7) stockant des éléments de modélisation, ledit procédé comportant les étapes suivantes: - le dispositif obtient l'entité à modéliser; - le dispositif transmet sur une liaison de communication à destination d'un serveur des données représentatives de l'entité; - le serveur détermine à partir des données transmises, un ensemble de paramètres de modélisation indiquant des éléments de modélisation; - le serveur transmet au dispositif les paramètres de modélisation; - le dispositif détermine le modèle de reconnaissance vocale de l'entité à modéliser en fonction d'au moins les paramètres de modélisation reçus et d'au moins un élément de modélisation stocké dans la base de référence et indiqué dans les paramètres transmis, puis mémorise le modèle de reconnaissance vocale dans la base de modèles.

Description

PROCEDE DE CONSTRUCTION DISTRIBUEE D'UN MODELE DE
RECONNAISSANCE VOCALE , DISPOSITIF, SERVEUR ET PROGRAMMES
D'ORDINATEUR POUR METTRE EN ŒUVRE UN TEL PROCEDE
La présente invention concerne le domaine de la reconnaissance de la parole embarquée, et plus particulièrement le domaine de la fabrication des modèles de reconnaissance vocale utilisés dans le cadre de la reconnaissance embarquée. Un terminal utilisateur pratiquant la reconnaissance embarquée, capture un signal vocal à reconnaître en provenance de l'utilisateur. Il le compare à des modèles de reconnaissance prédéterminés mémorisés dans le terminal utilisateur correspondant chacun à un mot (ou une séquence de mots) pour reconnaître, parmi ces derniers, le mot (ou la séquence de mots) qui a été prononcé par l'utilisateur. Puis il réalise une opération en fonction du mot reconnu.
La reconnaissance embarquée évite les délais de transfert survenant dans le cas de la reconnaissance centralisée ou distribuée et dus aux échanges sur le réseau entre le terminal utilisateur et un serveur effectuant alors tout ou partie des tâches de reconnaissance. La reconnaissance embarquée s'avère en particulier efficace pour des tâches de reconnaissance de parole telles que le répertoire personnalisé.
Le modèle d'un mot est un ensemble d'informations représentant plusieurs façons de prononcer le mot (accentuation/omission de certains phonèmes et/ou variété de locuteurs etc.). Les modèles peuvent également modéliser, non pas un mot, mais une séquence de mots. Il est possible de fabriquer le modèle d'un mot, à partir d'une représentation initiale du mot, cette représentation initiale pouvant être textuelle (chaîne de caractères) ou encore vocale. Dans certains cas, les modèles correspondant au vocabulaire
_reconnaissable- par- le 4erminal-(p^ar-exemple^le~coτitenir~du~rêpertoire)" sôήF fabriqués directement par le terminal. Aucune connexion avec un serveur n'est requise pour la fabrication des modèles, mais les ressources disponibles sur le terminal limitent fortement la capacité des outils de fabrication. Pour un bon traitement des noms propres, avec une bonne prédiction des variantes possibles de prononciation, il est préférable d'employer de gros lexiques d'exceptions, ainsi que de larges ensembles de règles. Une telle base de connaissances ne peut donc pas être facilement installée à demeure sur un 5 terminal. Dans le cas où la fabrication des modèles est locale au terminal utilisateur, la taille de la base de connaissances employée est réduite pour des raisons de contraintes de dimension de mémoire (moins de règles et moins de mots dans le lexique), ce qui fait que la prononciation de certains mots sera mal prédite.
10 De plus il est quasiment impossible d'installer simultanément sur le terminal des bases de connaissances pour plusieurs langues.
Dans d'autres cas, les modèles sont fabriqués sur un serveur, puis téléchargés en direction du terminal utilisateur.
Par exemple, le document EP 1 047 046 décrit une architecture 15 comprenant un terminal utilisateur, comportant un module de reconnaissance embarquée, et un serveur reliés par un réseau de communication. Selon ce document, le terminal utilisateur capture une entité à modéliser, par exemple un nom de contact destiné à être mémorisé dans un répertoire vocal du terminal utilisateur. Puis il envoie à destination du serveur des données 20 représentatives du nom de contact. Le serveur détermine à partir de ces données un modèle de référence représentatif du nom de contact (par exemple un modèle de Markov) et le communique au terminal utilisateur, qui le stocke dans un lexique de modèles de référence associé au module de reconnaissance de la parole.
25 Toutefois cette architecture implique la transmission au terminal utilisateur de tous les paramètres du modèle de référence pour chaque nom de contact à enregistrer, ce qui implique un grand nombre de données à transmettre, et donc des coûts et des délais de communication importants.
La présente invention vise à proposer une solution ne présentant pas _3Q_ de telsjn_convénientsτ
Suivant un premier aspect, l'invention propose un procédé de construction distribuée d'un modèle de reconnaissance vocale d'une entité à modéliser. Le modèle est destiné à être utilisé par un dispositif comportant une base de modèles construits et une base de référence stockant des éléments de modélisation. Le dispositif est apte à communiquer avec un serveur par l'intermédiaire d'une liaison de communication. Le procédé comporte au moins les étapes suivantes : - le dispositif obtient l'entité à modéliser ;
- le dispositif transmet sur la liaison de communication à destination du serveur des données représentatives de l'entité ;
- le serveur reçoit les données à modéliser et effectue un traitement pour déterminer à partir de ces données, un ensemble de paramètres de modélisation indiquant des éléments de modélisation ;
- le serveur transmet sur la liaison de communication à destination du dispositif les paramètres de modélisation ;
- le dispositif reçoit les paramètres de modélisation et détermine le modèle de reconnaissance vocale de l'entité à modéliser en fonction d'au moins les paramètres de modélisation et d'au moins un élément de modélisation stocké dans la base de référence et indiqué dans les paramètres de modélisation transmis ; et
- le dispositif mémorise le modèle de reconnaissance vocale de l'entité à modéliser dans la base de modèles construits. Dans un mode de mise en oeuvre avantageux de l'invention, le dispositif est un terminal utilisateur à reconnaissance vocale embarquée.
L'invention permet ainsi de bénéficier de la puissance de ressources disponibles sur un serveur et ainsi de ne pas être limité lors des premières étapes de la construction du modèle par des contraintes de dimension de mémoire propres au dispositif, par exemple un terminal utilisateur, tout en limitant la quantité des données transférées sur le réseau. En effet, les données transférées ne correspondent pas au modèle complet correspondant à l'entité à modéliser, mais à des informations qui vont permettre au dispositif de construire le modèle complet, en s'appuyant sur une base de connaissance générique-stockée-dans-le-dispositif:
Par ailleurs, l'invention permet, par des opérations d'évolution centralisées, de maintenance et/ou de mise à jour, réalisées sur les bases de connaissance du serveur, de faire bénéficier les dispositifs de ces évolutions. Suivant un second aspect, l'invention propose un dispositif apte à communiquer avec un serveur par l'intermédiaire d'une liaison de communication. Il comprend :
- une base de modèles construits ;
5 - une base de référence stockant des éléments de modélisation ;
- des moyens pour obtenir l'entité à modéliser ;
- des moyens pour transmettre sur la liaison de communication à destination du serveur des données représentatives de l'entité ;
- des moyens pour recevoir des paramètres de modélisation en 10 provenance du serveur, correspondant à l'entité à modéliser et indiquant des éléments de modélisation ; et
- des moyens pour déterminer le modèle de reconnaissance vocale de l'entité à modéliser en fonction d'au moins les paramètres de modélisation transmis et d'au moins un élément de modélisation stocké dans la base de
15 modélisation élémentaire et indiqué dans les paramètres de modélisation reçus ;
- des moyens pour mémoriser le modèle de reconnaissance vocale de l'entité à modéliser dans la base de modèles construits.
Le dispositif est adapté pour mettre en œuvre les étapes d'un procédé 20 selon le premier aspect de l'invention qui incombent au dispositif, pour constituer le modèle de l'entité à modéliser;
Dans un mode de réalisation, le dispositif est un terminal utilisateur destiné à effectuer de la reconnaissance vocale embarquée à l'aide de moyens de reconnaissance vocale embarqués adaptés pour comparer des données 25 représentatives d'un signal audio à reconnaître capturé par le terminal utilisateur, à des modèles de reconnaissance vocale mémorisés dans le terminal utilisateur.
Suivant un troisième aspect, l'invention propose un serveur pour effectuer une partie de tâches de fabrication de modèles de reconnaissance
3.0 vocale—destinés— à— être— mémorisés— et- utilisés- par-un-'dispositif" àptê~ a" communiquer avec le serveur par l'intermédiaire d'une liaison de communication. Le serveur comprend : - des moyens pour recevoir par l'intermédiaire de la liaison de communication des données à modéliser transmises par le dispositif ;
- des moyens pour effectuer un traitement pour déterminer à partir de ces données, un ensemble de paramètres de modélisation indiquant des éléments de modélisation ;
- des moyens pour transmettre sur la liaison de communication à destination du dispositif les paramètres de modélisation.
Le serveur est adapté en outre pour mettre en œuvre les étapes d'un procédé suivant le premier aspect de l'invention qui incombent au serveur. Suivant un quatrième aspect, l'invention propose un programme d'ordinateur de constitution de modèles de reconnaissance vocale à partir d'une entité à modéliser, exécutable par une unité de traitement d'un dispositif destiné à effectuer de la reconnaissance vocale embarquée. Ce programme utilisateur comprend des instructions pour exécuter les étapes, qui incombent au dispositif, d'un procédé suivant le premier aspect de l'invention, lors d'une exécution du programme par l'unité de traitement.
Suivant un cinquième aspect, l'invention propose un programme d'ordinateur de constitution de modèles de reconnaissance vocale, exécutable par une unité de traitement d'un serveur et comprenant des instructions pour exécuter les étapes, qui incombent au serveur, d'un procédé suivant le premier aspect de l'invention, lors d'une exécution du programme par l'unité de traitement.
D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : la figure 1 représente un système comportant un terminal utilisateur et un serveur dans un mode de mise en œuvre de l'invention ; la figure 2 représente un graphe lexical déterminé à partir de -la- chaîne-de- caractères ~<cPetït » par un serveur dans un mode de réalisation de l'invention ; la figure 3 représente un graphe lexical déterminé à partir de la chaîne de caractères « Petit » avec prise en compte des contextes par un serveur dans un mode de réalisation de l'invention ; la figure 4 représente un graphe de modélisation acoustique déterminé à partir de la chaîne de caractères « Petit », par un serveur dans un mode de réalisation de l'invention.
La figure 1 représente un terminal utilisateur 1 , qui comporte un module de reconnaissance vocale 2, un lexique 5 stockant des modèles de reconnaissance, un module de fabrication de modèles 6 et une base de référence 7. La base de référence 7 stocke des éléments de modélisation. Ces éléments lui ont été préalablement fournis dans une étape de configuration de la base 7 du terminal, en usine ou par téléchargement.
On considère ci-après l'application au répertoire vocal de la reconnaissance vocale opérée par le module 2. Dans ce cas, chaque nom de contact dans le répertoire est associé à un modèle de reconnaissance respectif stocké dans le lexique 5, qui comprend ainsi l'ensemble des noms de contacts reconnaissables.
Lorsque l'utilisateur énonce le nom d'un contact à reconnaître, le signal correspondant est capturé à l'aide d'un microphone 3 et fourni en entrée du module de reconnaissance 2. Ce module 2 met en œuvre un algorithme de reconnaissance analysant le signal (par exemple en effectuant une analyse acoustique pour déterminer une séquence de trames et des coefficients cepstraux associés) et déterminant s'il correspond à un des modèles de reconnaissance stockés dans le lexique 5. Dans le cas positif, c'est-à-dire lorsque le module de reconnaissance vocale a reconnu le nom du contact, le terminal utilisateur 1 compose alors le numéro de téléphone mémorisé dans le répertoire vocal en association avec le nom du contact reconnu.
Les modèles stockés dans le lexique 5 sont par exemple des modèles de Markov correspondant aux noms des contacts. On rappelle qu'un modèle densité de probabilité et d'une chaîne de Markov. Il permet le calcul de la probabilité d'une observation X pour un message m donné. Le document « Robustesse et flexibilité en reconnaissance automatique de la parole » de D. Jouvet, Echo des Recherches, n° 165, 3ème trimestre 1996, pp. 25-38, décrit notamment la modélisation markovienne de la parole.
Selon l'invention, la fabrication des modèles de reconnaissance stockés dans le lexique 5 est distribuée entre le terminal utilisateur 1 et un 5 serveur 9. Le serveur 9 et le terminal utilisateur 1 sont reliés par une liaison bidirectionnelle 8.
Le serveur 9 comporte un module 10 de détermination de paramètres de modélisation et une pluralité de bases 11 comportant des règles de type lexical et/ou syntaxique et/ou acoustique et/ou des connaissances relatives 10 notamment aux variantes en fonction des langues, des accents, aux exceptions dans le domaine des noms propres etc. La pluralité de bases 11 permet ainsi d'obtenir l'ensemble des variantes de prononciation possibles d'une entité à modéliser, lorsqu'on souhaite une modélisation de ce type.
Le terminal utilisateur 1 est adapté pour obtenir une entité à modéliser 15 (dans le cas considéré ici : le nom de contact « PETIT ») fourni par l'utilisateur, par exemple sous forme textuelle, par l'intermédiaire de touches que comporte le terminal utilisateur 1.
Le terminal utilisateur 1 établit ensuite une liaison en mode data par l'intermédiaire de la liaison de communication 8, et envoie au serveur 9 par 20 l'intermédiaire de cette liaison 8, la chaîne de caractères « Petit » correspondant au mot « PETIT ».
Le serveur 9 reçoit la chaîne de caractères et effectue un traitement à l'aide du module 10 et de la pluralité de bases 11, pour fournir en sortie un ensemble de paramètres de modélisation indiquant des éléments de 25 modélisation.
Le serveur 9 envoie les paramètres de modélisation au terminal utilisateur 1.
Le terminal utilisateur 1 réceptionne ces paramètres de modélisation qui indiquent des éléments de modélisation, extrait de la base de référence 7
3.0 les— éléments— indiqués,— puis— construit— à— partir~desdits"-paτamètres~~dë" modélisation et desdits éléments, le modèle correspondant au mot « PETIT ». Dans un premier mode de réalisation, Ia base de référence 7 comporte un modèle de reconnaissance pour chaque phonème, par exemple un modèle de Markov.
Le module 10 de détermination de paramètres de modélisation du serveur 9 est adapté pour déterminer un graphe phonétique correspondant à la chaîne de caractères reçue. A l'aide de la pluralité de bases 11 , il détermine ainsi à partir de la chaîne de caractères reçue, les différentes prononciations possibles du mot. Puis il représente chacune de ces prononciations sous la forme d'une succession de phonèmes. Ainsi, à partir de la chaîne de caractères « Petit » reçue, le module 10 du serveur détermine les deux prononciations suivantes : p.e.t.i. ou p.t .i, selon que le e muet est prononcé ou pas. Ces variantes correspondent à des successions respectives de phonèmes, représentées conjointement sous la forme p . ( e I ( ) ) . t . i ou encore par le graphe phonétique représenté en figure 2.
Le serveur 9 renvoie ensuite au terminal utilisateur 1 un ensemble de paramètres de modélisation décrivant ces variantes. L'échange est par exemple le suivant : Terminal -> Serveur : « Petit » Serveur -> Terminal : p . (e I () ) . t . i .
Lorsque le terminal utilisateur reçoit ces paramètres de modélisation décrivant des séquences de phonèmes, il construit le modèle du mot « PETIT » à partir du graphe phonétique, et des modèles de Markov stockés dans la base d'éléments de modélisation pour chacun des phonèmes /p/, /e/, /t/, /i/. Puis il stocke le modèle de Markov ainsi construit pour le nom de contact « PETIT » dans le lexique 5.
Ainsi la construction du modèle a été réalisée en exploitant des connaissances figurant dans la pluralité des bases 11 du serveur 9, mais a nécessité la transmission par le serveur, sur la liaison de communication 8, des
~seαïs~pafamèfres décrivant le graphe de modélisation pnonêtique représenté en figure 2, ce qui représente une quantité d'informations bien moindre que celle correspondant à la totalité du modèle du nom « PETIT » stocké dans le lexique 5. Dans un contexte multilingue, la base de référence 7 du terminal utilisateur 1 peut stocker des jeux de modèles de phonèmes pour plusieurs langues. Dans ce cas, le serveur 10 transmet en outre une indication sur le jeu à utiliser. Dans ce cas, l'échange sera par exemple du type :
Terminal -> Serveur : « Petit »
Serveur -> Terminal : p_fr_FR . (e_fr_FR I ()) . t_fr_FR . LfM=R1 où le suffixe _fr_FR désigne des phonèmes du français appris sur des données acoustiques françaises (par opposition à des données canadiennes ou belges, par exemple) .
Par ailleurs, pour de nombreux noms propres, le serveur 9, à l'aide de la pluralité de bases 11, détecte et prend en compte la langue d'origine « supposée » du nom. Il génère ainsi des variantes pertinentes de prononciation pour celui-ci ( cf. « Generating proper name pronunciation variants for automatic récognition », de K. Bartkova ; Proceedings ICPhS'2003, 15th International Congress of Phonetic Sciences, Barcelone, Espagne, 3-9 août 2003, pp 1321-1324).
Dans un mode de réalisation, pour accroître les performances ultérieures de reconnaissance, le module 10 de détermination de paramètres de modélisation du serveur 9 est adapté pour prendre en compte en outre les influences contextuelles, c'est-à-dire ici les1 phonèmes qui précédent et qui suivent le phonème courant, comme représenté sur la figure 3.
Le module 10 dans un mode de réalisation peut alors envoyer des paramètres de modélisation décrivant le graphe phonétique avec prise en compte des contextes. Dans ce mode de réalisation, la base de référence 7 comporte les modèles de Markov des phonèmes prenant en compte les contextes.
Il a été décrit ci-dessus une représentation de chaque prononciation possible sous la forme d'une succession de phonèmes. Toutefois, d'autres niodes_-de_ -mise — en- œuvre— de — l'invention — peuvent" îëpTésëntêf des" prononciations sous la forme d'une succession d'unités phonétiques autres que les phonèmes, par exemple de polyphones (suite de plusieurs phonèmes) ou d'unités sub-phonétiques qui prennent en compte, par exemple, la séparation entre la tenue et l'explosion des plosives. Dans ce cas de mise en œuvre de l'invention, la base 7 comporte des modèles respectifs de telles unités phonétiques.
Le mode de réalisation décrit ci-dessus en référence à la figure 3 est relatif au cas où le serveur prend en compte les contextes. Dans un autre mode de réalisation, c'est le terminal qui prendra en compte les contextes pour la modélisation, sur la base d'une description lexicale (par exemple un graphe lexical standard indiquant simplement les phonèmes) transmise par le serveur, de l'entité à modéliser. Dans un autre mode de mise en œuvre de l'invention, le module 10 du serveur 9 est adapté pour déterminer, à partir des informations envoyées par le terminal relatives àl'entité à modéliser, un graphe de modélisation acoustique.
Un tel graphe de modélisation acoustique déterminé par le module 10 à partir du graphe phonétique obtenu à partir de la chaîne de caractères « Petit » est représenté en figure 4. Ce graphe est le support du modèle de
Markov, qui associe une chaîne de Markov à un ensemble de fonctions de densités de probabilité D.
Les cercles, numérotés 1 à 14, représentent les états de la chaînes de
Markov, et les arcs indiquent les transitions. Les étiquettes D désignent les fonctions de densité de probabilité, qui modélisent les formes spectrales que l'on observe sur un signal et qui résultent d'une analyse acoustique. La chaîne de Markov contraint l'ordre temporel dans lequel on doit observer ces formes spectrales. On considère ici que les densités de probabilités sont associées aux états de la chaîne de Markov (dans un autre mode de réalisation, les densités sont associées aux transitions).
La partie haute du graphe correspond à la variante de prononciation p.e.t.i, la partie basse correspond à la variante p .t.i.
Dp1, Dp2, Dp3 désignent trois densités associées au phonème /p/. De même, De1, De2, De3 désignent les trois densités associées au phonème IeI ; Dtl,JDt2, D_t3-désignent- trois-densités assOciées~~au~ phc7rè7τTë"7t/"èTDÏ1 , ' DÏ2,
Di3 désignent les trois densités associées au phonème IM. Le choix de trois états et densités par modèle acoustique de phonème (correspondant respectivement au début, au milieu et à la fin du phonème) est courant, mais non unique. En effet, on peut utiliser plus ou moins d'états et de densités pour chaque modèle de phonème.
Chaque densité est en fait constituée d'une somme pondérée de plusieurs fonctions gaussiennes définies sur l'espace des paramètres acoustiques (espace correspondant aux mesures effectuées sur le signal à reconnaître). Sur la figure 4, quelques fonctions gaussiennes de quelques densités sont schématiquement représentées.
Ainsi pour Dp1 , on a par exemple :
où <arpl fc désigne la pondération de la gaussienne Gpi k (∑<zPik =î)> k pour la densité Dp1 et k varie de 1 à Np1, Np1 désignant le nombre de gaussiennes constituant la densité Dp1 et pouvant être dépendant de la densité considérée.
Dans un mode de réalisation de l'invention, le serveur 9 est adapté pour transmettre à destination du terminal utilisateur 1 des informations du graphe de modélisation acoustique déterminé par le module 10, qui fournissent la liste des transitions successives entre états et indiquent pour chaque état l'identifiant de la densité associée.
Dans un tel mode de réalisation, l'échange est par exemple du type : Terminal -> Serveur : « Petit »
Serveur -> Terminal : <Transitions-Graphe>
1 1 ; 1 2 ;
2 2 ; 2 3 ; 2 4 ; 3 3 3 3 ;; 3 3 5 5 ;;
4 4 > 4 9 ;
5 5 ; 5 6 ;
6 6 ; 6 7 ;
7 7 ; 7 8 ;
8 8 ; 8 10 ;
9 9 ; 9 10 ;
10 10 ; 10 11 ; 11 11 ; 11 12 ;
12 12 ; 12 13 ;
13 13 ; 13 14 ;
14 14 ;
</Transitions-Graphe>
<Etats-Densités>
1 Dp1 ; 2 Dp2.; 3 Dp3 ;
4 Dp4 ;
5 De1 ; 6 De2 ; 7 De3 ;
10 8 Dt1 ; 10 Dt2 ; 11 Dt3 ;
9 Dt4 ;
12 Di1 : 13 Di2 : 14 Di3 :
</Etats-Densités>
Le premier bloc d'informations, transmis entre les balises <Transitions- 15 Graphe> et </Transitions-Graphe> décrit ainsi l'ensemble des 28 transitions du graphe acoustique, avec chaque état de départ et chaque état d'arrivée. Le second bloc d'informations, transmis entre les balises <Etats-Densités> et
</Etats-Densités> décrit l'association des densités aux états du graphe, en précisant les couples état/identifiant de densité associé. 20 Dans un tel mode de réalisation de l'invention, la base de référence 7 dispose des paramètres des densités de probabilité associées aux identifiants reçus. Ces paramètres sont des paramètres de description et/ou de précision des densités.
Par exemple, à partir de l'identifiant de densité Dp1 reçu, elle fournit la 25 somme pondérée décrivant la densité, ainsi que la valeur des coefficients de pondération et les paramètres des gaussiennes intervenant dans la sommation.
Lorsque le terminal utilisateur 1 reçoit les paramètres de modélisation décrits ci-dessus, il extrait de la base 7 les paramètres des densités de 30. probabilité associés- aux-identifiants indiqués dans"le~bloc^Eîàts-OeήsiFés>, et construit le modèle du mot « PETIT » à partir de ces paramètres de densités et des paramètres de modélisation. Puis il stocke le modèle ainsi construit pour le nom de contact « PETIT » dans le lexique 5.
Dans un autre mode de réalisation, le serveur 9 est adapté pour transmettre à destination du terminal utilisateur 1 des informations du graphe de modélisation acoustique déterminé par le module 10, qui fournissent, en plus de la liste des transitions successives entre états et de l'identifiant de la densité associée pour chaque état comme précédemment, la définition de densités en fonction des fonctions gaussiennes.
Dans ce cas, le serveur 9 envoie à destination du terminal utilisateur 1 , en plus des deux blocs d'informations décrits précédemment, un bloc d'informations complémentaires transmis entre les balises <Densités-
Gaussiennes> et</ Densités-Gaussiennes>, qui décrit pour des densité de probabilité, les gaussiennes et les coefficients de pondération associés, en précisant les couples valeurs des coefficients de pondérations/identifiant de gaussienne associé, du type, lorsque toutes les densités Dp1, Dp2,..., Di3 du graphe sont à décrire :
<Densités-Gaussiennes>
Dp1 apU GpX X apUNpl GpX NpX
D'3 OC13 x G(3 1 ai3,Ntt "/3,Λ73
</ Densités-Gaussiennes>. Dans un tel mode de réalisation de l'invention, la base de référence 7 dispose des paramètres de description des gaussiennes associées aux identifiants reçus.
Lorsque le terminal utilisateur reçoit les paramètres de modélisation décrits ci-dessus, il construit le modèle du mot « PETIT » à partir de ces paj;ajiτèjres_et^pj^r_çjτaiiue_5aussienne--indiquée--dans- le-bloe-<-Densités-
Gaussiennes>, à partir des paramètres stockés dans la base de référence 7.
Puis il stocke le modèle ainsi construit pour le nom de contact « PETIT » dans le lexique 5. Certains modes de réalisation de l'invention peuvent combiner certains des aspects de réalisation décrits ci-dessus. Par exemple, dans un mode de réalisation, le serveur connaît l'état de la base de référence 7 du terminal 1 et sait ainsi déterminer ce qui est stocké ou non dans la base 7. Il est adapté pour fournir uniquement la description du graphe phonétique lorsqu'il détermine que les modèles des phonèmes présents dans le graphe phonétique sont stockés dans la base 7. Pour les phonèmes dont les modèles ne sont pas non décrits dans la base 7, il détermine le graphe de modélisation acoustique. Il fournit au terminal utilisateur 1 les informations des blocs <Transitions-Graphe> et <Etats-Densités> relatives aux densités qu'il détermine comme connues de la base 7. Il fournit en outre les informations du bloc <Densités-Gaussiennes> relatives aux densité non définies dans la base 7 du terminal utilisateur.
Dans un autre mode de réalisation, le serveur 9 ne connaît pas le contenu de la base de référence 7 du terminal utilisateur 1 , et ce dernier est adapté, au cas où il reçoit des informations du serveur 9 comprenant un identifiant d'un élément de modélisation (par exemple une densité de probabilité ou une gaussienne) tel que la base de référence 7 ne comporte pas les paramètres de l'élément de modélisation ainsi identifié, pour émettre une requête à destination du serveur 9 pour obtenir ces paramètres manquants afin de déterminer l'élément de modélisation et d'enrichir la base de référence.
Dans le cas de reconnaissance multilingue, la base de référence 7 du terminal utilisateur comportant des unités de modélisation pour une langue particulière, le serveur 9 peut rechercher parmi les unités de modélisation qu'il sait être disponibles dans la base de référence 7, lesquelles "ressemblent" le plus à celles requises par un nouveau modèle à construire correspondant à une langue différente. Dans ce cas, il peut adapter les paramètres de modélisation à transmettre au terminal utilisateur 1 pour décrire au maximum le modèle ou un élément de modélisation absent de la base 7 et requis par le terminal utilisateur, en fonction des éléments de modélisation stockés dans la complémentaires à~ transférer et à stocker dans le terminal.
L'exemple décrit ci-dessus correspond à la fourniture par le terminal utilisateur de l'entité à modéliser sous forme textuelle, par exemple via le clavier. D'autres modes de saisie ou de récupération de l'entité à modéliser peuvent être mises en oeuvre selon l'invention. Par exemple, dans un autre mode de réalisation de l'invention, l'entité à modéliser est récupérée par le terminal utilisateur 1 à partir d'un identifiant d'appel reçu (affichage 5 nom/numéro). Dans un autre mode de réalisation de l'invention, l'entité à modéliser est capturée par le terminal utilisateur 1 à partir d'un ou de plusieurs exemples de prononciation du nom de contact par l'utilisateur. Le terminal utilisateur 1 transmet alors à destination du serveur 9 ces exemples de l'entité à modéliser (soit directement sous forme acoustique, soit après une analyse 0 déterminant des paramètres acoustiques, par exemple des coefficients cepstraux).
Le serveur 9 est alors adapté pour, à partir des données reçues, déterminer un graphe phonétique et/ou un graphe de modélisation acoustique (directement depuis les données par exemple dans une approche de type 5 monolocuteur ou après la détermination du graphe phonétique), et envoyer les paramètres de modélisation au terminal utilisateur 1. Comme détaillé plus haut dans le cas d'une capture textuelle de l'entité à modéliser, le terminal utilise ces paramètres de modélisation (qui notamment indiquent des éléments de modélisation décrits dans la base 7) et les éléments de modélisations ainsi 0 indiqués et disponibles dans la base 7, pour construire le modèle
Dans un autre mode de réalisation de l'invention, le terminal utilisateur 1 est adapté pour optimiser le lexique 5 des modèles construits, en factorisant les redondances éventuelles. Cette opération consiste à déterminer les parties communes à plusieurs modèles mémorisés dans le lexique 5 (par exemple les 5 débuts ou fins de mot identiques). Elle permet d'éviter de dupliquer inutilement des calculs au cours de la phase de décodage et ainsi d'économiser de la ressource de calcul. La factorisation des modèles peut concerner des mots, des phrases complètes ou encore des portions de phrases.
Dans un autre mode de réalisation, l'étape de factorisation est CL - .effectuée. parJe-serveur,~par- exemple-à- partir-d-une liste de-mots~envoyée"par" le terminal, ou encore à partir d'un nouveau mot à modéliser envoyé par le terminal et d'une liste de mots mémorisée au niveau du serveur et connue par le serveur comme répertoriant des mots dont les modèles sont stockés dans le terminal.
Puis le serveur envoie, en complément des paramètres de ^ modélisation indiquant les éléments de modélisation, des informations relatives aux facteurs communs ainsi déterminés.
Dans un autre mode de réalisation, le terminal utilisateur 1 est adapté pour envoyer à destination du serveur 9, en plus de l'entité à modéliser, des informations additionnelles, par exemple l'indication de la langue utilisée, afin que le serveur effectue une analyse phonétique en conséquence, et/ou les caractéristiques des unités phonétiques à fournir ou des modèles acoustiques qui doivent être utilisés, ou encore l'indication de l'accent ou de tout autre caractérisation du locuteur permettant une génération de variantes de prononciation ou de modélisation adaptées à ce locuteur (à noter que cette information peut être stockée sur le serveur, si celui-ci peut identifier automatiquement le terminal appelant) etc.
La solution selon l'invention s'applique à toutes sortes d'applications de reconnaissance embarquée, l'application de répertoire vocale indiquée ci- dessus n'étant mentionnée qu'à titre d'exemple.
Par ailleurs, le lexique 5 décrit ci-dessus comporte des noms de contact reconnaissables ; il peut cependant comporter des noms communs et/ou encore des phrases reconnaissables.
Plusieurs approches sont possibles pour la transmission des données entre le terminal utilisateur 1 et le serveur 9. Ces données peuvent être compressées ou non. Les transmissions depuis le serveur peuvent se faire sous la forme d'envoi de blocs de données en réponse à une demande particulière du terminal, ou encore par l'envoi de blocs avec balises similaires à ceux présentés ci-dessus.
Les exemples décrits ci-dessus correspondent à la mise en oeuvre de l'invention au sein d'un terminal utilisateur. Dans un autre mode de réalisation, la coπstruction de modèles-de reGonnaissanee-est distribuéernon~pas~eτitre cm serveur et un terminal utilisateur, mais entre un serveur et une passerelle apte à être reliée à plusieurs terminaux utilisateurs, par exemple une passerelle résidentielle, au sein d'un même domicile (« residential gateway »). Cette configuration permet de mutualiser la construction des modèles. Suivant les modes de réalisation, une fois les modèles construits, la reconnaissance vocale est effectuée soit exclusivement par le terminal utilisateur (les modèles construits lui sont transmis par la passerelle), soit par la passerelle, soit par les deux dans le cas d'une reconnaissance distribuée.
La présente invention permet donc de tirer avantageusement parti de multiples bases de connaissance du serveur (par exemple multilingues) pour la constitution de modèles, bases qui ne peuvent, pour des raisons de capacité mémoire, être installées sur un dispositif de type terminal utilisateur ou passerelle résidentielle, tout en permettant de limiter les quantités d'informations à faire transiter sur la liaison de communication entre le dispositif et le serveur.
L'invention permet également une plus grande facilité de mise en oeuvre des évolutions de détermination de modèles, puisqu'il suffit de réaliser les opérations de maintenance, de mise à jour et d'évolution sur les bases du serveur, et non pas sur chaque dispositif.

Claims

REVENDICATIONS
1. Procédé de construction d'un modèle de reconnaissance vocale d'une entité à modéliser, distribuée entre un dispositif (1) comportant une base
(5) de modèles construits et une base de référence (7) stockant des éléments de modélisation, ledit dispositif étant apte à communiquer avec un serveur (9) par l'intermédiaire d'une liaison de communication (8), ledit procédé comportant au moins les étapes suivantes : - le dispositif obtient l'entité à modéliser ;
- le dispositif transmet sur la liaison de communication à destination du serveur des données représentatives de ladite entité ;
- le serveur reçoit lesdites données à modéliser et effectue un traitement pour déterminer à partir desdites données, un ensemble de paramètres de modélisation indiquant des éléments de modélisation ;
- le serveur transmet sur la liaison de communication à destination du dispositif lesdits paramètres de modélisation ;
- le dispositif reçoit les paramètres de modélisation et détermine le modèle de reconnaissance vocale de l'entité à modéliser en fonction d'au moins les paramètres de modélisation et d'au moins un élément de modélisation stocké dans la base de référence et indiqué dans les paramètres de modélisation reçus ; et
- le dispositif mémorise le modèle de reconnaissance vocale de l'entité à modéliser dans la base de modèles construits.
2. Procédé selon la revendication 1, selon lequel ledit dispositif est un terminal-utilisateur— (4)-à-reeonnaissanee- vocale embarqσéeT'Ië" mϋclëlë" étant destiné à être utilisé par le terminal utilisateur.
3. Procédé selon la revendication 1 ou la revendication 2, selon lequel le traitement effectué par le serveur (9) comprend une étape de détermination d'un ensemble de paramètres de description phonétique de l'entité à modéliser.
4. Procédé selon l'une quelconque des revendications précédentes, selon lequel les paramètres de modélisation transmis au dispositif (1) comprennent au moins un desdits paramètres de description phonétique, un modèle acoustique dudit paramètre de description phonétique étant stocké dans la base de référence (7) du dispositif.
5. Procédé selon l'une quelconque des revendications précédentes, selon lequel le traitement effectué par le serveur (9) comprend au moins une étape de modélisation acoustique, selon laquelle le serveur détermine un modèle de Markov comportant un ensemble de paramètres de description acoustique associés à l'entité à modéliser.
6. Procédé selon la revendication 5, selon lequel les paramètres de modélisation transmis au dispositif , (1) comprennent au moins un identifiant de densité de probabilité acoustique, la description de ladite densité identifiée, comprenant une somme pondérée de fonctions gaussiennes, étant stockée dans la base de référence (7) dispositif.
7. Procédé selon la revendication 5 ou la revendication 6, selon lequel les paramètres de modélisation transmis au dispositif (1) comprennent au moins un coefficient de pondération associé à un identifiant de fonction gaussienne, la fonction gaussienne ainsi indiquée étant définie dans la base de référence (7) du dispositif.
8. Procédé selon l'une quelconque des revendications ci-dessus, selon lequel lorsqu'au moins un modèle d'une entité à modéliser a été précédemment mémorisé dans la base de modèles construits (5) du dispositif (1), et après détermination du modèle correspondant à une nouvelle entité à modéliser, le dispositif effectue une étape de factorisation des modèles en analysant ledit modèle précédemment mémorisé et le modèle correspondant à la nouvelle entité, afin d'identifier des caractéristiques communes.
9. Procédé selon l'une quelconque des revendications ci-dessus, selon lequel le serveur effectue en outre une étape de factorisation des modèles d'une liste d'entités comprenant ladite entité à modéliser. en analysant lesdits modèles, afin d'identifier des caractéristiques communes.
10. Procédé selon l'une quelconque des revendications ci-dessus, selon lequel lorsqu'un élément de modélisation indiqué par au moins un paramètre de modélisation reçu ne se trouve pas dans la base de référence (7) du dispositif (1), le dispositif émet une requête à destination du serveur par l'intermédiaire de la liaison de communication
(8), pour déterminer l'élément de modélisation associé et récupérer les paramètres correspondants afin d'enrichir la base de référence.
11. Dispositif (1) apte à communiquer avec un serveur (9) par l'intermédiaire d'une liaison (8) de communication et comprenant :
- une base de modèles construits (5) ; une base de référence (7) stockant des éléments de modélisation ;
- des moyens (3) pour obtenir l'entité à modéliser ;
- des moyens pour transmettre sur la liaison de communication à destination du serveur des données représentatives de ladite entité ; - des moyens pour recevoir des paramètres de modélisation en provenance du serveur, correspondant à ladite entité à modéliser et indiquant des éléments de modélisation ;
- des moyens (6) pour déterminer le modèle de reconnaissance vocale de l'entité à modéliser en fonction d'au moins les paramètres de modélisation reçus et d'au moins un élément de modélisation indiqué dans lesdits paramètres de modélisation et stocké dans la base de référence; et
- des moyens pour mémoriser le modèle de reconnaissance vocale de l'entité à modéliser dans la base (5) de modèles construits. ledit dispositif étant adapté pour mettre en œuvre les étapes d'un procédé selon l'une des revendications 1 à 10 qui incombent audit dispositif, pour constituer le modèle de l'entité à modéliser.
12. Serveur (9) pour effectuer une partie de tâches de fabrication de modèles de reconnaissance vocale destinés à être mémorisés et utilisés par un dispositif (1) à reconnaissance vocale embarquée, le serveur étant apte à communiquer avec le dispositif par l'intermédiaire d'une liaison de communication (8) et comprenant : - des moyens pour recevoir par l'intermédiaire de la liaison de communication des données à modéliser transmises par le dispositif
- des moyens (10) pour effectuer un traitement pour déterminer à partir desdites données, un ensemble de paramètres de modélisation indiquant des éléments de modélisation ;
- des moyens pour transmettre sur la liaison de communication à destination du dispositif lesdits paramètres de modélisation ; ledit serveur étant adapté pour mettre en œuvre les étapes d'un procédé selon l'une des revendications 1 à 10 qui incombent au serveur.
13. Programme d'ordinateur de constitution de modèles de reconnaissance vocale à partir d'une entité à modéliser, exécutable par une unité de traitement d'un dispositif destiné à effectuer de la reconnaissance vocale embarquée, comprenant des instructions pour exécuter les étapes, qui incombent au dispositif, d'un procédé selon l'une des revendications 1 à
10 lors d'une exécution du programme par ladite unité de traitement.
14. Programme d'ordinateur de constitution de modèles de reconnaissance vocale, exécutable par une unité de traitement d'un serveur, comprenant des instructions pour exécuter les étapes, qui incombent au serveur, d'un procédé selon l'une des revendications 1 à 10 lors d'une exécution du programme par ladite unité de traitement.
EP05815123A 2004-11-08 2005-10-27 Procede de construction distribuee d'un modele de reconnaissance vocale , dispositif, serveur et programmes d'ordinateur pour mettre en uvre un tel procede Withdrawn EP1810277A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0411873 2004-11-08
PCT/FR2005/002695 WO2006051180A1 (fr) 2004-11-08 2005-10-27 Procede de construction distribuee d'un modele de reconnaissance vocale , dispositif, serveur et programmes d'ordinateur pour mettre en œuvre un tel procede

Publications (1)

Publication Number Publication Date
EP1810277A1 true EP1810277A1 (fr) 2007-07-25

Family

ID=34950626

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05815123A Withdrawn EP1810277A1 (fr) 2004-11-08 2005-10-27 Procede de construction distribuee d'un modele de reconnaissance vocale , dispositif, serveur et programmes d'ordinateur pour mettre en uvre un tel procede

Country Status (3)

Country Link
US (1) US20080103771A1 (fr)
EP (1) EP1810277A1 (fr)
WO (1) WO2006051180A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070129949A1 (en) * 2005-12-06 2007-06-07 Alberth William P Jr System and method for assisted speech recognition
CN102176310B (zh) 2005-12-08 2013-08-21 纽昂斯奥地利通讯有限公司 具有巨大词汇量的语音识别系统
US9129599B2 (en) * 2007-10-18 2015-09-08 Nuance Communications, Inc. Automated tuning of speech recognition parameters
GB2466242B (en) * 2008-12-15 2013-01-02 Audio Analytic Ltd Sound identification systems
US11087739B1 (en) * 2018-11-13 2021-08-10 Amazon Technologies, Inc. On-device learning in a hybrid speech processing system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864810A (en) * 1995-01-20 1999-01-26 Sri International Method and apparatus for speech recognition adapted to an individual speaker
US5960399A (en) * 1996-12-24 1999-09-28 Gte Internetworking Incorporated Client/server speech processor/recognizer
DE19751123C1 (de) * 1997-11-19 1999-06-17 Deutsche Telekom Ag Vorrichtung und Verfahren zur sprecherunabhängigen Sprachnamenwahl für Telekommunikations-Endeinrichtungen
US6463413B1 (en) 1999-04-20 2002-10-08 Matsushita Electrical Industrial Co., Ltd. Speech recognition training for small hardware devices
DE19918382B4 (de) * 1999-04-22 2004-02-05 Siemens Ag Erstellen eines Referenzmodell-Verzeichnisses für ein sprachgesteuertes Kommunikationsgerät
US6442519B1 (en) * 1999-11-10 2002-08-27 International Business Machines Corp. Speaker model adaptation via network of similar users
US20030182113A1 (en) * 1999-11-22 2003-09-25 Xuedong Huang Distributed speech recognition for mobile communication devices
US6823306B2 (en) * 2000-11-30 2004-11-23 Telesector Resources Group, Inc. Methods and apparatus for generating, updating and distributing speech recognition models
EP1215661A1 (fr) * 2000-12-14 2002-06-19 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Appareil portable à reconnaissance de la parole
FI20010792L (fi) * 2001-04-17 2002-10-18 Nokia Corp Käyttäjäriippumattoman puheentunnistuksen järjestäminen
US20030050783A1 (en) * 2001-09-13 2003-03-13 Shinichi Yoshizawa Terminal device, server device and speech recognition method
CN1453767A (zh) * 2002-04-26 2003-11-05 日本先锋公司 语音识别装置以及语音识别方法
US7386443B1 (en) * 2004-01-09 2008-06-10 At&T Corp. System and method for mobile automatic speech recognition

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006051180A1 *

Also Published As

Publication number Publication date
WO2006051180A1 (fr) 2006-05-18
US20080103771A1 (en) 2008-05-01

Similar Documents

Publication Publication Date Title
US11664020B2 (en) Speech recognition method and apparatus
JP6434948B2 (ja) 名前発音システム及び方法
EP1362343B1 (fr) Procede, module, dispositif et serveur de reconnaissance vocale
JP4267081B2 (ja) 分散システムにおけるパターン認識登録
JP5062171B2 (ja) 音声認識システム、音声認識方法および音声認識用プログラム
CN107104994B (zh) 语音识别方法、电子装置及语音识别系统
US12367867B2 (en) System for generating voice in an ongoing call session based on artificial intelligent techniques
CN115312040A (zh) 语音唤醒方法、装置、电子设备和计算机可读存储介质
CN115762467A (zh) 说话人表征向量分布空间创建、语音合成方法及相关设备
CN100589180C (zh) 使用切换状态空间模型的多模变分推导的语音识别方法
EP1810277A1 (fr) Procede de construction distribuee d&#39;un modele de reconnaissance vocale , dispositif, serveur et programmes d&#39;ordinateur pour mettre en uvre un tel procede
CA2531496C (fr) Reconnaissance vocale pour les larges vocabulaires dynamiques
Siohan CTC Training of Multi-Phone Acoustic Models for Speech Recognition.
Kos et al. A speech-based distributed architecture platform for an intelligent ambience
WO2005010868A1 (fr) Systeme de reconnaissance vocale, son terminal et son serveur
Jendoubi et al. Belief hidden Markov model for speech recognition
JP5956913B2 (ja) 言語モデル生成装置、言語モデル生成方法、プログラム、記録媒体
EP4443425A1 (fr) Procédés et systèmes de commande vocale
WO2018077987A1 (fr) Procédé de traitement de données audio issues d&#39;un échange vocal, système et programme d&#39;ordinateur correspondant
Sertsi et al. Offline Thai speech recognition framework on mobile device
CN120950661A (zh) 基于多模态与会话状态感知的实时话术决策方法及系统
Pieraccini et al. Data-driven methods in industrial spoken dialog systems
EP1490862A1 (fr) Procede de reconnaissance de la parole
Vasavada et al. Power efficient implementation of MVA-SI on speech controlled IoT systems
Myint Testing Speech to Text Application on Android Platform

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070504

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FRANCE TELECOM

17Q First examination report despatched

Effective date: 20090717

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100626