一、什么是低代码(low-code)？为什么需要低代码？

（一）信息化难题

企业在信息化转型过程中常面临诸多困境：传统软件开发周期长（通常3-6个月），无法快速响应业务变化；专业开发人才稀缺且成本高昂，中小企业难以承担；各部门系统孤立形成数据孤岛，集成难度大；业务人员需求与技术开发脱节，落地效果不佳；简单部门级应用需排队等待IT团队开发，效率低下。

（二）低代码(low-code)介绍

为破解上述难题，低代码应运而生。低代码是一种可视化应用开发方法，通过图形化界面、拖拽组件和模型驱动逻辑，以最少手工编码快速构建应用程序，本质是一组数字技术工具集合。它能降低开发门槛，实现业务与技术协同，将应用交付周期缩短至2-4周，助力企业快速完成信息化落地，适配各类业务场景与复杂系统搭建需求。

（三）低代码与传统开发对比

相较于传统开发，低代码优势显著：开发效率提升500%以上，无需从0到1编写全部代码；成本降低60%以上，大幅减少专业开发人才依赖；上手门槛低，业务人员可参与搭建，无需深厚编码基础；迭代灵活，可快速响应业务调整，无需大规模重构系统；集成便捷，能快速对接企业现有ERP、CRM等系统，打破数据孤岛。

（四）低代码的衍生概念

1、无代码：低代码的简化形态，完全无需编写代码，纯通过拖拽组件、配置参数即可完成应用搭建，门槛更低，适合非技术人员（业务人员）快速搭建简单表单、审批类应用，如伙伴云、简道云等平台侧重此类模式，但灵活性略低于低代码。

2、aPaaS（应用平台即服务）：低代码是aPaaS的核心形态，aPaaS更侧重提供完整的云端应用开发、部署、运维一站式平台，除低代码可视化开发能力外，还包含服务器、数据库、安全防护等基础服务，如Zoho Creator、明道云均属于aPaaS范畴，支撑企业全流程应用开发与落地。

二、国内主流低代码平台十大能力测评对比

（以下内容来自作者的深度测评）

（一）织信Informat

1、平台介绍

织信是深圳基石协作科技有限公司自研的企业级AI低代码平台，团队主创由曾主导平安、微众、腾讯、华润、华为等知名企业信息化项目的核心团队组建，从专注企业数字化转型解决方案起步，逐步打磨成兼具灵活性与实用性的企业级低代码开发平台。

深耕低代码行业十余年，见证了从早期简单表单工具到如今企业级全流程解决方案的迭代，今天要测评的织信低代码，是由基石协作于2019年推出的核心产品，其核心团队成员均具备丰富的大型企业数字化系统研发经验，凭借多年行业实践沉淀，逐步升级为可提供“数据+流程+AI”全场景能力的企业级低代码平台，为各行业企业提供一站式数字化转型解决方案，助力企业快速实现国产化、自主可控的信息化部署，兼顾效率与安全，适配从中小规模到大型企事业单位的多样化需求。

2、核心能力

▐ 基础能力

织信低代码的主要功能模块围绕数据引擎、流程引擎、权限引擎三大核心展开，搭配仪表盘、AI辅助开发、拓展功能等模块，以“高效搭建、灵活拓展”为核心，兼顾易用性与企业级需求，覆盖从基础表单到复杂系统的全场景搭建。

▐ 数据引擎

作为织信低代码的核心基础，数据引擎的实用性堪称行业上游水平，其展现方式贴合企业日常操作习惯，支持多达5个大类、35种字段组件（可自定义组件），拖拽即可生成对应表单，无需复杂操作。用户可根据业务场景，为表单设置缜密的逻辑规则，实现字段联动、实时更新，有效打破数据孤岛。

此外，数据引擎还支持80+种高级函数，覆盖运算、日期、字符串等各类业务场景，满足复杂数据处理需求。数据录入支持Excel导入、在线编辑等多种方式，同时可通过链接分享实现内外协作，权限控制细致，保障数据安全。

▐ 流程引擎

织信低代码的流程引擎适配性极强，完全不输专业流程管理工具，采用可视化拖拽+连线操作，无需代码即可设计完整业务流程，遵循BPMN2.0规范，支持自由流程、固定流程、分支流程、并行流程等多种模式，可满足企业所有业务流程需求。

流程审批功能全面，支持审批、退审、加签、撤回、手写签名等操作，处理人可根据实际情况灵活应对；同时支持待办工作流设置，可配置触发条件、负责人及状态，实现流程智能流转，大幅减少人工干预。

▐ 权限引擎与仪表盘

权限引擎提供团队、应用、数据三级权限管控，可灵活配置不同人员的数据查看、操作权限，搭配数据智能预警功能，当数据出现异常时，可第一时间向负责人推送消息，保障数据安全与业务合规。

仪表盘模块支持创建各类统计卡片，提供丰富的可视化报表功能，可多维度展示数据、实现数据对比，同时支持电脑端、移动端多端查看，让移动办公更便捷，帮助企业实现数据全面掌控。

▐ 低代码+AI

织信低代码的核心特色的是AI与低代码的深度融合，区别于普通低代码平台的基础搭建能力，其提供AI自动建模、AI辅助开发、AI组件开发三大核心能力，用户输入简单指令即可快速构建数据表业务模型，30s可实现从需求到成品页面的快速生成，大幅提升开发效率。同时支持API接口、脚本、拓展包等多种拓展方式，可集成第三方服务，满足企业个性化定制需求。

3、优势

可扩展性强，适配复杂场景。织信低代码支持代码开发、API接口、拓展包等多种拓展方式，可轻松集成第三方服务，同时支持分布式架构、集群部署，能承载上亿级数据，适配ERP、OA、CRM等复杂管理系统的数字化升级，满足中大型企业的复杂业务需求。

