Kotaemon如何实现多条件组合检索？语法说明
在企业级知识管理日益复杂的今天，一个常见的挑战是：用户面对海量文档、会话记录和元数据时，如何快速精准地找到所需信息？简单的关键词搜索早已不够用——我们不再满足于“包含某个词”，而是需要知道“谁在什么时候、以什么类型提交了与某主题相关的报告”。
Kotaemon 正是在这一背景下构建的智能助手系统。它融合大语言模型的理解能力与结构化查询的精确性，支持对非结构化内容进行深度过滤。其中，多条件组合检索是其核心竞争力之一，让用户可以用类似自然语言的方式表达复杂筛选逻辑。
从一句话到一场精准搜索：背后发生了什么？
设想你输入这样一句请求：
“帮我找上周张伟提交的关于财务分析的报告。”
这看似简单的一句话，实则蕴含多个维度的信息：
-作者：张伟
-时间范围：“上周” → 可转化为日期区间
-主题关键词：“财务分析”
-文档类型或标签：报告
Kotaemon 并不会直接把这个句子丢给向量数据库去模糊匹配。相反，它会先通过 NLU 模块提取出这些结构化条件，然后生成一条精确的查询语句：
author:"张伟" AND tag:report AND title:"财务分析" AND created_at >= "2024-05-27"这条语句不是随意拼凑的字符串，而是一种经过严格定义的语言——我们称之为FilterDSL。
FilterDSL：让机器听懂“并且”、“或者”、“不是”
FilterDSL 是一种轻量级领域特定语言（DSL），专为嵌入式条件检索设计。它的目标很明确：用最少的语法代价，表达最丰富的逻辑关系。
它长什么样？
以下是一些典型的 FilterDSL 表达示例：
| 意图 | 对应 DSL |
|---|---|
| 找标题含“年度报告”的文档 | title:"年度报告" |
| 标签为 report 且作者为 Bob | tag:report AND author:Bob |
| 非草稿状态 + 修改时间较新 | status != draft AND modified_at > "2024-05-01" |
| 来自内部源或 API 的文档 | (source:internal OR source:api) AND type:document |
| 排除测试用户的数据 | NOT user:test_* |
你会发现，这种语法接近 SQL，但更简洁；又像自然语言，却无歧义。它由三部分构成：字段名、操作符和值，并通过逻辑连接词组合成树状结构。
支持哪些操作？
逻辑运算
AND/OR：并列或任选条件NOT：排除某些情况()：控制优先级，比如(A OR B) AND C
比较操作符
| 类型 | 支持的操作符 |
|---|---|
| 字符串相等 | =,!=,:（同义） |
| 数值/日期比较 | >,<,>=,<= |
| 模糊匹配（可选） | ~=（正则）、LIKE |
值的书写规范
- 字符串必须用双引号包围：
"财务分析" - 数字直接写：
42,3.14 - 时间建议使用 ISO8601 格式：
"2024-06-01T00:00:00Z"
字段引用方式
- 简单字段：
author,tag - 嵌套路径：
metadata.source.url——适用于 JSON 结构数据
⚠️ 小贴士：未加引号的字符串若含空格或特殊字符（如
-,/），可能导致解析失败。强烈建议始终使用双引号包裹字符串值。
解析流程：从文本到可执行查询的四步走
当你输入一段 FilterDSL 字符串时，系统并不会立刻去查数据库。它要经历一个严谨的解析过程，确保语义正确、安全可控。
第一步：词法分析（Lexing）
原始字符串被拆解成一个个“token”——也就是最小语义单元。例如：
author:"张伟" AND created_at >= "2024-05-01"会被切分为：
[IDENT:author] [STRING:"张伟"] [OP:AND] [IDENT:created_at] [OP:>=] [STRING:"2024-05-01"]这个阶段就像把一句话切成词语，便于后续理解。
第二步：语法分析（Parsing）
基于预定义文法，系统将 token 序列构建成一棵抽象语法树（AST）。例如上面的例子会形成如下结构：
graph TD A[AND] --> B[FieldEq author="张伟"] A --> C[FieldGte created_at="2024-05-01"]这棵树清晰表达了逻辑层级：两个条件通过AND连接，各自对应一个字段比较节点。
括号的存在会影响树的形状。比如：
tag:report OR tag:memo AND status:final实际含义是tag:report OR (tag:memo AND status:final)，因为AND优先级更高。如果你想改成(tag:report OR tag:memo) AND status:final，就必须显式加括号。
第三步：语义绑定
AST 中的字段名只是字符串，还不能直接用于查询。此时系统会检查这些字段是否存在于当前数据模型中，并验证类型一致性。
比如你写了created_at = "pending"，虽然语法合法，但created_at是日期字段，值却是字符串"pending"，这就属于类型不匹配，会在这一阶段报错。
同时，系统还会应用字段白名单机制，防止用户访问敏感字段（如password_hash）。只有被列入允许列表的字段才能参与查询。
第四步：执行计划生成
最后一步是“翻译”。根据当前使用的底层存储引擎（PostgreSQL、MongoDB 或 Elasticsearch），Query Planner 将 AST 编译为对应的原生查询格式。
举个例子：
author:"Alice" AND (tag:report OR tag:memo)在不同后端的表现形式如下：
转换为 MongoDB 查询对象（MQL）
{ "author": "Alice", "$or": [ { "tag": "report" }, { "tag": "memo" } ] }转换为 PostgreSQL SQL 片段
WHERE author = 'Alice' AND (tag = 'report' OR tag = 'memo')转换为 Elasticsearch Query DSL
{ "bool": { "must": [ { "match": { "author": "Alice" } }, { "bool": { "should": [ { "term": { "tag": "report" } }, { "term": { "tag": "memo" } } ] } } ] } }这种“一次编写，多端执行”的能力，正是 Kotaemon 实现存储解耦的关键所在。
多条件组合的真实威力：不只是“找文件”
FilterDSL 不仅是一个技术组件，更是解决实际业务问题的利器。以下是几个典型场景：
场景一：权限隔离下的默认过滤
普通用户不应该看到他人私有文档。系统可以在所有查询前自动注入一个隐式条件：
visibility:public OR owner:${current_user}管理员则能看到更多，但仍受限于团队边界：
team:${user_team}这种方式无需改动前端代码，就能实现细粒度的数据可见性控制。
场景二：动态时间表达式
用户说“最近三天修改过的高优任务”，系统可以将其转换为：
priority:high AND modified_at >= now()-3d这里的now()-3d是一种扩展语法，在解析时会被替换为具体的 ISO 时间戳。类似的还有today,start_of_month等便捷表达。
场景三：正则匹配辅助模糊查找
有些命名有规律，比如日志来源可能是system/auto/gen-20240601。这时可以用正则：
NOT source~=system/auto/.*表示排除所有以system/auto/开头的自动生成条目。
场景四：结合语义检索的混合查询
真正强大的地方在于——FilterDSL 并不取代向量检索，而是与之协同工作。
流程如下：
flowchart LR A[用户输入] --> B{是否DSL?} B -- 是 --> C[解析为FilterDSL] B -- 否 --> D[NLU提取条件] D --> C C --> E[Query Planner] E --> F[结构化DB查询] E --> G[向量DB相似度检索] F & G --> H[结果融合排序] H --> I[返回最终结果]也就是说，你可以既用 FilterDSL 锁定“作者+时间+类型”，又依赖向量库找出“语义上相关”的内容。两者取交集或加权合并，极大提升召回准确率。
性能与安全：别让灵活性变成负担
功能强大不代表可以无限制使用。为了保障系统稳定与安全，Kotaemon 在运行时设置了多项约束：
| 参数 | 默认值 | 说明 |
|---|---|---|
| 最大嵌套层级 | 10 | 防止深层括号导致栈溢出 |
| 单次查询超时 | 5s | 避免慢查询阻塞服务 |
| 字段白名单 | 显式配置 | 禁止访问未授权字段 |
| 关键字段索引 | 强制建立 | 如 author, created_at, tag |
此外，还有一些优化实践值得推荐：
- 高频字段建索引：对
author,tag,created_at等常用字段建立数据库索引，能将查询速度从秒级降到毫秒级。 - 启用结果缓存：对于仪表盘类固定查询（如“本月上传统计”），可缓存结果减少重复计算。
- 语法容错处理：支持忽略大小写、自动补全常见字段名（如
auther → author），提升用户体验。 - 查询审计日志：记录所有复杂查询，用于后期行为分析和性能调优。
未来方向：当 LLM 开始“主动构造”查询
目前，FilterDSL 主要由用户手动编写或由 NLU 模块辅助生成。但随着大模型能力增强，未来的趋势是让 LLM 自主推理并构造完整查询。
想象一下，你说一句：
“看看去年李工写的那个项目总结，我记得里面有预算表格。”
系统不需要你指明字段，就能推断出：
- “李工” →author:"李工"
- “去年” →created_at >= "2023-01-01" AND created_at < "2024-01-01"
- “项目总结” → 可能是tag:summary OR title~=项目.*总结
- “预算表格” → 向量语义匹配重点段落
然后自动生成完整的 FilterDSL 并执行。整个过程对用户完全透明，真正做到“无感检索”。
这不仅是语法的进步，更是交互范式的跃迁——从“我告诉你怎么查”，变为“你帮我找到我想找的”。
写在最后
多条件组合检索看似只是一个查询功能，实则是连接人类意图与机器数据的核心桥梁。Kotaemon 通过 FilterDSL 实现了表达力与安全性的平衡，通过 Query Planner 实现了灵活性与兼容性的统一。
这项能力已在 v1.3+ 版本中稳定上线，广泛应用于企业知识库、客服工单系统、研发文档中心等场景。它不仅提升了信息获取效率，也为更高级的智能代理（Agent）奠定了基础。
当我们谈论“智能助手”时，真正的智能不在于回答得多快，而在于能否准确理解“我到底想找什么”。而 FilterDSL，正是让机器学会“听重点”的第一步。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
