北京
「/search budget」——三秒后，18,000封邮件里相关的预算讨论按优先级排好。再补一句「John当时怎么说的？」，七秒后得到带出处的完整回答。全程在我的笔记本上跑，没调任何API。
这是Llamail邮件Agent的第二篇。第一篇讲了整体架构：Gmail接Telegram，n8n调度，FastAPI串起llama.cpp、SQLite和ChromaDB。这次拆底层——/search和/ask到底怎么工作的。
纯语义搜索的问题很典型：它懂「预算」的意思，但你要找「john@acme.com发的发票编号INV-2024-003」，它可能返回一堆 vaguely 关于发票的邮件，偏偏漏掉那封。纯关键词搜索反过来：FTS5对精确词项很强，但「budget」「financials」「spending plan」「Q2 numbers」在它眼里是四个毫不相关的词。
我的解法：每份查询同时进ChromaDB做语义检索、进SQLite FTS5做关键词检索，再用一个极小的加权函数合并结果。思路接近RRF（Reciprocal Rank Fusion），但我做的是归一化分数合并而非倒数排名，实现更简单。18,000+邮件的邮箱里，搜索约3秒，完整RAG问答约7秒。
从Telegram端看，/search只走检索流程；/ask同样检索，但要把Top结果塞进受控上下文，再调一轮LLM。两者都不花哨，能用的关键在于检索本身是混合的——语义负责「意思」，关键词负责「精确」。
两种单模式搜索的失败模式都很 predictable。语义搜索会把邮件地址、发票号、项目代码这些关键标识「模糊」掉；关键词搜索则对概念变体和高层问题束手无策，除非原文原句躺在邮箱里。下一篇会展开讲RRF的完整实现。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