AI赋能，开发效率突出。其AI辅助开发能力大幅降低了开发门槛，无论是技术人员还是非技术人员，都能快速上手搭建应用，同时支持私有化部署，保障企业数据隐私与安全，适配央国企、军工等对合规性要求高的行业。

行业模板丰富，适配性广。平台沉淀了CRM、ERP、HR等多种行业解决方案模板，覆盖制造、金融、医疗、地产等多个领域，减少企业从零搭建的工作量，同时可根据自身需求微调，适配不同行业的个性化需求。

4、不足

深度定制门槛较高 虽然基础搭建无需代码，但进行深层次业务逻辑定制时，仍需要一定的代码知识和技术能力，对无开发背景的团队来说，学习成本较高，可能需要专门安排技术人员支持。

学习资源与社区氛围待提升 相比成熟低代码平台，织信的学习教程、案例分享相对偏少，初次上手的用户可能需要自行摸索，官方客服支持虽到位，但社区答疑、视频教程等资源仍需完善。

5、商业模式及持续生存能力

▐ 商业模式

织信低代码采用订阅制+定制化服务的商业模式，分为面向中小企业的标准版、面向中大型企业的定制版、面向高合规需求企事业单位的旗舰版，不同版本在数据量、功能权限、服务支持上有所差异，同时提供个性化定制服务，适配不同规模企业的预算与需求。

▐ 持续生存能力

织信低代码由具备大厂信息化经验的核心团队操盘，自2019年推出以来，历经多年打磨，已积累4万家企业用户，服务吉利控股、君乐宝乳业、某飞机设计研究院等行业头部客户，凭借扎实的产品能力和广泛的行业适配性，持续生存能力强劲。

6、客户画像

经过多年发展，织信低代码累计服务4万家企业用户，主要客户规模为50人以上的中大型企业，行业覆盖国防军工、央国企、生产制造、金融证券、生物医疗等多个领域，尤其受到对合规性、数据安全、系统稳定性要求高的企业青睐。

7、评测结论

织信低代码综合评分（满分100分，一颗★2分）

易上手度：★★★★

基础能力：★★★★★

数据管理：★★★★★

API能力：★★★★★

低代码能力：★★★★★

性价比：★★★★

模板质量：★★★

样式交互：★★★★★

AI能力：★★★★★

市场口碑：★★★★

整体评分：90分

8、选用建议：

中大型企业有复杂业务系统搭建需求，且对数据安全、合规性、可扩展性要求较高的，可优先选用。

需要AI辅助开发、追求高效搭建，或有私有化部署需求的企事业单位，织信低代码适配度极高。

国防军工、制造、金融等对系统稳定性和数据承载能力有高要求的行业，可重点考虑，其行业解决方案能快速适配业务需求。

（二）宜搭

1、平台介绍

宜搭是由深耕企业数字化领域多年的阿里钉钉团队打造，历经从基础零代码工具到宜搭Plus低代码平台的迭代打磨，逐步升级为一个为企业提供全场景数字化搭建服务的低代码PaaS平台，为企业的办公协同、业务管理、流程审批等场景提供一站式解决方案。

依托阿里集团的技术积淀与生态资源，搭配灵活的代码扩展能力和丰富的插件支持，兼顾易用性与定制化需求，适配从小微企业到中大型企事业单位的多样化数字化转型诉求。

2、基础能力

宜搭的主要功能模块由表单、流程、报表、插件中心与低代码扩展五大核心部分组成，以“生态联动、灵活拓展”为核心，依托钉钉生态优势，实现办公场景与业务场景的深度融合，让低代码搭建更贴合企业实际使用需求。

▐ 表单

进入表单配置页，采用可视化拖拽操作，上手门槛适中，其提供的页面组件超过70个，在同类低代码平台中表现突出，组件规范度与成熟度极高，涵盖基础输入、数据关联、附件上传等各类场景，可满足不同行业的表单搭建需求。配置完成后的效果实时预览，无需反复调试，所见即所得。

表单支持Excel导入、在线编辑等多种数据录入方式，同时可依托钉钉生态实现内部协作共享，权限控制细致，可针对不同人员配置表单查看、编辑、提交等权限，保障数据安全。此外，表单还支持逻辑规则配置，实现字段联动、必填校验等功能，提升数据录入的准确性。

▐ 流程

虽然宜搭早期以零代码工具起步，但流程引擎功能已十分完善，丝毫不逊色于专业流程管理平台。其遵循BPMN2.0规范，采用可视化拖拽+连线的配置方式，无需代码即可设计完整的业务流程，支持固定流程、分支流程、并行流程等多种模式，适配企业审批、业务流转等各类场景。

流程审批功能全面，支持审批、退审、加签、撤回等常用操作，处理人可根据实际业务需求灵活应对；同时支持流程触发条件配置，实现数据提交后自动触发审批流程，大幅减少人工干预，提升流程处理效率。

▐ 报表

宜搭的报表模块与表单、流程数据深度联动，支持多数据源聚合分析，可将多张表单数据进行统计、筛选、合并、运算等操作，生成各类可视化报表。提供多种图表类型，支持多维度数据展示、对比分析，可根据企业需求自定义报表样式，帮助企业快速掌握业务数据情况。

报表支持实时更新，数据变化后无需手动刷新即可同步展示，同时可嵌入钉钉工作台，方便员工随时查看，实现数据驱动决策。

▐ 低代码+插件中心

宜搭在各个功能层次均预留了代码扩展槽，将定制能力大量开放给用户，专业开发者可通过代码对表单、流程、报表、页面等能力进行扩展，满足企业深层次的个性化定制需求，在数据逻辑定制上几乎无限制。

