竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier

商务智能的发展-未来的研究方向

一、 商务智能（BI），商业智慧（BI）的发展方向：

BI新走向之一：融合加强，演变成门户化

BI新走向之二：日趋“傻瓜”，体现人性化

BI新走向之三：移动BI将成为新战场

BI新走向之四：在云中部署BI，成为主流方向

BI新走向之五：SaaSBI日渐雄起，受中小企业青睐

BI新走向之六：可视化技术呈亮点，交互式分析助推BI

BI新走向之七：外部信息将整合到内部BI中，内外网信息并联互动

二、  智能的搜索引擎研究方向：

查询聚类（Query clustering）

查询意图识别（Query intent recognition）

查询推荐（Query suggestion）

查询改写（Query rewriting），具体包括：

查询同义变换（Query paraphrasing）

查询扩展（Query expansion）

查询缩略（Query reduction）

查询纠错（Query error correction）

学习排序（Learning to rank）

个性化搜索（Personalized search）

命名实体挖掘（Named entity mining）

本体知识库构建（Ontology construction）

 

三、   商务智能（BI），人工智能（AI）的研究方向：

1. 基于大规模机器学习的排序算法(Machine Learning to Rank)

排序算法是搜索技术的核心之一，基于机器学习排序算法将机器学习技术应用于排序问题。研究内容包括但不限于：

排序算法的分布式训练

排序算法的在线学习(online learning)

排序算法的在线预测速度提升

多目标优化的排序算法

2. 海量特征设计(large scale feature engineering)

特征设计在机器学习系统中扮演着至关重要的作用。但当面临海量数据时，往往特征数量也会是海量的，这时如何做好特征选择、特征组合等工作，与小规模时相比会复杂很多。研究内容包括但不限于：

海量特征自动选择

海量特征自动组合

3. 高效训练样本获取(Label Complexity Reduction)

机器学习算法要求大量的高质量的标注样本，然而标注样本耗时耗力，并且在样本到达一定量 后，对样本量的需求增幅远大于训练效果提升，如何高效地获取良好样本是一个挑战。海量互联网数据下的LTR的样本获取、多语言学习任务背景下标注样本的获 取、网页/网站/query等的分类或聚类所需样本等是高效样本获取方法的应用场景。本方向的问题包括但不限于：

通过主动学习(Active learning)加速标注流程

通过迁移学习/多任务学习(Transfer learning/multi-task learning) 利用其他领域的知识和标注样本来提升另一领域的学习效果

通过半监督学习(Semi-supervised learning)，考虑如何利用少量的标注样本和大量的未标注样本进行分类和聚类，相关问题有半监督学习的算法改进、半监督学习的在线学习 (Online-learning)或者增量学习(incremental-learning)算法等

4. 规则系统与机器学习系统的整合 (Integration of rule-based system and learning-based system)

规则系统和学习系统一直是人工智能实现方法的两个分支，二者各有优劣。规则系统更擅长高频和训练数据稀疏部分，而学习系统的泛化能力更出色。如何结合两者的优势，规避各自的缺点，是我们希望探讨的地方。研究内容只要与两个系统的整合相关即可。

5.海量数据的主题模型(Topic-model on large scale data)

主题模型主要使用大规模的文档—词汇共现(co-occurrence) 矩阵，例如1亿*100万的矩阵来建模文档和词汇间的潜在联系。研究内容包括但不限于：

主题模型的建模改进

主题模型的在线学习(Online learning)或者增量学习(incremental learning)

主题模型训练过程的大规模并行优化

主题模型的应用

6.推荐系统(recommender system)

推荐系统有着广泛的应用，如搜索引擎和电子商务网站以各种方式使用着推荐系统。在百度的 应用即包括在搜索、知道、音乐、贴吧等用户产品内及产品间的推荐，也包括面向搜索请求推荐广告、面向广告商推荐关键词等。不同应用场景的应用目标和数据量 存在较大差异，对于推荐算法本身也存在不同要求。在本领域的研究包括但不限于：

推荐系统的设计

推荐算法的改进

推荐效果的评估

个性化推荐

7. 点击模型(Click Model)

