1.北京阿博茨科技有限公司
2.浅谈软件研发管理体系建设
3.知识表示学习框架OpenKE-PyTorch版使用指南
4.#gStore-weekly | gstore源码解析（一）：基于boost的知识gstore http服务源码解析
北京阿博茨科技有限公司
阿博茨科技是一家总部位于北京海淀学清路8号科技财富中心的创新型人工智能公司，核心团队由微软亚洲研究院的图谱精英构成，曾历经两次创业，完整均取得显著成就。源码公司已获得SIG、知识源码资本等知名投资机构的图谱pb合并删除源码数千万美金融资，目标成为数据处理和分析领域的完整独角兽企业。
阿博茨服务的源码客户广泛，包括招商银行、知识中国银行等头部银行，图谱平安资管、完整人保资管等头部资管公司，源码以及易方达、知识海通证券等金融机构。图谱他们利用先进的完整计算机视觉技术，如在图表识别领域的全球领先技术，以及自然语言处理和知识图谱，为金融、地产、博彩等领域的客户提供智能投研、风控和运营等解决方案。
作为技术壁垒，阿博茨拥有计算机视觉、自然语言处理和知识图谱的核心技术，其中一项技术被列入“中美技术禁运清单”，凸显其独特价值。公司荣誉颇丰，曾荣获达沃斯世界经济论坛“技术先锋”等称号，并在金融科技创业大赛中拔得头筹，获得了多项全球技术专利和认证。
阿博茨现招聘管理培训生，包括通用岗位和专业岗位，如技术中心管理培训生负责项目技术评审和落地，产品中心管理培训生则负责产品设计与优化。应聘者需具备良好的沟通理解能力、逻辑清晰和抗压性，以及自我驱动和执行力。对于AI相关背景、实习经历和特定技能的拥有者，将更具竞争优势。
如对阿博茨的职位感兴趣，可通过联系陈经理进行进一步咨询，邮箱jinch@abcft.com，联系电话****，公司地址位于北京市海淀区科技财富中心A座3A层。
浅谈软件研发管理体系建设
最近一段时间，我一直在反复思考一个问题：我们的软件研发管理体系应该是怎样的？在不断思考的过程中，逐步有一些粗浅的认识，在此将这些认识记录成文字，并期待能够与更多的伙伴碰撞，进一步完善这种认识，并逐步上升到理论高度，从而有利于指导具体实践。1. 对软件研发管理体系的一些概念认知
1.1. 研发管理是什么
关于研发管理，百度百科中这样定义：研发管理就是在研发体系结构设计和各种管理理论基础之上，借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。
也就是说，研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构，之后按照这种研发体系结构组件一支高水平的研发团队，设计高效合理的研发流程，借助合适的研发信息平台支持研发团队高效工作，以绩效管理调动研发团队的积极性，以风险管理控制研发风险，以成本管理使研发在成本预算范围内完成研发工作，以项目管理确保研发项目的顺利进行，而知识管理使得研发团队的扑鱼达人源码下载智慧联网和知识沉淀。
纵观各类软件企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分，最终追求的目标都是能否适合企业的发展，给企业带来市场和财务上的成功。
1.2. 基于CMMI的研发管理
CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则，实际上，大部分企业尤其是国内企业并不会严格按照这个模型去做，因为如果每一个过程域都不打折扣地执行地话，需要非常标准化的流程和强大的资源支撑，在这个讲究快速响应变化的时代其实是很难做到的，通常这个时候都会进行相应的裁剪，甚至会结合敏捷迭代等方面的模式，从而逐步形成自己公司的研发管理体系。
1.3. 基于敏捷模式的研发管理
在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外，还有相应的成熟工具做支撑。例如，腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分，实现对需求的有效管控和分解，从而确保持续迭代上线。
敏捷研发管理在当前我们以业务为导向、项目为主的情况下，要全面实施尚有较大困难，当然并非是完全不能做，主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。
1.4. 基于IPD的研发管理
之前有简单了解过IPD产品研发管理体系，我认为其中的核心就是“四四四”模型，四四四代表了四大团队、四个流程、四个支撑体系。
四大团队建设包括建立集成产品管理团队（IPMT）、建立产品市场团队（PMT）、建立产品开发团队（PDT）、建立技术开发团队（TDT）。
四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。
四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。
个人感觉，基于IPD的ecshop微分销砍价源码产品研发管理从整体上来看是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动。
IPD的理念和敏捷开发理念在本质上是基本一致的，比如以市场需求（用户价值）为核心，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。
从理论上来讲，IPD研发管理体系是一个较全面的体系，在当前我们的现状下也可能容易出现水土不服的情形，当然其中有一些好的做法是值得借鉴的。
2. 什么样的软件研发管理体系适合我们的发展
从项目及产品的研发角度来看，发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式，由于项目的特点及人员的组织结构等因素，项目开发及产品研发的周期往往较长，较难适应市场快速变化的需要，也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂，推行了敏捷研发模式，或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。
那么，针对当前我们所面临的一系列问题，究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展？我们需要重构我们的软件研发管理体系吗？我们有必要重构我们的软件研发管理体系吗？带着这些问题，我想主要思考几个方面的问题。
2.1. 能否快速适应未来业务的发展变化
技术是为业务发展而服务的，因此在考虑软件研发管理体系构建时，第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下，信息化能力是越来越多客户的第一选择，因此在业务的快速发展方面需要更加强有力的技术支撑，而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系，特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。
2.2. 在业务出现较大波动时能否弹性伸缩
另外一个问题就是，业务在发展过程中，受大环境等诸多因素的影响，定然很难一直都是呈现直线上升的发展趋势，这当中必然会有波峰波谷，只不过这个波峰波谷是大是小的问题。而我们面临的问题则是，当出现较大的波峰波谷的时候，我们的研发管理体系应该如何适应？特别是在软件业务处于相对低谷时，既能够继续保持对技术研发的持续投入，又能够在应用开发等方面有一定的可伸缩性，从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下，不同业务单元的发展会有不同的发展路径，对软件研发能力的诉求也有所不同，那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。
对于基础研发能力，个人认为应该是一个软件公司最内在的核心技术能力，往往很多时候基础研发工作很难像做行业应用开发那样立竿见影，但这项工作干得不好往往又容易成为行业研发能力的掣肘，这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。
对于行业研发能力，个人认为应该要从两个方面去考虑，一个是产品化的能力，其二才是应用开发能力。应用开发能力很好理解，就是目前我们这么多年以来一直在做的各种类型的项目开发，而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容，不过这条路上我们尚开始起步，还有很长的路要走，也还有不少坑要踩。航线订舱c 源码个人认为，产品化的能力能否真正发展起来，其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发，应用开发更多是定制化的开发，是客户导向的软件开发，通常面向的是一个或少数几个的客户；而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发，是市场导向的软件开发，面向的是一个或多个的客户群体，甚至面向的是一个市场或跨界市场。
2.3. 新技术研发及成果转化能否跟上业务变化
最近几年，新技术层出不穷，在软件架构的发展方面也非常迅猛，历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看，我们有少量的项目/系统采用了SOA架构，然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看，我们在技术领域的持续跟进及成果转化方面已然有落后趋势，这方面需要我们奋起直追才行。当然，出现如今这种局面固然由众多因素催生而成。比如，已有开发框架前端兼容性的问题最近一两年以来常常被诟病，诚然有它内在的好处，然则最近一两年以来，用户对系统的用户体验要求更高了，不再是单纯地满足于功能实现层面，而是开始追求良好的人机交互和界面展现。因此，这方面势必对新技术的要求更加迫切。最近几年，当不少团队都在往前后端分离走的时候，我们至今的绝大部分软件项目开发仍然停留在前后端分离之前，对不少用户界面展现要求高的软件项目而言，难以快速有效响应变化，同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。
因此，能否在新技术的研发上抓住正确的方向并加快研发成果转化，为业务的快速变化提供强有力的技术支撑，是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看，研发架构方面，我们虽说不能完全抛弃传统的单体/垂直架构，但我们必须要往微服务架构方向迈进，除了与最新技术接轨之外，更重要的是如何进行业务解耦，沉淀行业积累，并反向推动人员组织层次的变革，提升软件生产效率，提高软件质量。
除此之外，对于人工智能、区块链等新领域，也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。
2.4. 在标准化和敏捷迭代之间如何平衡
标准化的软件研发道路固然有不少好处，有严谨的流程、规范的体系、固定的套路，当然更多的则是瀑布开发模式，虽然最近几年也陆续有迭代开发的模式，但更多的是被动式响应，而且这种迭代开发模式基本上是大阶段的划分，在每一个大阶段里面依旧是开发市场平台源码一个典型的瀑布开发模式，即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤，横跨周期往往较长，一旦发生需求变更，变动的代价过高。
敏捷开发强调以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
那么，问题来了，既然标准化项目管理模式下存在太多流水线作业及效率低下等问题，那么我们能够直接转向敏捷迭代模式呢？世界上万事万物都是对立统一的，个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面，在现有的以项目为主导的软件开发体系中，标准化模式是我们一直以来的主要做法，也积累了不少经验做法；另一方面，采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪，既能提高软件质量和软件开发效率，也能够保留一定的规范性和软件过程文档。例如，针对项目管理，通常是五个过程组：启动、规划、执行、监控、收尾，那么我们其实可以结合实际将规划提前，将监控贯穿于执行过程，这样就势必要求在启动时也要做好项目计划相关工作，在执行过程中抓住关注点并定期监控其执行情况，在收尾阶段做好项目回顾总结。
不论采用何种模式，我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
因此，我们的软件研发管理体系中是否应该引入DevOps，进而改善公司组织文化、提高员工的参与感、提高交付效率，我想这也是需要重点关注和考虑的。
2.5. 组织过程资产能否持续积累并盘活
组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标，项目组织在实践中形成自己独特的过程资产，构成组织的核心竞争力。
组织过程资产主要包括但不限于以下内容：项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训，其中既包括已经形成文字的档案，也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档，包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。
经过多年的软件开发，我们做了大大小小形形色色的软件项目和产品，也逐渐积累了一些行业化的软件项目，但总的来看，能够形成规模化效应的软件产品尚较为匮乏，更多的是以定制化开发为主的软件系统，当然也积累了不少项目经验。在这过程中，也积累了不少标准、规范、流程、模板等各类软件过程资源。然而，从目前掌握的情况来看，这些资源是分散的，不够体系化的，还谈不上真正意义上的资产，至少在价值的发挥上还不充分。况且，软件行业这几年的人才流动率明显加快，人员更替的速度以及未能体系化的过程资产积累，加剧了组织过程资产的盘活难度。
那么，构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分，也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中，其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产，这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”，是一项涉及知识库、过程资产、环境和交流等元素的整合过程，所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言，我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。
3. 构建我们的软件研发管理体系应包含哪些内容
软件研发管理体系的建设离不开几个关键要素：人员、技术、过程、资源，并在此基础上配以相应的管理手段。进一步来看，要构建适合我们自身发展的软件研发管理体系，需要着重考虑几个能力体系的建设，即：人员组织能力、技术研发能力、过程管理能力和资源建设能力。
前面也有针对“什么样的软件研发管理体系适合我们的发展”进行了一些相对粗浅的探讨，那么在考虑如何构建适合我们发展的软件研发管理体系之前，我想这里首先要明确一下我们期待构建的软件研发管理体系。我们公司的业务涉及众多行业客户，一直以来主要以定制化项目开发为主，同时也涉及运维服务，而在产品研发等方面则处于起步阶段，且在一段时期内项目、产品、服务将会长期并存，因此，个人认为适合我们的软件研发管理体系应该至少经历三个阶段，包括初期的标准化软件研发管理体系、中期的标准化与敏捷相结合的软件研发管理体系和后期的敏捷化软件研发管理体系。
基于上述这样的考虑，正常来讲我们当前应该在标准化的软件研发管理体系中要做进一步强化，而考虑到市场的快速变化、技术的日益进步，个人认为我们当前就需要开始考虑标准化的与敏捷相结合的软件研发管理体系。为什么还需要考虑标准化的软件研发管理体系呢？主要是传统的定制化的软件项目开发依旧占据主体，且目前在这方面仍然有非常大的改进提升空间，然而标准化的模式常常是过于强调标准、规范、流程，开发模式过于线性化，因此需要引入敏捷开发模式。所以，我们又需要考虑敏捷的软件研发管理体系，这主要是为了更好地适应市场变化、更快速地响应客户需求，更好地提升软件开发生产效率。
3.1. 人员组织能力
关于人员组织能力，个人认为有两个关注点：一是团队的发展，二是个体的发展。这两者是相辅相成、互相融合促进的。综合来看，人员组织能力的建设主要包括设立与公司战略、业务、技术发展相适应的组织架构，并配以构建相对完整可行的岗位体系和对应的人员考核体系，同时在团队建设等方面持续改进与提升。
关于组织架构，当前的组织架构虽然解决了一些曾经的主要矛盾，但依然存在不少问题，突出的一点就是核心薄弱，即核心技术能力不强，仍旧需要投入大量的人力到各行业的应用开发中，当然这与我们一直以来承接定制化的软件项目开发不无关系。这是当前乃至未来一定时期需要解决的。
同时，最近几年来的组织架构主要是以职能型组织架构为主，产品线为主导的研发模式尚不成熟，针对项目及产品的团队构建主要是以项目经理来驱动，在项目团队的组成方面固然与互联网的项目团队截然不同。在团队建设方面，需要进一步打通团队之间的壁垒，强化团队的整体协同作战能力。
在岗位体系方面，特别是对人员的绩效评价方面，需要在已有的岗位体系基础上进一步考虑如何更好地执行落地，确保个人绩效目标与团队绩效目标的一致性和顺利达成。
3.2. 技术研发能力
结合我们的实际，我认为在技术研发能力方面要考虑四个方面：一是技术预研，二是技术开发，三是产品开发，四是定制开发。
关于技术预研，通俗来讲就是：预研=预先+研究。这种预先研究通常来源于几个方面，例如来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等。为什么要做技术预研呢？这是扫清前行障碍的过程，这为后续展开总体设计、详细设计指明了方向，也是持续积累公司技术能力、保持与新技术同步而不至于脱离轨道的方式之一。
关于技术开发，其实这里主要指与基础平台、公共组件、关键技术等方面的技术研发。另外一个方面来理解，技术开发是技术预研的延续，是在技术预研成果经论证的基础上开展的一系列能促进公司发展、业务发展、技术发展而开展的技术研发工作。
软件产品是指向用户提供的计算机软件、信息系统、套装软件或在提供计算机信息系统集成、应用服务等技术服务时提供的软件，是通用的产品应用于某一行业领域而不是像软件项目一样为某一需求或者单位定制开发。
软件项目主要为特定企业开发或者部署实施一套专用的系统，在进入项目开发之前需要与用户进行具体的交流和讨论，了解用户心中对于软件预期的样子，后经过招投标，签订合同，实施交付。
关于产品开发，这方面我们尚处于起步阶段，尚缺乏一套完整可行的产品研发流程及最佳实践，需要摸着石头过河，也需要长期坚持不懈地努力。
关于定制开发，当前主要是基于客户需求的软件项目定制开发，后续还会包括基于产品衍生出来的定制化开发。前面的这种方式是我们当前最熟悉的模式，主要面临的困境是两个：一是如何实现快速交付，二是如何实现成本可控，从而提升软件项目的利润。
做项目侧重于在最短的时间内，按照客户的需求开发出操作敏捷，用户体验良好的软件。而做产品则侧重于市场驱动，时间相对充足，但要开发出有竞争力，有自身特色，且受客户欢迎的产品，要求功能响应速度快，操作简单，界面美观。
技术预研+技术开发是强化内核的内在需要，定制开发是现阶段的生存根本，产品开发则是为未来发展铺路。
3.3. 过程管理能力
过程管理能力主要包括项目管理、开发管理、质量管理和配置管理等几个方面，需要一套完整合理的流程贯穿整个过程。
在项目管理方面，我们需要梳理当前项目管理体系的标准、规范、流程及相关实践，建立以过程为核心、以度量为基础、以人为本的可裁剪、受认可、能执行的信息集成项目管理体系，进一步规范公司的项目管理，提升项目群管理能力。结合项目管理的五大过程组（启动、计划、执行、监控、收尾），并结合敏捷迭代的思想，形成标准化项目管理与敏捷迭代相结合的具有实际指导意义的方法体系，同时将这套方法体系以指南性文件、规范性文件等形式传导到相关人员，确保可落地执行。此外，为加强过程管控、资源共享、工作协同，组建PMO团队，实现对项目群及重大项目的统一管控与决策支持。
在开发管理方面，一是要落实统一的软件开发规范，包括架构规范、设计规范、UI规范、编码规范、测试规范等。强化设计及开发关键环节的评审，包括对需求、概要设计、详细设计、UI设计等的设计方面的评审，对测试用例等方面的评审，对代码的评审检查（例如利用SonarQube进行代码的自动检查等）及发布评审等。同时通过试点+逐步铺开的方式着力推进CI/CD的落地。
在质量管理方面，进一步强化项目质量审计，逐步改进软件过程生产效能。而在配置方面，则加强对配置项的识别、配置空间的管理、变更控制等，规范软件开发过程，确保构建正确的系统。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。
综合来讲，在过程管理方面就是要形成一套适用的软件研发管理流程，并配以相应的节点管控，让不同开发角色之间即各司其职又相互融合促进，从而促进软件开发自组织能力的逐步提升，充分调动软件开发人员的主动性和积极性。
3.4. 资源建设能力
简单来讲，资源建设是软件研发管理体系中的支撑体系。资源建设主要包括了一系列的制度规范、工具、模板、过程资料及交付物（例如项目文档、源代码等），以及相应的经验、知识沉淀等。一是要适时梳理相应的制度、规程、标准、规范、文档模板等，形成标准化资源库；二是要对不同行业历年来的项目资料及源代码分门别类做好规划和归档管理，形成静态库（归档库）和活跃库，同时做好数据安全管理；三是要对软件研发人员及工作中的一些隐性知识转化为显性知识，并逐步构建软件研发的知识图谱，促进知识经验的持续积累与转化，并通过链条式、网状式等方式实现知识分享与传播，形成经验知识库。
知识表示学习框架OpenKE-PyTorch版使用指南
OpenKE（An Open-source Framework for Knowledge Embedding）是一个基于PyTorch的开源知识表示学习框架，专注于知识图谱相关问题。该框架包含了多种算法的实现，用户可访问其官网获取数据集、API文档及论文。
OpenKE提供PyTorch版与TensorFlow版，其中GitHub默认版本为PyTorch。以PyTorch版为例，简述使用步骤。
首先，确保机器已配置PyTorch环境。在Linux服务器上执行以下操作：下载PyTorch版代码，进入目录，编译C++文件，回到OpenKE目录，并拷贝示例文件夹中的TransE算法、FBK数据集的示例程序。创建checkpoint文件夹后，执行程序开始训练，训练个周期，预计耗时约一小时。训练后，输出训练效果。
OpenKE官方未明确解释结果中l和r的含义，需查阅源代码。在/OpenKE/examples/train_transe_FBK.py中，明确指出该程序执行链接预测任务。进一步探索/OpenKE/openke/base/Test.h，得知链接预测任务是指在已知三元组(h, r, t)中删除头实体h或尾实体t，预测准确度的评估。结果中的l和r代表删除头实体h和尾实体t的预测结果，而raw和filtered分别对应未修复数据与修复后的数据预测结果。
#gStore-weekly | gstore源码解析（一）：基于boost的gstore http服务源码解析
gStore, 由北京大学王选计算机所数据管理实验室的邹磊教授团队开发的图数据库系统，专门针对知识图谱设计，旨在高效管理大量关联数据。图谱学苑的技术分享系列将推出gStore源码深度解析系列，目标是帮助内核开发者和图数据库研究者理解系统内部构造。系列将逐步深入，从外部到核心，由易入难，以SERVER服务为核心，剖析其启动、参数处理、线程池管理和HTTP请求解析等关键环节。
首先，ghttp模块基于Ole Christian Eidheim的Simple-Web-Service构建，提供一个基于Boost.Asio的轻量级HTTP服务器。服务启动时，采用fork创建子进程，主进程作为守护进程，确保服务的稳定运行。通过命令行参数，用户可以指定HTTP服务监听端口和预加载数据源。
ghttp通过线程池技术实现多线程服务，个线程预设，HttpServer负责接收所有请求，而query接口则有其独立的子线程池。每个请求都会在子线程中独立处理，参数处理包括GET请求的URLEncode/Decode和POST请求的JSON格式解析。
在request_thread方法中，接口参数的提取和校验是核心环节，但安全机制的详细实现将在后续章节深入讨论。阅读时，结合Main/ghttp.cpp源码将有助于理解。下篇文章将聚焦于核心接口如build、load、query的具体实现逻辑解析。