其插件中心是核心特色之一，可便捷接入各类扩展能力，目前已支持发票识别、身份证识别、公章识别等插件，用户通过可视化配置即可快速接入，无需额外开发，进一步提升搭建效率（目前部分插件仍在内测阶段）。

3、优势

组件丰富，拓展性强 宜搭拥有70+成熟组件，覆盖各类业务场景，同时预留充足的代码扩展槽，专业开发者可灵活定制，搭配插件中心的拓展能力，既能满足基础搭建需求，也能应对复杂业务场景的定制化诉求。

钉钉生态联动优势 依托阿里钉钉生态，宜搭可与钉钉办公场景深度融合，实现应用嵌入钉钉工作台、钉钉消息推送等功能，无需额外下载APP，企业员工可直接通过钉钉使用搭建的应用，大幅降低推广与使用成本。

大厂背书，稳定性强 由阿里钉钉团队操盘，依托阿里集团的技术积淀，平台稳定性与安全性有保障，同时产品迭代速度快，持续优化功能体验，能及时响应企业数字化转型的新需求。

4、不足

对新手不够友好。产品设计偏技术导向，配置过程中会出现较多开发语言相关内容，有开发经验的用户接受度较高，但非技术背景的业务人员想要快速搭建趁手的应用，学习成本较高，必须有IT人员协助。

应用模板质量欠佳。目前宜搭的应用模板数量较少，且大多只是基础框架，内容相对简单，安装后需要进行大量配置才能正常使用，缺少成熟复杂的行业模板，无法有效减少用户从零搭建的工作量。

5、商业模式及持续生存能力

▐ 商业模式

宜搭目前有四个付费版本，面向小微企业的普惠版（50个账号免费）；面向中小企业的标准版（58元/账号/年）；满足中大型企业定制需求的企业版（98元/账号/年）；全定制化能力开放的尊享版（168元/账号/年）。不同版本对数据集数量、附件容量及自定义功能做了明确限制，其商业模式带有阿里一贯风格，现阶段重点聚集合作伙伴、引流阿里云，收费并非主要诉求。

▐ 持续生存能力

宜搭倚靠阿里集团的优越资源，推出后快速迭代，从零代码工具升级为低代码平台宜搭Plus，短短时间内已服务上千家企业，聚集数百家生态开发者，产品生态逐步成熟。依托阿里的技术与资金支持，产品创新能力与持续生存能力极强，未来仍将持续拓展功能边界。

6、客户画像

经过多年发展，宜搭已积累大量企业用户，客户规模覆盖小微企业到中大型企业，行业涉及面较广，尤其受到依托钉钉办公的企业青睐，其中小微企业与中小企业占比最高，多用于轻量级办公审批、简单业务管理等场景。

7、评测结论

宜搭综合评分（满分100分，一颗★2分）

易上手度：★★★★

基础能力：★★★★★

数据管理：★★★★★

API能力：★★★★

低代码能力：★★★★

性价比：★★★★

模板质量：★★★★

样式交互：★★★★

AI能力：★★★★

市场口碑：★★★

整体评分：82分

8、选用建议：

依托钉钉办公、需要实现办公与业务场景深度融合的企业，可优先选用宜搭，生态联动优势突出。

有专业IT人员支持、既需要基础搭建功能，又有深层次定制化需求的企业，宜搭的扩展能力可充分满足诉求。

中大型企业有复杂业务系统搭建需求，且注重平台稳定性与安全性，同时希望依托大厂技术保障的，可重点考虑。

（三）微搭

1、平台介绍

微搭，是由深耕云计算与企业数字化领域的腾讯云核心团队打造，历经从微信生态专属开发工具到全场景低代码平台的迭代打磨，逐步升级为一个聚焦“生态连接+高效开发”的企业级低代码PaaS平台，为企业的小程序开发、内部管理、客户运营等场景提供一站式解决方案。

依托腾讯集团的技术积淀、微信生态资源及云原生能力，搭配AI辅助开发与灵活的代码扩展能力，兼顾易用性与企业级需求，适配从小微企业到中大型企事业单位的多样化数字化转型诉求，尤其在C端应用搭建上具备天然优势。

2、基础能力

微搭的主要功能模块由表单、流程、报表、低代码IDE与生态联动五大核心部分组成，以“微信生态深度适配、多端协同开发”为核心，依托腾讯云技术底座，实现小程序、H5、Web端一次开发、多端部署，让低代码搭建更贴合企业C端运营与内部管理需求。

▐ 表单

进入表单配置页，采用可视化拖拽操作，上手门槛较低，其提供了丰富的UI组件，涵盖基础输入、数据关联、附件上传、身份识别等各类场景，可满足不同行业的表单搭建需求。配置过程实时预览，所见即所得，无需反复调试，大幅提升搭建效率。

表单支持Excel导入、在线编辑等多种数据录入方式，同时可轻松连接腾讯云数据库、腾讯文档等数据源，无需强制迁移数据，灵活适配企业现有数据体系。权限控制遵循RBAC权限体系，可针对不同人员配置表单查看、编辑、提交等权限，搭配SSO单点登录能力，保障数据安全与企业级协同需求。

▐ 流程

微搭的流程引擎兼顾基础审批与简易业务流转需求，采用可视化拖拽+连线的配置方式，无需代码即可设计完整流程，支持固定流程、分支流程等基础模式，适配企业内部审批、业务上报等轻量级流程场景。

流程审批功能简洁实用，支持审批、退审、加签等常用操作，可与企业微信深度联动，审批消息实时推送至企业微信，方便员工及时处理；同时支持流程触发条件配置，实现数据提交后自动触发审批，减少人工干预，提升流程处理效率。但相较于老牌BPM厂商，其复杂流程处理能力略有不足。

▐ 报表