百度拥有中国搜索引擎市场上最丰富的用户数据，点击模型将极大提升用户对搜索的需求满意度。研究内容包括但不限于：

用户行为数据清洗

用户行为分析和建模

用户行为用于评测

8.网页多分类学习

互联网中网页资源可以按照不同的维度划分成不同的类型，而且一个网页可能兼有多个维度的类型标记。该方向的主要目标就是：如何自动高效地为网页进行分类标记。研究内容包括但不限于：

网页分类的机器学习模型研究：二分类/多分类/多标记学习/无监督学习等

主题/资源/结构分类特征挖掘

模型的跨语言通用性研究

9.基于海量网页的结构化信息自动抽取研究

WEB结构化信息抽取就是将网页中的非结构化数据按照一定的需求抽取转换成结构化数据。研究内容包括但不限于：

结构化信息自动抽取方法改进

抽取规则生成表示优化

10.观点挖掘、情感分析(opinion mining and sentiment analysis)

观点挖掘、情感分析主要是对带有情感色彩的主观性文本进行分析、处理、归纳和推理的过程。研究内容包括但不限于：

情感分析的算法改进

情感分析在大规模数据(博客、微博、新闻评论、商品评论)中的应用

情感分析在推荐中的应用

11. 基于机器学习的反作弊研究(fraud detection based on machine learning)

基于机器学习的反作弊研究内容包括但不限于：

自动训练数据标注

作弊特征分析

在线实时作弊检测

离线批量数据评估

业务分析师在敏捷项目中的作用

敏捷软件开发实践的文化中存在着一个断层，该断层同样体现在许多敏捷团队中。这个断层就是业务分析人员在敏捷项目中的角色——谁来担任这个角色？它 的作用 和价值是什么？它又是如何发生改变的？这种情况的潜台词（其实我曾至少听人说过一次）就是：“我们不需要什么见鬼的分析师！”。无需赘言，我当然认为这是 大错特错！在本文中，我证明如下观点：只要以正确的方式向业务看齐，业务分析师就可以帮助敏捷团队成功，而不是像大多数情况那样以开发团队为导向。

为什么要有业务分析师这个角色？

我的观点是：没有业务分析人员，就会发生真的断层。举例来说：

• 谁会注意最大的组织问题？
• 为了高效工作，用户（可怕的词汇——不过这是另外一个话题了）有自己的需求，而管理层（说到底，他们是为开发软件买单的“客户”）的要求可能与之冲突，谁去识别这种潜在的冲突？
• 假如现在有1500人以目前现有的方式工作，如果我们实施了新的软件之后，他们的工作模式会发生很大变化，谁来发现这样的事情？
• 当组织的工作流程因为新软件的实施而发生改变时，有些人要负责设计新的工作流程，以保证业务可以继续顺利运转，那么谁来帮助这些人？
• 与客户交互不当产生的潜在业务损失，谁来发现？
• 我可以继续举例，不过我想你应该有概念了。

在Agile 2008大会上，Alan Cooper做了一个很棒的演讲，他热情洋溢地提到：敏捷项目中需要包含互动设计的工作，要有人能够理解人的行为、而且可以确保相关的产品能够在现实世界中有效工作。

我的观点是：最理想、最有效的做法，是由业务分析师承担这个职责；而且我们应该一直这样做。我们接受培训，部分上也是处于这个目的：理解更广泛的业务需求，并向负责技术的团队以他们可以理解的方式解释这些需求。一直以来，业务分析师一直充当客户需求的守护神。

业务分析师可以帮助团队成功

我 坚信：对业务分析师角色的轻视，是如今众多敏捷团队的严重问题。在很多组织中，由于缺乏组织架构和管理层的支持，分析师的职能被削弱了，他们无法完全体现 自己的价值。业务分析师应被视为客户的代言人，并加入以业务为核心的解决方案提供团队，而不是技术的提供者。在面对问题时，业务分析师能够带来不同的视角 和理解，因此他们应该被授以足够的权力、信任和感谢，他们应向负责业务改进的人员和部门报告自己的工作，而不是去报告给信息技术团队。在这样的组织结构 中，业务分析师将会给予足够的权限，以提升业务价值为明确目标，推荐项目的变化向这个目标努力；而不仅仅只是作为技术团队的一部分，被看做“技术的跟屁虫 ”。

