对于不熟悉homophone是什么的人,我提供以下示例:
在使用iOS随附的Speech API时,我遇到用户可能说出其中一个单词但无法总是返回我想要的单词的情况。
我调查了[alternativeSubstrings]
(link)属性,想知道这样做是否有帮助,但是在测试上述单词时,它总是空着。
我也查看了Natural Language API,但在其中找不到任何有用的内容。
我了解到,随着用户添加更多的单词,Speech API可以开始推断上下文并对此进行纠正,但是我的用例对此效果不佳,因为它通常最多只需要一个或两个单词,因此上下文的有效性。
上下文处理的示例:
单独使用上面的单词,我得到以下结果:
但是,如果我把下面的句子放在一起,你会发现它们都是错误的:
我对我们的阶梯太高了
理想情况下,我要么获得一个包含每个转录段的[are, our], [to, too, two], [hi, high]
的列表,要么可以将字符串与支持同音字的函数进行比较。
例如:
if myDetectedWord == "to" then { ... }
myDetectedWord
可以是[to, too, two]
的地方,此函数将为每个返回true。
答案 0 :(得分:2)
这是一个常见的NLP难题,我不确定在此应用程序中可能需要什么输出。但是,如果可能的话,您可能希望在设计/体系结构过程中绕过此问题。否则,这个问题将变成一个挑战。
话虽这么说,但如果您想真正进入它,我喜欢您的想法:
针对函数的字符串
这可能更高效且性能更友好。
我想解决这个问题的一种方法是通过RegEx处理,而不是使用无限循环和数组。您也许可以从原型循环和数组开始,看看它是如何工作的,然后您可能想使用正则表达式来获得性能。
例如,您可以在正则表达式中定义固定数组,然后快速检查您的字符串(逐字检查,也许使用反向引用),并且可以根据需要在expressions中添加许多边界以进行字符串处理。
还可以基于在字符串的某些部分中出现某些单词的概率来设计您的固定数组。例如,
^I
vs
^eye
I
是第一个单词的可能性远高于eye
。I
的概率也比eye
的概率高。 您可能希望以此为基础对单词进行加权。
我想说的关键是,如果您希望拥有一个好的/可行的应用程序,则可以尽可能地缩小期望的输出范围并提高准确度,甚至可以使用100个单词。
好的项目,希望您喜欢/享受挑战。