微搭的报表模块与表单、数据源深度联动，支持多数据源聚合分析，可将多张表单数据进行统计、筛选、运算等操作，生成曲线、饼图、表格等多种可视化报表。报表支持实时更新，数据变化后无需手动刷新即可同步展示，帮助企业快速掌握业务数据情况。

此外，微搭新增用户数据分析能力，可直接查看小程序新增用户、活跃用户等数据，支持自定义查看方式，为企业C端运营提供数据支撑。

▐ 低代码+生态联动

微搭的核心特色是微信生态深度集成与多端开发能力，支持小程序、H5、Web多端开发，一次开发即可多端部署，小程序注册、开发、预览、发布全流程一步到位，1个人7天即可完成小程序和管理系统的定制开发与上线。

其提供低代码IDE，支持自定义组件和代码扩展，专业开发者可通过代码进行深度定制；同时内置AI生成能力，支持AI生成应用、组件、代码等，大幅提升开发效率。此外，微搭支持公有云与私有化部署，可一键将应用部署至自有服务器，保障数据主权。

3、优势

微信生态优势突出 与微信小程序、企业微信原生集成，调用流程免签名、免权限配置，小程序开发效率极高，是需要快速搭建小程序、H5营销页的企业首选，能最大化发挥微信生态的协同价值。

云原生与AI赋能 深度集成腾讯云Serverless等能力，实现弹性伸缩，服务器搭建、网络安全等无需企业自行处理；AI辅助开发能力覆盖全开发流程，大幅提升开发效能，人效产值可提升60%-150%。

大厂背书，部署灵活 依托腾讯云技术积淀，平台稳定性与安全性有保障；支持公有云与私有化部署，适配不同企业的数据安全需求，同时服务上海浦东国际机场、河南圆方物业等各行业客户，落地案例丰富。

4、不足

传统To B能力薄弱 在传统To B管理软件领域，生态和模板丰富度暂不如宜搭等平台，复杂业务流程处理能力相较于老牌厂商略有不足，难以适配大型企业复杂的业务管理场景。

模板实用性不足 虽提供多场景模板，但多为基础框架，行业针对性不强，安装后需要进行大量配置才能正常使用，无法有效减少用户从零搭建的工作量，尤其缺乏复杂行业解决方案模板。

5、商业模式及持续生存能力

▐ 商业模式

微搭目前有多个付费版本，所有用户均可享有体验版无限期试用资格，但发布应用有时效限制；面向初创团队、专注小程序开发的团队版（88元/月起）；面向中大型企业的企业版（10800元/年），不同版本在资源配额、功能权限上有所差异，商业模式侧重生态引流与云服务联动，兼顾自助搭建与企业级定制需求。

▐ 持续生存能力

微搭倚靠腾讯集团的技术与资金支持，迭代速度较快，不断新增AI辅助开发、用户数据分析等能力，产品生态逐步成熟。目前已服务上千家企业，聚集大量生态开发者，同时拥有完善的官方培训、认证体系，助力合作伙伴快速上手，持续生存能力极强。

6、客户画像

经过多年发展，微搭已积累覆盖多行业的企业用户，客户规模从初创团队到中大型企业均有涉及，尤其受到需要快速开发小程序、依托微信生态或企业微信办公的企业青睐。行业覆盖交通、文旅、房地产、农业等，多用于小程序开发、轻量级内部管理系统搭建等场景。

7、评测结论

微搭综合评分（满分100分，一颗★2分）

易上手度：★★★★

基础能力：★★★★

数据管理：★★★★

API能力：★★★★★

低代码能力：★★★★★

性价比：★★★★

模板质量：★★★★

样式交互：★★★★★

AI能力：★★★★

市场口碑：★★★★

整体评分：80分

8、选用建议：

需要快速开发小程序、H5营销页，或依托微信生态、企业微信办公的企业，可优先选用微搭，生态联动优势无可替代。

初创团队、零经验团队，想要快速搭建轻量级应用或小程序，微搭的易用性与AI辅助能力可大幅降低开发门槛。

对数据安全有要求、需要私有化部署，且注重平台稳定性，同时有轻量级业务管理需求的企业，可重点考虑。

声明：本测评仅为笔者经验总结的个人观点，与产品不存在利益相关。相关信息、功能描述均来自于网络公开信息、产品官方渠道及笔者使用体验，若有偏差，可与我们取得联系，我们核实后将进行勘误。

引言：

随着大模型和多模态 AI 的快速发展，向量已成为文本、图像、音视频等多元数据的通用语义表示。在这种背景下，检索增强生成（RAG）技术成为连接私有知识与大模型的核心桥梁，而高效的向量检索则是其关键支柱。

与将向量检索视为独立外挂服务的方案不同，Apache Doris 4.0 选择将向量检索能力深度集成于其 MPP 分析型数据库内核。实现向量检索与 SQL 计算、实时分析和事务保障的无缝融合。

本文旨在深入剖析 Doris 向量检索的系统级设计与工程实践，展示其如何在性能、易用性与规模扩展之间取得的平衡。

1. ANN 索引核心设计

Apache Doris 的向量索引基于 ANN（近似最近邻）算法实现，并非独立的外挂组件，而是深度集成于存储、执行与 SQL 引擎中的原生能力。在 4.x 版本中，其核心 ANN 索引能力主要包括以下几方面：