那系统分析师又该如何？

注意这里的区别：我们所说的是业务分析师，而不是系统分析师。“系统分析师”是干什么的？虽然在多数情况下，系统分析师的技能足以有效地完成业务分 析相关 的工作，我还是要区分开这两个角色，因为他们的角度不同——业务分析师的重点放在对业务需求的理解之上，并受其驱动；而系统分析师却常常从相反的角度考 虑，他们主要思考基于技术的解决方案，有时提出的方案甚至不利于真正解决业务问题（“Wow，我已经告诉你解决方案了！”）。系统分析师可以成为好的业务 分析师，但是他们一定要小心，必须压抑自己提出技术建议的冲动。

要业务分析师干什么？我们需要“客户”

业务分析师愿意花时间去接近 不同的“利益相关者”，也就是那些代表公司或组织、关心业务变更成功交付的人。业务分析师要理解多种不同维度的业务需求；与管理层讨论总体方向和目标；法 务部门一起工作，看看新的或是变更后的业务流程会产生哪些法务上的影响；跟后勤部门一起工作，识别办公空间或仓库布局的变化，理解流程变化对于物流、产品 直到发货过程的潜在影响；还要跟行政人员一起，搞清楚新的审核过程可能造成哪些潜在的瓶颈……以及诸如此类的事情。

分析调研进行到某个时间点时，我们会发现：要解决某个业务问题，就得在技术上想办法。此时，业务分析师的角色会有点变化，我们要加入到技术可行性的 讨论之 中，要决定是“构建vs购买”，或是决定内包还是外包。在这个阶段中，传统的业务分析师就会参与业务案例的制定，组织在实施敏捷时可以借助这些案例；至于 对项目的判断，要看它们能够为组织带来哪些业务上的好处。如果没有这个价值取向，为了管理敏捷待办事项列表而正在进行的优先级排定工作，可能就会缺乏对项 目愿景的全面理解，从而导致需求出现问题。

上述决策确定之后，而且组织也打算在技术上投入一定资金，此时业务分析师的角色就又变了，成为了需求的 看护者、用户故事的收集者和指导者。业务分析师也是在此时积极参与到敏捷项目中，并成为敏捷软件开发项目团队的重要成员，代表客户和最终用户，并与其他团 队成员协作，以达成明确的业务需求，使其受益于基于技术的解决方案。

业务分析师与项目团队一起工作，保证用户故事的正确实现。对于团队来说，他们是客户的代言人，推进用户故事的详细说 明。在面对更广泛的利益相关者群体时，他们充当项目的代言人，负责在正确的时间将客户正确的声音传达给项目团队。一般来说，这里的“客户”，在很多敏捷相 关的文化中都有提到，并不是一个单一的个人，而是表示很多“利益相关者”构成的群体。这群人构成多样，经常意见相左，互相角力，有时甚至彼此敌对。他们对 于业务需求和“完成”的定义经常充满分歧。

看完上面这段话，你是不是觉得我不相信“现场客户”的作用？绝 对不是！我120%地坚信：敏捷开发过程要想成功，我们必须有现场客户。我们所面对的挑战在于：有太多不同客户的声音，经常向团队发出彼此冲突的命令。在 整个项目中，业务分析师必须随时能够从这些“噪音”中过滤出有用的信号，并识别出那个时刻哪个客户适于作为代表。

那么业务分析师到底是干嘛的？

在 敏捷项目中，业务分析师也是用户故事的守护者。他们会引导发现过程，并促进团队之间的沟通，通过提出“如果……会怎么样？”之类调查性的问题帮助客户代 表；而这些问题来自于他们对项目发端因素的广泛调查， 对于利益相关者群体的印象，以及对于组织正式结构之下错综复杂的政治和人际关系的理解。他们还有能力接触出资方，争取机会访问真实的客户（这些人是真正为 系统提供的服务付钱的人），知道应该怎么做才能形成竞争优势，让客户满意，并最终让组织取得商业上的成功。

