同樣是辦公軟件，中國與美國市場的差異，可謂天差地別：
在中國，只要一個飛書、釘釘，或者企業微信，就能解決企業從消息溝通、會議、寫文檔、做表格、做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 等會議，實時收集發言、注意力、情感、發言頻率等互動數據，自動記錄每個發言人的“語氣”和“情緒走勢&rd
{FWD_PAGER}quo;（這是其核心功能，也是其爭議來源）。
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用
{FWD_PAGER}于做大營收，完成了其商業化能力的進一步壯大。
另外，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 決定重新做一
{FWD_PAGER}次底層架構。核心思路是——不再把會議、郵件、對話這些內容當作孤立存在的文本，而是把它們轉化成完整的“故事”。
第一步，所有原始數據（無論來自 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 可以在用戶還沒開口之前，就主動提醒：“你漏了這個跟進”“客戶好像冷下來了”“這場會情緒偏負面”。
而基于這些免費的洞察：免費用戶會因即時洞察留下來，企業
{FWD_PAGER}客戶因深度搜索和上下文積累產生粘性；兩者互為因果，最終帶動更多的高價值轉化。
尾聲：工程實踐的三條經驗
走完整個流程后，Read AI 團隊總結出三個必須記住的實踐：
結構化敘述 + 嵌入表達 = 更強的 LLM 輸出能力 單靠 embedding 是不夠的，必須要有抽象層結構。
就算用元數據過濾，也必須跑得快 有時候，用戶相比關心你查得準不準，更關心你查的快不快。
消費級規模下，多租戶能力是剛需，不是加分項 否則成本和復雜度壓垮整個平臺。
展望未來，Read AI 計劃與milvus進一步加深合作，主要包括兩方面：
引入 Vector Lake 架構 把不要求實時響應的查詢（比如歸檔分析）遷到對象存儲，進一步降低成本。
識別知識缺口 + 主動提醒 幫助用戶識別自己還要補什么信息。
而Read AI的終極目標則是讓 Read AI 成為一個 永遠在線、永不遺忘、能自主行動的 AI 企業平臺。讓企業真正實現數據資產化，不僅全盤洞悉今天發生了什么，更能知道接下來應該去做什么。（軟件開發，小程序開發）
原文鏈接：https://blog.csdn.net/weixin_44839084/article/details/149185139