1. 多索引类型与距离度量支持：支持主流的 ANN 索引类型（HNSW、IVF）及常见距离度量（L2 距离、内积）。用户可根据业务在构建速度、内存占用与召回率上的要求灵活权衡。
2. 原生 SQL 集成：向量检索以原生 SQL 算子形式提供，支持直接定义向量列、通过 ORDER BY distance LIMIT K 进行相似度搜索，并能与过滤、聚合、JOIN 等算子自由组合，天然支持混合检索与分析。
3. 构建与查询解耦：采用异步索引构建机制，数据导入后即可查询，索引在后台构建并加载，避免导入阻塞，保障查询高峰期的稳定低延迟写入。
4. 向量压缩优化：在导入与构建阶段支持标量量化（SQ）、乘积量化（PQ）等压缩技术，显著降低存储与内存开销，提升高维大规模向量场景的资源效率。
5. 分布式并行执行：依托于分布式架构，Doris 向量索引天然支持数据分片与索引分布式存储；查询可在各 BE 节点并行执行；Top-K 结果在上层进行合并与裁剪。随着节点数量增加，系统能够在数据规模与吞吐能力上实现近线性扩展。

2. Benchmark & Analysis

Apache Doris 的目标并非追求单一指标的极限表现，而是在真实生产负载下，实现性能的均衡性、系统稳定性与架构可扩展性。本次测试将围绕这一目标展开，所用工具为 ZillizTech 开源的向量搜索 BenchMark：https://github.com/zilliztech/VectorDBBench。

• 云服务商：阿里云
• CPU：Intel Xeon Platinum 8369B @ 2.70GHz (16 核)
• 内存：64GB

2.1 导入与构建性能

测试结果表明，在 Performance768D1M 数据集上，Apache Doris 在保证同等索引质量的前提下，导入性能显著优于对比系统。尤为重要的是，其导入速度的提升并未以牺牲图结构质量为代价。Doris 在 QPS 达到 895 的同时，仍保持了 97% 以上的召回率，在性能三角的三个维度上取得了出色的平衡。

2.2 查询性能

即便单独考量查询性能，Apache Doris 同样处于业界第一梯队。

在 Performance768D10M 数据规模上，当召回率要求高于 95% 时，Apache Doris 的 QPS 表现优于 OpenSearch 与 Qdrant。此结果为默认配置下的开箱性能，未针对 Segment 文件数量等进行专项调优。

这里比较的是开箱性能测试，即不做 segment 文件数量的优化时的性能对比。

Milvus 的 flat 版本以及 Cloud 版本会有更好的性能表现，但是其出品的 VectorDBBench 只提供了 SQ8 量化后的成绩。

3. 核心设计与性能优化

Apache Doris 采用 FE（协调节点）与 BE（计算节点）构成的分布式架构。BE 作为核心执行单元，承担查询计划执行与数据导入任务，负责几乎所有高负载计算与大规模数据吞吐，是系统高性能的基石。尤其在向量场景下，数据写入、索引构建与向量距离计算都属于典型的 CPU 与内存密集型工作。为充分发挥其性能、保障系统稳定运行，我们对 ANN 索引的写入、构建与查询路径进行了系统优化。

3.1 写入与构建路径优化

优化主要分为两类：功能优化与性能优化。

• 在功能层面，依托 Doris 成熟的分布式集群管理与存储管理能力，引入 LightSchemaChange 实现轻量级的索引管理机制，这是目前专用向量数据库普遍不具备的能力。
• 在性能层面，重点聚焦于索引构建流程的优化，以显著提升索引构建速度和整体吞吐能力。

3.1.1 异步索引构建机制

Apache Doris 针对 ANN 索引构建开销大的问题，提供了异步构建机制。用户可在数据导入后，选择业务低峰期触发索引构建；在查询高峰时，仅需将已建好的索引加载至内存即可快速检索，从而将密集的 CPU 消耗转移至成本更低的时段。

在 FE 侧，CREATE INDEX 与 BUILD INDEX 通过 SchemaChangeHandler 编排：

1. 为每个分区创建影子索引与影子 Tablet（IndexState.SHADOW），并建立 origin→shadow 的 Tablet 映射与影子副本（副本初始态为 ALTER）。
2. 生成新的 schema version/hash，保障新旧版本隔离。
3. 通过 FE→BE 的 AgentTask（Thrift）分发构建任务到各 BE，BE 在 Tablet 层面完成索引数据构建。
4. 构建成功后，FE 原子性地将影子索引切换为正式索引，更新元数据并清理旧工件。

该流程在保证线上业务可读写的同时，实现了索引构建的在线隔离与数据一致性。

3.1.2 导入性能优化

为在保障索引质量的前提下提升写入吞吐与稳定性，Doris 采用了 多层级分片、双层并行、SIMD 向量化计算 的组合方式进行优化。

A. 多层级分片

Apache Doris 将逻辑表在内核层拆分为多个 Tablet。每次数据导入会生成一个 Rowset，每个 Rowset 又包含若干 Segment，而 ANN 索引正是在 Segment 粒度上构建与使用的。这一设计将“全表数据量”与“索引超参数”解耦，用户只需根据单批次导入的数据规模来设定参数，无需因数据总量增加而反复重建索引。

以单 BE 单分桶的典型场景为例，我们从实际经验中总结出如下参数可供参考：

得益于 Apache Doris 的分片架构下，索引参数可稳定在合理的规模区间，不受全表数据总量增长的影响。换言之，索引超参数的设置只需基于单个 Tablet 单次导入的数据行数。即便集群规模扩大，也仅需根据机器与分桶数量相应调整批次大小（batch size）即可。

以 HNSW 索引为例，在单 BE 集群中，针对每批导入 25 万、50 万、100 万行的典型规模，分别选择 max_degree≈100/120/150、ef_construction≈200/240/300、hnsw_ef_search≈50~200，即可在延迟可控的同时平衡召回与构建成本。

经验上，召回率随 hnsw_ef_search 提高而改善，但查询延迟也会线性增加。max_degree 与 ef_construction 过小会导致图结构稀疏、查询不稳定；过大则会显著增加构建时间与内存占用。因此，建议结合业务对召回和延迟的要求，通过离线压测确定最佳参数组合。

