按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
这个项目的起因其实就是张宏江的一个问话：“能不能简单哼一下就把一首歌给找出来？”“ 挺好玩。”当时第一个感觉就是这个问题很好玩。仔细一想，其实这也是一个现实的问题。比如说我自己（不少人也是）经常记不清歌名，但还能哼两句主旋律。如果我们真能有一个哼唱搜歌的系统，说不定真可能派上用场。同时，这还是一个独立、完整的系统，设计开发这样一个系统对我也是一个有益的锻炼。于是，我和一个实习生由红开始了这个项目。
我们首先翻阅了资料，发现哼唱搜索其实在1995年的ACM多媒体大会上就由Asif Ghias博士（康奈尔大学）等提出并给出了一个解决方法。以后又有些研究员陆续提出了一些改进方法。但是，我们发现以前的方法还是有不少的局限性。比如，旋律本来是一个音符序列，包括每个音符的音高和时长；但在很多方法中，旋律被简化为只包含反映下一个音符相对于上个音符上升、持平、下降的字符串。有些方法为了加快搜索速度，要求只能哼唱歌曲的起始部分。还有些则为了避免哼唱节奏的影响，要求用户使用一个节拍器。这都限制了这些方法的可应用性。我们觉得里面还有许多方面可以提高。
我们把系统分成了三个部分：数据库处理（从音乐中提取旋律），哼唱处理（从哼唱中提取旋律）和旋律匹配。其中的关键问题是旋律表征、旋律提取、和旋律匹配算法。鉴于以前对旋律表征过于简化，除了以前使用的上升下降等量化数据，我们还保持了旋律中每个音符的音高和时长作为更精确的表征。在旋律匹配过程中，我们采用了两步法以加快搜索速度：先用简化旋律作一初选，然后再用音高和时长，通过音高匹配模型和节奏匹配模型，来更精确地寻找相似的音乐。
歌曲大搜索之哼哼也可以 芦烈（2）
经过半年时间的努力，我们终于完成了算法，建立了一个演示系统。算法在测试集上的性能也挺不错：在搜索结果中，前五位内能找到正确歌曲的比率（hit rate）达到了80％。然而，虽然算法取得了不错的结果，回想起来，还是有不少地方可以提高。比如我们所用的开发集及测试集都比较小，这样可能并不能完全反映算法的性能。我们还发现我们在分析哼唱数据将其转化为旋律时，使用了不少启发式规则，一些参数的设置过于局限于开发集而失去了通用性，使得这个系统对某些人工作很好，但对另一些人却不好。而且，要成为一个真正能为大众使用的产品，我们还缺少一个关键触发点：一个好的应用场景。对于最重要的一个应用场景——网络音乐的搜索，哼唱搜索还无法胜任。这是因为目前的算法对 mp3等音频数据还无法有效处理来提取旋律，我们使用的数据库主要基于MIDI 数据。但是不管怎样，这是一个完全从零开始的项目，我在整个过程中，从查阅资料、设计模块、设计算法，到编写代码、数据收集、算法评价及相应改进，都得到了不少的锻炼，对研究方法也更有心得了。
由于其他项目的开展，哼唱搜索暂时告一段落。我想，其实它也是在等待一个更好的机会。
忽现转机
几年后（2006夏）的某一天，搜索技术中心（STC）的开发项目主管谢育涛突然跟我联系，说他正好看到张贴在研究院中有关哼唱搜索的海报，要跟我讨论一下将其用在手机搜索上的可行性。谢育涛主要负责的是手机搜索，那时他正在跟位于深圳的Windows Live Mobile China （WLMC） 做图铃搜索，也就是提供高效算法来搜索手机图片和手机铃声。除了传统的文本搜索之外，他们还在寻求一些与其他搜索产品不同的新功能。哼唱搜索可能是一个好的选择。
为了寻求哼唱搜索手机铃声的可行性，我们同相关的同事进行了多次讨论。最后，我们觉得哼唱搜索和手机铃声下载将是一个完美的结合：
首先，手机铃声的下载是一个相当大的市场。有资料显示2005年全球手机铃声业务达到令人惊讶的50亿美元。
第二，手机作为一个便携式手提设备，用键盘输入文本并不太方便。但是，声音对手机来说却是一个非常自然的输入方式，因为手机本身便是用来做声音交流的。哼唱是声音的一种。
第三，手机铃声通常有多个版本以便用于不同的手机型号，而MIDI版本的手机铃声是最基本的。这样，只要将MIDI同其他格式关联起来，旋律提取便不再是个问题。
第四，通过手机下载手机铃声是个一步式的解决方案。不再需要通过电脑等中介系统。
同时，我们也发现在这个应用场景下，直接使用我们以前的方法效果并不理想。新的问题带来了新的挑战：
第一，在以前系统中，哼唱是通过麦克风录制的，质量比较好。在现在的应用场景下，我们需要用手机录制。同时，我们必须还要考虑到录制时引入的背景噪声（用户可能在大街上使用这个系统），还有由于无线传输而可能引起的信号畸变。
第二，我们将要面对一个大的多的数据库（通常手机铃声库可能包含1…10万首铃声）。这就要求我们更进一步的提高搜索精度和速度。利用一切可以使用的信息，优化旋律模型和节奏模型。同时需要建立一个更大的开发集和测试集，来优化参数选择和性能评价。
当时，由于媒体计算组的重组，我加入了语音组继续从事音频分析和检索的工作。语音组研究项目负责人Frank Seide和语音组带头人宋謌平博士也非常支持这个项目。于是我们就立即开始了分工合作，来搭建一个端到端（end…to…end）的系统原型。其中，我和一个实习生翁锐浩主要负责哼唱搜索算法的改进，其他几位同事，包括STC的欧佳凡和WLMC的王晓兵，负责搭建搜索平台。
重拾哼唱搜索
晓兵和佳凡的工作卓有成效，他们同###的高阳公司合作，很快就搭建了一个系统平台，并申请了一个临时声讯服务号码（当时是125905988）。通过这个平台，我们就可以有效地采集真实数据。用户可以通过手机直接拨打服务号码，系统会记录下每一条哼唱记录。我记得当时我们有一部手机专门用来做数据采集。我们邀请了很多同事和实习生，把手机交给他们，让他们留下自己“美妙”的哼哼声。对于哼唱环境、哼唱方式、哼唱歌曲，我们都没有加以限制，以期得到符合用户习惯的最真实的数据。通过这个系统，我们得到了大量的数据。
有了真实的数据，我们就着手算法的改进了。算法的改进主要在两方面：一是哼唱的旋律提取，我们考虑了不同的背景噪声和信号畸变，提出了更精确的方法来检测和分割每一个音符；二是匹配模型的改进，我们使用了隐马尔科夫模型 来作旋律匹配，明确考虑了哼唱和数据库音乐之间的音符对齐问题，将它更有效地集成到了改进的旋律模型、节奏模型和匹配时的容错模型中。我们还提出了一个更加系统化的匹配过程。
经过几个月的努力，我们终于开发出了一个更高性能的算法。测试显示，第一位歌曲的正确率 （top 1 accuracy） 达到了82％，在前五位中找到的比率更是接近90％。我们也搭建了一个在线服务原型：你可以使用你的手机，拨打一个服务号码，根据提示音哼唱一段旋律，你就能得到你要找的手机铃声。这也是业界第一个哼唱搜索手机铃声的系统。为了能在中国市场运作，我们还将此技术转让给了位于上海的美斯恩有限公司。
我们还把这个技术展示在微软一年一度的技术节上（TechFest）上； 得到了非常不错的反响。比尔·盖茨也过来看了我们的演示。我也第一次获得了与比尔·盖茨面对面的机会。后来有在微软总部雷德蒙工作的同事对我说：“你的演示很成功啊，很多同事回来后还在讨论呢。”
结束语
哼唱搜索，只是我所经历的众多项目中的一个。之所以讲讲它的故事，不仅是因为它是我第一个独立项目，而且它也让我懂得，做一个项目，不只是仅仅做一个实验室算法，而是要系统地综合地考虑其应用场景甚至商业模型，考虑真实使用环境并使用大数量多样化的真实数据。做到这一点，才有可能使你的技术应用于现实生活中，才有机会让用户感受到科技改变生活。
我想，无论工业界的研究员，还是高等院校里的学生，都可以从这个角度去重新审视一下手中的问题和解决方案。
作者介绍：
芦烈，2000年加入微软亚洲研究院，现为语音组研究员。主要研究方向是机器学习，音频、音乐的内容分析和检索。他在国际一流期刊和会议上发表过50多篇论文，拥有近20项专利；曾多次在国际会议上担任技术委员会成员。他于2000年获上海交通大学电路与系统专业硕士学位，现兼于荷兰代尔夫特理工大学攻读博士学位。他寥有所好，溺于技术而疏于艺术。好音乐而做音乐分析，却常因没有音乐细胞而心有戚戚。 希望有朝一日自己的研究成果可被广泛应用。
研究院“&”的故事 陈刚（1）
创新工程组（Innovation Engineering Group，简称IEG）是研究院中一个非常特殊的非研究性质的组，它负责很多研究组的研究原型和技术转移工作。许多研究院技术背后都有这个组的贡献。由于IEG支持的研究组很多，开玩笑说，就 “研究方向”的数量而言，她可以稳坐研究院第一。
出乎一般人意料的是，这个主要由软件开发工程师而非研究员组成的开发组竟然是研究院成立的第一个组，现在也是10岁了。令人骄傲的是，2003年，从它分化出一支并壮大成立了微软亚洲工程院（ATC）。2005年，搜索技术中心（STC） 的成立也是从这个组开始的。再后来，开发组合并用户体验 （User Experience） 后形成了现在的创新工程组（IEG）。我们组现有二十多人，有老有少，有中国人也有外国人，而且终于有了女性开发工程师，作为一个微软内部的软件开发团队，这确实比较少见。和初创时期纯粹年轻男生的组织构成相比，现在更“平衡”了。
自从2000年进入微软亚洲研究院做开发，不经意间我已在这个组工作了8年，猛然发现自己竟成了组龄最长的组员。作为一个仍很年轻的“老人”，我很乐意把一些经历在研究院10年之际与大家分享。
进入微软研究院
至今我还记得进入微软时两次决定的面试片段。1999年末我面临毕业求职，一日接到微软中国研究院到知春路希格玛的面试通知。西装穿戴整齐到了希格玛五层，我就径直被带到一个屋子里面被很多人围着问话，而这些人没有一个穿西装的，倒是有穿拖鞋的。问问题的人单刀直入、毫不含糊，印象中只记得往来之间人影恍惚、镜光耀眼（研究员们的戴眼镜的比例可不是一般的高）。我战战兢地演示着程序，一边祈祷千万别出岔子。刚刚提心吊胆介绍完，我听见背后“咚”的一声，转头看到一人倚墙坐倒，我心里一惊，那个人却开始打起了很响的呼噜。其余人等毫不惊讶，继续和我聊。通过面试后，我作为实习生帮视觉计算组（VC； Visual puting）的论文做演示程序，加入了他们的第一场SIGGRAPH战斗。而那位坐倒睡过去的研究员就是徐迎庆博士，他的项目正是我进入微软的第一个任务。
SIGGRAPH 战斗告一段落后，到了2000年初我必须决定工作去向。正好研究院在大批招人，再次经过开发组5轮面试官轮番轰炸，没有遇到传说中方井盖圆井盖的问题就到了关底。Harry （沈向洋，当时他是视觉计算组负责人）面试了我。记得有两段话对我的未来影响巨大。Harry说：“想想在什么地方你做一件事可以影响全世界，让全世界的人都用你做的东西？在微软你可以有这样的影响力”。这个诱惑至今对我有吸引力。Harry接着问“你可以选择，做研究还是做开发”。得知做开发可以选择不同的项目和研究组的时候，我更愿意在多个项目间穿梭，更喜欢面对代码而不是论文。于是成为了当时微软中国研究院的开发组的一员，我的职位名称是RSDE（Research Software Development Engineer），当时组里有不到10个人。
我们是RSDE； R&D中的&
外企风格之一就是众多用让人听起来摸不着头脑的缩写，请让我来解释一下我们的职衔。微软程序员的职衔是SDE，即软件开发工程师 （Software Design Engineer或者Software Development Engineer） 。创新工程组的大多数组员的职衔是RSDE （Research Software Development Engineer） 即隶属研究部门的软件开发工程师 。这个多出来“R”意味着我们的任务一部分需要做SDE的事情，写代码编程序，另一部分是和研究员们并肩工作，把概念和想法实现为原型系统和算法，并进一步帮助把研究成果转化为高质量的微软产品代码，这就是所谓的技术转移（Tech Transfer）。技术转移是我们组的主要任务之一，所以 TTG （Tech Transfer Group） 即“技术转化组”是我们使用时间最长的组名之一，即使目前仍然是是创新工程组的主要部分。
还有一个有趣的说法描述我们的工作：研发工作一般叫做R&D，“研”指的是研究部门（R； Research），“发”指的是产品开发部门（D； Development），而RSDE的位置就恰恰在那个“&”中，是连接研究和开发的纽带。。 最好的txt下载网
研究院“&”的故事 陈刚（2）
技术转移
每年都有不少研究技术从亚洲研究院的实验室进入到微软产品中，变成产品的某个功能（feature）。作为研究院的一员，我很骄傲的是，Windows XP、 Vista、 Office、Tablet PC （平板电脑）、Xbox、Windows Live、游戏、硬件等等微软产品中都有来自于北京海淀区知春路城铁边上的这个实验室的技术。其中研究员们的智慧是关键，其中创新工程组的RSDE们也是这些技术产品化的幕后英雄。很多年以前，人们把中关村叫成硅谷的时候，我眼中只是好多买电脑零配件的摊位，而现在的中关村才真正地有了一个IT技术的聚集地的模样。
技术转移是一个需要时间的过程，不是像同城速递那么快捷一个下午就到达目的地。很多大学的孵化中心就是一种类型的技术转移过程。这里说说微软研究院中一个典型的软件技术转移的过程：
1。 研究组选研究题目。这个题目可能是领域内长久的研究方向，希望可以得到某些突破，或者是来自与已有产品的问题。
2。 研究员深入分析问题，设计算法，构造原型系统，收集数据，选择算法，评估结果，不断迭代尝试。
3。 当原型系统显示有能力解决问题的时候，我们开始与相关产品部门接洽技术转移。研究部门有专人负责与产品组的信息沟通。同时我们也可以得到产品组对我们结果的反馈意见。
4。 当原型算法的质量到达相当不错的阶段，产品组看过后便有了更有明确的需求。RSDE开始和研究员成立一个临时的虚拟小组（virtual team，有别于平时的管理组）一起工作，进一步提升原型系统的设计和质量以达到产品组的要求，研究员、产品组的项目经理、开发工程师、测试工程师一起工作，最终把算法代码实现写入到产品组的代码中去。
5。 最终产品发布。到了这个时候，参与项目的人会得到一个石头或金属嵌玻璃的奖牌（Ship…it Award），上面写着“感谢xxx对xxxx产品做出的贡献——比尔·盖茨”。
这是一个相当明确的流程，而现实常常出乎意料，任何一步都不是那么简单，而是变数丛生、繁复无比。产品部门的要求来自与市场，通常期望值很高，可这时往往暴露了研究阶段成果的一个问题，那就是——研究成果和产品要求的差距。
不是所有的研究项目都会成功产品化，为了提高研究的效率，通常当一个算法解决了问题的主要方面就可以开始向产品部门推销了。当“买方”对算法结果基本认可并有意向集成之前，会提一系列的具体要求，希望算法可以达到产品标准。很典型的要求比如是否能够能否达到99％以上的正确率，融入产品已有架构的容易程度，算法复杂度、实现的速度、数据适应性、资源内存消耗、安全性、可靠性、等等。我们在这些方面有过不少坎坷。
例如我们做人脸卡通，第一步在是用户输入正面肖像照输入后自动的配准面部五官，然后再继续后续步骤。最初的的算法在亚洲人的照片上可以工作得很好，可是产品组要求算法必须在世界其他国家市场上要正常工作。这就带来了新的要求，必须考虑世界上其他人种的肤色、发色、眼睛鼻子大小。新的要求导致了数据和算法上的很大改动。
当一项技术是“基本可用的”，假设它已经达到80％的产品要求，而产品的真正要求是“非常好用”，可能意味着90…99％，产品组的众多要求累积在一起，这之间将近20％的距离往往就是发生量变到质变的那一段。这常常意味着算法要做相当的调整和适应，甚至结构需要大修改。RSDE的典型技术转移工作就在这20％的一段。这个象“&”一样拧吧的阶段，我们要和研究员开会，学习他们的东西，出差去总部和产品组面谈，或者每天大早起床赶时间与总部开跨16个小时时区的电话会议，与产品的开发测试工程师一起工作，共同努力让一项研究技术完美地实现用户需求。
研究是高风险的事情，能够变成真正产品的研究只是成功的极少数。很多项目就在这个阶段前不幸夭折了。长江后浪推前浪，死在沙滩上的前浪研究项目的数量相当可观。这个艰苦的过程，难的不光是技术，还有在长长的辛苦、烧掉无数脑细胞之后却要接受项目无果而终的现实。txt电子书分享平台
研究院“&”的故事 陈刚（3）
所以每当有一个技术转移项目顺利完成时我们都很兴奋。当我们收到一份产品组高级经理的感谢信，还有看到好久不见的同事从总部出差回来挺着腰围暴涨了一圈的肚子时，就会上前恭喜他，然后和他一起抱怨总部的中餐馆的菜真油，公司楼下的食堂Pizz