业 务分析师要广泛掌握调研和人际交往技能，掌握使用批判性思维和怀疑思考的能力，还要使用多种多样的建模技巧和其他工具，帮助客户代表发现构成系统的故事范 围。业务分析师还能帮助客户代表用清晰易懂的方式表达这些故事，从而让“完成”的含义一目了然，同时与测试人员和客户代表共同工作，帮人们看清用户故事必 须要具备的验收条件。

最好的业务分析师会参与故事各个方面的讨论，并积极加入到系统的交互设计过程中。他们深刻理解用户群体与系统交互的多种方式，知道不同需求之间的分歧，并可以平衡这些分歧，让系统在设计上满足不同利益相关者的要求。

敏 捷业务分析师也是设计师，他们对系统的理解远不仅仅是识别和记录需求文档这么简单。他们知道屏幕上的功能流程背后意味着什么，也能保证系统的流程符合人们 实际的工作流程。颜色和字体、屏幕的界面布局和响应时间，这些因素对系统使用者的工作效率会产生哪些影响，敏捷业务分析师都了如指掌。他们寻找一切机会创 建人们愿意使用的、真正实用的系统，并愿意引导开发人员构建符合人的直觉和自然使用习惯的用户界面。在理想状况下，用户界面会让人觉得似乎消失不见了，因 为它们非常易用，操作人员甚至感觉不到界面的存在。

传统的分析方法，希望在弄明白“怎么做”之前先搞清楚要“做什么”。可这不适用于敏捷项目。敏捷开发过程有一种与生俱来的工作方式，就是在一个高效的迭代开发周期之中，我们总是要通过“怎么做”的过程来知道“做什么”。

在处理系统与用户互动的界面工作时，系统的外观和感觉很重要，敏捷业务分析师能将这方面的工作清晰地展现出来，使其得到团队的重点关注。

敏捷业务分析师要确保真正的业务价值得到发掘和展现，他们要跟项目团队和客户代表一起找到这些价值，这可以使得所有人的工作都变得更加简单、高效，同时达成客户的满意度和“粘性”。我们的客户也就会一而再、再而三地跟我们反复做生意。

谁应扮演业务分析师的角色？

在 Scrum项目中，产品负责人或首席客户推广人员最适于充当敏捷业务分析师。因为他们有足够的权力，也能得到相应支持，足以代表客户。这些分析师要积极参 与管理产品待办事项列表，并识别产品功能的优先级。此外，还要构建与业务利益相关者的良好关系，同时理解技术实现的可行性；有了这些作为基础，业务分析师 就可以积极参与项目价值的交付过程。敏捷业务分析师必须要成为业务项目团队的积极成员，还得努力做出贡献；而不仅仅是试着产生一长串带有“应该”之类词汇 的句子；还要代表、放大、守护许许多多客户的声音，提出“你们有没有想过……”这样艰难的问题，从而保证我们交付的产品可以达成客户多样化、相互牵制的需 求；还要基于以往和眼下的用户故事，与整个项目团队一起讨论和互动，以理解并识别缺陷、流程和问题。

业务分析师角色对于项目的成功不可或缺

技术是为了满足人的需要而存在，而不是成为人的需要！
——Malcolm Watson, 墨尔本Pronto软件公司开发经理

业务分析师人群应该走上前台，成为敏捷协作团队的积极参与者，因为他们力图创建可以交付真正的价值和客户满意度的系统。主动承担“业务分析师”的角 色，将 问题拆分成各个组成部分，理解真正的潜在需要，然后成为项目团队的积极参与者；这样交付的解决方案，能够创建出真正的竞争优势，提升客户满意度！

谁是我指出的这些“业务分析师”？

国际业务分析师协会（IIBA）指出：业务分析师“要充当各个利益相关者之间的联系人，从而提炼、分析、构成、验证与业务流程、方针政策、信息系统的变更相关的需求”。

业务分析师要承担“万能沟通者”的角色，以清晰有力的方式理解并表述出不同利益相关者考虑问题的角度，协助业务人员发现模糊的潜在需求并使其逐渐清晰，从而识别出真正有附加值的需求。