B. 双层并行构建

集群层由多台 BE 并行处理导入批次；单机内再对同一批数据进行多线程距离计算和图结构更新。配合“内存攒批”（在内存中适度合并小批次），可避免过细分批导致的图结构稀疏与召回下滑，在固定超参数下获得更稳定的索引质量与构建速度。

以 768 维、1,000 万条向量为例：分 10 批构建的召回率约可达 99%，若切成 100 批则可能降至约 95%。适度的内存攒批既不显著抬高内存峰值，又能提升图连通性和近邻覆盖，从而减少查询阶段的回表与重复计算。

C. SIMD 加速

向量距离计算是典型的 CPU 密集型计算。Doris 在 BE 侧采用 C++ 实现距离计算，引入 SIMD（单指令多数据）并行计算。可以更少的指令、更少的访存，更快完成把同样的距离，从而显著提升向量索引构建和重排阶段的吞吐能力。具体来讲：

• 并行计算多个维度：利用 SSE / AVX / AVX-512 等指令集，同时加载和计算 8～16 个浮点数，而非逐维循环。
• 减少内存访问：在计算前对向量数据进行批处理和转置，使数据在内存中连续排列，优化 CPU Cache 访问模式。
• 合并计算步骤：使用 FMA（乘加融合）指令，把“乘法 + 加法”合并为一步，并通过水平求和快速聚合向量数据。
• 高效处理边界情况：对维度不对齐的尾部数据，使用掩码指令统一处理，避免额外分支和判断。

3.1.3 向量压缩技术

以 HNSW 为代表的高性能索引数据结构通常将向量与图结构常驻内存。在 RAG 场景中，文本/图片/音频等模态向量维度约为 1,000，若每维使用 FLOAT32 存储，一百万行占用 4 GB，千万行则约 40 GB。考虑到索引结构的额外占用（约 1.3 倍），一千万行整体接近 52 GB。以 16C64GB 机器为例，单机索引上限约为千万级，需预留空间以避免 OOM，并保障查询和构建的并行开销。

为了显著降低内存占用、扩展单机承载能力，向量压缩技术成为关键。Apache Doris 在此提供了两种主流的实现方案：标量量化与乘积量化。

A. 标量量化（Scalar Quantization，SQ）

标量量化通过用低精度类型替换高精度类型来压缩存储空间，Doris 支持 INT8 和 INT4 的标量量化，并在导入和构建阶段完成编码。

如若将 FLOAT32（4 字节）替换为 INT8（1 字节）可节省约 75% 存储，进一步压缩为 INT4 则节省约 87.5%。如果压缩后数据的分布形态保持一致，召回率在可控延迟内接近未压缩效果。

上图展示了在 128 维和 268 维向量上的测试结果。相比 FLAT（不编码，用完整 Float32 表示每个浮点数），SQ8 可实现接近 2.5 倍的压缩，而 SQ4 可实现接近 3.3 倍的压缩。

值得说明的是，引入 SQ 不可避免的会带来额外的压缩计算开销（索引构建阶段），且标量量化更适用于各维度近似均匀分布的数据。如遇分布呈高斯或更复杂形态时，标量量化误差增大，则可采用乘积量化方式。

B. 乘积量化（Product Quantization， PQ）

RAG 等场景中，由 Transformer 编码器生成的向量，存在明显的语义结构、分布不均匀。乘积量化通过子空间划分 + 子空间学习型量化，能够更好地适配。

PQ 将高维向量分割为多个子向量，并为每个子空间独立训练一个码本（例如通过 k-means 聚类学习质心）。这使得数据密集区域能用更精细的码本保持细节，从而在整体上用更短的码长维持原始的距离关系。查询时通过查表与累加来估算距离，大幅减少了计算与内存访问开销。

我们在 128 维与 268 维上对比 SQ 与 PQ，参数统一设定为 pq_m = dim/2、pq_nbits = 8。

从空间占用看，PQ（m=68/128， nbits=8）的内存占比与 SQ4 大致相当，可实现约 3× 压缩。

除构建更快外，PQ 还可依赖查表加速解码，体现在更优的查询速度上。

关于 PQ 的超参数，实际使用时建议结合数据分布进行针对性适配与调优。根据经验，将 pq_m 设为原始维度的一半，pq_nbits 设为 8，在多数场景下即可取得良好的效果，可作为初始调优的参考起点。

综合来看，对于用户来说， SQ 和 PQ 该如何选择呢？

• 从使用上来说，SQ 的优点是使用方式简单，只需要指定数据类型即可，而 PQ 的使用门槛更高，需要对其原理有较为深刻的理解才能在生产环境中发挥其优势。
• 从性能及开销上来说，SQ 在解码阶段存在额外计算开销，且随维度增加开销更高；PQ 则能在压缩的同时保持接近原始向量的查询性能。
• 从场景上来说，SQ 更适用于各维度近似均匀分布的数据。如遇分布呈高斯或更复杂形态时，标量量化误差增大，则可采用乘积量化方式。

3.2 查询执行路径优化

搜索场景对延迟极为敏感。在千万级数据量与高并发查询的场景下，通常需要将 P99 延迟控制在 200 ms 以内。这对 Doris 的优化器、执行引擎以及索引实现都提出了更高要求。Apache Doris 为此做了大量优化，这一章节对其中涉及到的部分能力做介绍。

3.2.1 虚拟列机制

Apache Doris 的向量索引采用外挂方式。外挂索引便于管理与异步构建，但也带来性能挑战：如何避免重复计算与多余 IO？

