同样是办公软件，中国与美国市场的差异，可谓天差地别：
在中国，只要一个飞书、钉钉，或者企业微信，就能解决企业从消息沟通、会议、写文档、做表格、做PPT、做会议纪要等多重需求。
而在美国，往往不同功能对应不同软件。想要检索一个历史文档中的信息，或者会议中的细节，有时候，甚至需要来回在四五个软件之间跳转，繁琐且低效。
那么，怎么高效地找到散落不同软件中的精准信息，降低信息整合的成本？针对这个需求，2021年，Read AI 就这样诞生了。
更值得一提的是，仅仅依靠会议记录，以及不同软件之间的信息打通与检索，Read AI分别在2024年的4月与10月完成了金额高达2100万美金与5000万美金的A轮与B轮融资，公司估值达到4.5亿美元。
与此同时，其注册用户、活跃用户和月度经常性收入（MRR）也在近两年实现成倍增长；其中，每月活跃用户增加了 12 倍，40 多个国家/地区的测量会议增加了 15 倍。
那么，Read AI 是如何做到的？指数级增长背后，为什么说向量数据库成为了其核心转型动力支撑？
01 大模型时代的会议分析软件如何转型？事实上，在成立初期，Read AI 一度走了一小段弯路：那时，公司产品的核心功能还是虚拟会议分析仪表盘（Dashboard），为管理层提供会议的实时情绪与参与度监控功能。
但很快，就有专业论文指出，这个功能就被指出隐含算法偏见，比如默认黑人的负面情绪更多等等，而招致大规模的吐槽与批评。
此外，Read AI也很快意识到，一个只能帮助管理层细化管理，却不能实际帮助执行层解决问题的软件，注定无法走得长远。
那么，如何让会议软件，帮助更多打工人提升工作的效率与体验呢？
Read AI 选择扩充其产品矩阵：日历同步、CRM同步、邮件汇总、即时通讯汇总、视频会议汇总功能依次上线，基于以上数据，Read AI又推出了会议总结、会议分析、多平台信息检索等功能，转型为综合会议助手软件。当前，其功能主要包括以下几个模块：
模块一：Meetings
Assistant（会议助手）：自动加入 Zoom、Meet、Teams 等会议，实时收集发言、注意力、情感、发言频率等互动数据，自动记录每个发言人的“语气”和“情绪走势”（这是其核心功能，也是其争议来源）。
Real-Time Meeting Notes（实时笔记）：让与会者在会议中实时可见转录与要点，自动整理对话结构、重要讨论片段。
Summary & Transcription（总结与转录）：AI 自动生成会议摘要、关键词、待办事项、提问点，支持20+ 语言自动转录支持，并提供高质量文本提取，附带原始引用时间点。
Playback（会议回放）：回顾整场会议，或只看“关键时刻”，支持高亮片段提取（Highlight Reel）。
Meeting Reports（会议报告）：自动生成结构化 PDF／HTML 会议报告，包含参与度分析（如谁主导、谁中断他人、沉默时长）可分享或上传至 Notion、Slack、CRM 等（同样有一定争议）。
模块二：Messaging
Readouts for Messaging：为 Slack / Teams 聊天生成摘要和行动建议，可识别群组对话中的主题脉络，Free版本 支持基础功能；Pro/Enterprise 支持多线程追踪，消息上下文可关联会议纪要，提升知识连贯性。
模块三：Email
Readouts for Email：为 Gmail / Outlook 邮件生成摘要和意图分析，标记邮件中“需回复内容”、“待处理事项”与情绪关键词，目前主打 Gmail，Outlook 已进入测试版。
Read AI for Gmail（插件）：Chrome 插件形式运行，自动分析当前邮箱内容，可结合会议纪要，形成“跨渠道对话线程”，已支持英文邮件；多语言版本待发布，所有 Gmail 用户可试用，Pro 提供自动批量分析。
模块四：Enterprise
Workspaces（工作空间）：支持组织内会议资料的共享与权限管理，可按项目、团队分类组织会议与报告，提供 Slack／Notion／Salesforce 等深度集成。
可以看到，在Read AI 的功能模块设计中，通过大模型以及更广泛的生态连接，Read AI不仅产品矩阵进一步壮大
与此同时，还通过不同产品的刚需程度，设计了不同的定价梯度，从free用于引流到Pro、enterprise用于做大营收，完成了其商业化能力的进一步壮大。
另外，Read AI 的一个默认使用规则是，用户只要一次使用，就会默认没有打扰的帮你出现在所有会上，帮助完成后续的所有内容同步与汇总。这也成为了其不断做大、高客户留存率的重要功能亮点。
02 完成高质量的产品功能升级，有多少难关过去Read AI 的作用，可以概括为老板的眼睛，员工的耳朵，只能做单纯的专注度分析以及会议内容转录。
如今通过大模型与向量数据库的加持，Read AI 给眼睛与耳朵加上了大脑甚至嘴巴，不仅能理解、检索用户提供的数据，还能根据数据提出针对性建议。
但这并不容易，因为用户的数据来源极度分散、格式千奇百怪，比如在美国一个用户今天的对话，可能分散在这些地方：
Zoom 上的 45 分钟销售 Demo
Slack 上的几轮快速反馈
Salesforce 里一个模糊的备注
Gmail 发出的报价邮件
还有一条客户刚刚在 Notion 留的异议
这些数据全是非结构化的、语境化的、语言风格混乱的，而且还是跨平台数据。
此外，用户要的不是原话，而是理解：他想知道，客户是不是在动摇；这场会议有没有人掉线；销售有没有机会；哪里是风险点；哪里该行动。
更别说，用户还要求系统在 百万租户、亿级数据、千级 QPS”的前提下，把响应延迟控制在 20–50ms。
更通俗来说，Read AI 需要的是一个能支持跨模态的企业级语义检索方案，其指标可以量化为：
是否能横向扩展？用户上百万，向量量级过亿。
是否能支持混合搜索？不能光看相似度，还要支持复杂过滤。
是否低延迟？20–50ms，不接受卡顿。
是否支持租户隔离？一套系统跑全球业务。
是否易用？PoC、部署、维护，团队能快速上手。
确定了以上指标后，Read AI 尝试过多种方案：自建索引？太重，维护成本爆炸。Pinecone？过滤弱，查询灵活性不足。FAISS？别说多租户，连复杂条件都跑不动。
直到遇到了所有条件全都满足，甚至超额完成的 Milvus。
03 架构重构：用 Milvus 建一个“语义大脑”接入milvus之后，Read AI 决定重新做一次底层架构。核心思路是——不再把会议、邮件、对话这些内容当作孤立存在的文本，而是把它们转化成完整的“故事”。
第一步，所有原始数据（无论来自 Slack、Zoom、Salesforce 还是邮箱）都会经过一个“嵌入 + 叙述”处理层：
转化为带有情感、语气、行为信号的语义表示
提炼为结构化、可检索的“叙述事件”（narrative threads）
然后，统一存入 Milvus 作为核心向量数据库。
这一步，Milvus 不只是“存”。它配合结构化元数据，支持“混合搜索”——你可以查：
张三最近和客户一对一里的“正面反馈”
某个季度内团队收到的“负面倾向”评论
哪场会议参与度最低？
尽管这些复杂条件组合，对延迟的要求极高。但“Milvus 的元数据过滤能力，是我们把响应控制在 20ms–50ms 的关键。”——Read AI 联合创始人兼 CTO
更重要的是，Milvus 原生支持多租户，Read AI 可以用一个集群服务数百万用户，避免了“每个客户都开一个索引”的灾难。
在 PoC 阶段，Milvus 团队还提供了调优建议与实时支持，几乎帮 Read AI 把整个上线周期缩短了一半。
Milvus 上线后，Read AI 还推出了 Search Copilot新功能，用户可以从海量对话中，秒找上下文。
实际效果来看，帮助Read AI 完成了：
检索速度提升 5 倍
即使复杂过滤，也能稳定在 20–50ms
搜索命中率明显提升
效率之外，真正改变的是业务形态。
从前，用户要自己提问，才能得到回应。现在，Read AI 可以在用户还没开口之前，就主动提醒：“你漏了这个跟进”“客户好像冷下来了”“这场会情绪偏负面”。
而基于这些免费的洞察：免费用户会因即时洞察留下来，企业客户因深度搜索和上下文积累产生粘性；两者互为因果，最终带动更多的高价值转化。
走完整个流程后，Read AI 团队总结出三个必须记住的实践：
结构化叙述 + 嵌入表达 = 更强的 LLM 输出能力 单靠 embedding 是不够的，必须要有抽象层结构。
就算用元数据过滤，也必须跑得快 有时候，用户相比关心你查得准不准，更关心你查的快不快。
消费级规模下，多租户能力是刚需，不是加分项 否则成本和复杂度压垮整个平台。
展望未来，Read AI 计划与milvus进一步加深合作，主要包括两方面：
引入 Vector Lake 架构 把不要求实时响应的查询（比如归档分析）迁到对象存储，进一步降低成本。
识别知识缺口 + 主动提醒 帮助用户识别自己还要补什么信息。
而Read AI的终极目标则是让 Read AI 成为一个 永远在线、永不遗忘、能自主行动的 AI 企业平台。让企业真正实现数据资产化，不仅全盘洞悉今天发生了什么，更能知道接下来应该去做什么。