ANN 索引在返回行号时，会同步计算出向量距离。执行引擎在 Scan 算子阶段可直接利用该结果进行筛选和排序，无需在读取数据后重新计算。这一过程通过 “虚拟列” 机制自动实现，最终以 Ann Index Only Scan 的形式运行，完全消除了因距离计算而产生的数据读取 I/O。

未应用 Index Only Scan：

应用 Index Only Scan 后：

例如 SELECT l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100;，执行过程将不再触发数据文件 IO。

该优化不仅适用于 TopK 检索，也支持 Range Search、复合检索（Range + TopK）以及与倒排索引结合的混合检索场景，实现了全路径的 Index Only Search。

虚拟列机制并不局限于向量距离计算。对于正则抽取、复杂标量函数等 CPU 密集型表达式，若在同一查询中被多次引用，该机制也能复用中间结果，避免重复计算。以 ClickBench 数据集为例，以下查询统计从 Google 获得最多点击的 20 个网站：

set experimental_enable_virtual_slot_for_cse=true;

SELECT counterid,
       COUNT(*)               AS hit_count,
       COUNT(DISTINCT userid) AS unique_users
FROM   hits
WHERE  ( UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.COM'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.RU'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) LIKE '%GOOGLE%' )
       AND ( LENGTH(regexp_extract(referer, '^https?://([^/]+)', 1)) > 3
              OR regexp_extract(referer, '^https?://([^/]+)', 1) != ''
              OR regexp_extract(referer, '^https?://([^/]+)', 1) IS NOT NULL )
       AND eventdate = '2013-07-15'
GROUP  BY counterid
HAVING hit_count > 100
ORDER  BY hit_count DESC
LIMIT  20;

核心表达式 regexp_extract(referer, '^https?://([^/]+)', 1) 为 CPU 密集型且被多处复用。启用虚拟列优化（set experimental_enable_virtual_slot_for_cse=true;）后，端到端性能提升约 3 倍。

3.2.2 前过滤与谓词下推

在 ANN TopN 检索中，过滤谓词的应用时机是关键的设计权衡：

• 前过滤：在 TopN 之前应用谓词，能阻止无效行进入候选；但需在候选集维护过程中实时剔除不符合条件的行。
• 后过滤：先按相似度取出 TopN，再执行过滤，可能导致最终结果不足 N 条。虽然可通过扩大 N 来补偿，但会额外增加扫描与计算开销。

Apache Doris 在 Scan 算子内通过 row bitmap 实现自然的前过滤语义。每个谓词执行后即时更新 row bitmap。当 TopN 下推到 Scan 时，向索引传递一个基于 row bitmap 的 IDSelector，仅保留满足条件的行作为候选，从源头上避免无效候选进入 TopN。

为进一步提升效率，Doris 还会在扫描前借助分区、分桶、ZoneMap 等轻量元数据进行快速预过滤，并结合倒排索引进行精确的行号定位，多层次缩小候选集，能够显著提升查询性能与资源效率。

3.2.3 全局执行优化

在传统执行路径中，Doris 会对每条 SQL 执行完整优化流程（语法解析、语义分析、RBO、CBO）。这在通用 OLAP 场景必不可少，但在搜索等简单且高度重复的查询模式中会产生明显的额外开销。为此，Doris 进行了全局执行优化，充分发挥索引、过滤等性能。

A. Prepare Statement：

Doris 4.0 扩展了 Prepare Statement，使其不仅支持点查，也适用于包含向量检索在内的所有 SQL 类型。Prepare Statement 的原理是将 SQL 编译与执行分离，模板化检索复用计划缓存，Execute 阶段跳过优化器。查询计划按“标准化 SQL + schema 版本”构建指纹进行缓存，执行阶段校验 schema version，变化则自动失效并重建。对频繁且结构相同仅参数不同的检索，Prepare 能显著降低 FE 侧 CPU 占用与排队等待。

B. Scan 并行度优化：

为提升 ANN TopN 检索性能，Doris 重构了 Scan 并行策略。原策略基于行数划分任务，在高维向量场景下，单个 Segment 的实际行数常远低于划分阈值，导致多个 Segment 被分配至同一任务中串行扫描，制约性能。

为此，Doris 改为严格按 Segment 创建 Scan Task，显著提升了索引检索阶段的并行度。由于 ANN TopN 搜索本身过滤率极高（仅返回 TopN 行），后续回表阶段即使串行执行，对整体吞吐与延迟的影响也微乎其微。

以 SIFT 1M 数据集为例，开启 optimize_index_scan_parallelism=true 后，TopN 查询耗时从 230ms 降至 50ms，效果显著。

此外，4.0 引入动态并行度调整：每轮调度前根据 Scan 线程池压力动态决定可提交的任务数；压力大则减并行、资源空闲则增并行，以在串行与高并发场景间兼顾资源利用率与调度开销。

C. TopN 全局延迟物化：

典型的 ANN TopN 查询可分为两个关键阶段：局部检索与全局归并。在局部检索阶段，Scan 算子通过索引获取每个数据分片（Segment）中的局部 TopN 近似距离；随后在全局归并阶段，由专门的排序节点对所有分片的局部结果进行合并，筛选出最终的全局 TopN。

传统执行流程存在一个显著效率问题：若查询需要返回多列或包含大字段（如长文本），在第一阶段就会读取这些列的全部数据。这不仅会引发大量磁盘 I/O，而且绝大多数被读取的行会在第二阶段的排序竞争中被淘汰，造成计算与 I/O 资源的浪费。

为此，Doris 引入了 “全局 TopN 延迟物化” 优化。该机制将非排序所需列的读取推迟到最终结果确定之后，大幅减少了不必要的 I/O。

优化执行流程示例：

以 SELECT id, l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100; 为例：

1. 局部轻量扫描：每个 Segment 利用 Ann Index Only Scan 结合虚拟列技术，仅计算出局部 Top 100 的距离值（dist）及其对应的行标识（rowid），不读取其他列。
2. 全局排序筛选：系统汇总所有 M 个 Segment 的中间结果（共 100 × M 条候选），对其进行全局排序，从而确定最终的 100 个目标 rowid。
3. 按需延迟物化：最终的 Materialize 算子根据上一步得到的 rowid，精准地到对应的存储位置读取所需列（例如 id）的数据。

通过将完整数据的“物化”步骤推迟到最后，该优化确保了查询前期仅处理轻量的距离与行标识信息，彻底避免了在排序前读取非必要列所带来的 I/O 开销，从而显著提升了整体查询效率。

4. 实战：使用 Apache Doris 搭建企业知识库

企业级知识库是 RAG 的典型落地场景。因此，我们基于 LangChain + Apache Doris 搭建了一个以 Doris 官网文档为语料的最小可用知识库，用于验证 Doris 向量检索的端到端能力。完整示例代码见 GitHub。

（1）环境准备

• LLM：用于对话与答案生成，这里使用 DeepSeek。先在官网注册并创建 API Key，妥善保存，后续用于调用 DeepSeek API。
• 嵌入模型：用于生成检索向量，这里使用 Ollama + bge-m3:latest。bge-m3 是开源的通用检索向量模型，兼顾中英文检索效果，默认输出 1024 维向量，适合知识库检索场景。

（2）建库与建表（方式一：SQL）

CREATE DATABASE doris_rag_test_db;

USE doris_rag_test_db;

CREATE TABLE doris_rag_demo (
  id int NULL,
  content text NULL,
  embedding array<float> NOT NULL,
  INDEX idx_embedding (embedding) USING ANN PROPERTIES("dim" = "1024", "ef_construction" = "40", "index_type" = "hnsw", "max_degree" = "32", "metric_type" = "inner_product")
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"storage_medium" = "hdd",
"storage_format" = "V2",
"inverted_index_storage_format" = "V3",
"light_schema_change" = "true"
);

说明：若计划使用 SDK 一键建表与导入（见 ⑤），本节可省略。

（3）演示语料

示例使用 Apache Doris 官网文档作为语料来源：https://github.com/apache/doris-website

（4）离线文档处理

• 切块（chunking）：采用重叠分割，将长文档切分为段落片段。

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=400, chunk_overlap=100, length_function=len
)
chunks = text_splitter.split_text(text)

• 生成向量（embedding）：对每个片段生成嵌入向量。

from typing import List, Dict
from langchain_community.embeddings import OllamaEmbeddings

embeddings = OllamaEmbeddings(model='bge-m3:latest', base_url='http://localhost:11434')

docs: List[Dict] = []
cur_id = 1
for chunk in chunks:
    docs.append({"id": cur_id, "content": chunk})
    cur_id += 1

contents = [d["content"] for d in docs]
vectors = embeddings.embed_documents(contents)

（5）导入 Doris（方式二：SDK 一键建表与导入）

import pandas as pd
df = pd.DataFrame(
        [
            {
                "id": d["id"],
                "content": d["content"],
                "embedding": vec,
            }
            for d, vec in zip(docs, vectors)
        ])

from doris_vector_search import DorisVectorClient, AuthOptions, IndexOptions

auth = AuthOptions(
    host='localhost',
    query_port=9030,
    http_port=8030,
    user='root',
    password='',
)

client = DorisVectorClient('doris_rag_test_db', auth_options=auth)

index_options = IndexOptions(index_type="hnsw", metric_type="inner_product")
table = client.create_table(
            'doris_rag_demo',
            df,
            index_options=index_options,
        )

说明：若已通过 ② 使用 SQL 创建好表并定义索引，可仅使用 SDK 的导入接口（如 insert/load 等，视 SDK 能力而定）将数据写入既有表。

（6）在线查询过程

向量检索

query = 'Doris 支持哪些存储模型？'
query_vec = embeddings.embed_query(query)
df = (
    table.search(query_vec)
    .limit(5)
    .select(["id", "content"])
    .to_pandas()
)

答案生成

ctx = "\n".join(f"{r['content']}" for _, r in df.iterrows())
prompt =  "以下是检索到的 Doris 文档片段：\n\n{}\n\n请根据上述内容回答：{}".format(ctx, query)

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
            model='deepseek-v3-1-terminus',
            api_key='xxxx',
            base_url='https://xxx',
            temperature=float(1.0))
resp = llm.invoke(prompt)

返回的内容是：

'根据提供的文档内容，Apache Doris 支持以下三种存储模型：\n\n1.  明细模型（Duplicate Key Model）：适用于存储事实表的明细数据。\n2.  主键模型（Unique Key Model）：保证主键的唯一性，相同主键的数据会被覆盖，从而实现行级别的数据更新。\n3.  聚合模型（Aggregate Key Model）：相同键（Key）的数值列（Value）会被自动合并，通过提前聚合来大幅提升查询性能。\n\n此外，文档在“灵活建模”部分还提到，Apache Doris 支持如宽表模型、预聚合模型、星型/雪花模型等建模方式，这些可以看作是建立在上述三种核心存储模型之上的数据组织方法。'

5. 总结

本文从 AI 时代的数据形态演进出发，系统性地介绍了 Apache Doris 在 4.x 版本中引入的向量检索能力，并对其底层实现进行了深入剖析。从 ANN 索引的能力边界，到 FE / BE 架构下的写入、构建与查询路径，再到 SIMD、压缩编码与执行引擎层面的工程优化，Doris 的向量搜索并非简单接入一个索引库，而是围绕 性能三角（召回率 / 查询延迟 / 构建吞吐） 精心设计的系统级方案。未来，我们还会进一步强化，使其成为 AI 时代数据系统智能检索的基石。