Kotaemon开发者访谈：我们为什么要造这个轮子？

Kotaemon开发者访谈：我们为什么要造这个轮子？

在企业纷纷拥抱大模型的今天，一个看似简单的问题却反复浮现：为什么很多团队不直接用现成的RAG库或对话平台，反而选择从头构建自己的框架？答案或许藏在一个真实的项目崩溃现场——某金融客户部署的智能客服上线三天后频繁“失忆”，用户刚问完“去年利润多少”，紧接着追问“同比增长率”时，系统竟完全忘记上下文，还反问“您指的是哪个公司？”更糟的是，它开始编造财报数据，且无法追溯来源。

这不是个例。随着LLM进入生产环境，我们发现：越聪明的模型，越需要严格的工程约束。Kotaemon 的诞生，正是为了回答那个朴素但关键的问题：如何让AI既具备强大能力，又足够可靠、可控、可维护？

当“检索增强生成”不再只是拼接上下文

提到RAG，很多人第一反应是“把文档扔进向量库，查完丢给大模型”。但这远远不够。真正的挑战在于：检索什么、怎么切、何时更新、出错怎么办。

比如，一份PDF财报被切成500字符的片段后，关键数据可能恰好被截断在两个chunk之间。当用户问“净利润增长率”，系统检索到前一段有“同比增长”，后一段有“23.7%”，却因距离太远未能同时召回——结果模型只能靠猜。这正是所谓“幻觉”的温床。

Kotaemon 的做法是引入语义感知切片器（Semantic Chunker），它不会机械地按字数切分，而是识别段落边界、标题结构甚至表格位置，确保每个chunk是一个完整的语义单元。我们还支持动态重排序（re-ranking），先用轻量级模型粗筛Top-50，再用交叉编码器精排Top-5，显著提升关键信息命中率。

更重要的是，我们把整个流程变成可审计的数据流。每次检索都会记录原始query、嵌入向量、相似度分数、返回的chunk及其元数据（如文件名、页码）。这意味着你可以回溯：“为什么系统认为这份合同与‘违约金’相关？”——不再是黑盒决策。

下面这段代码展示了核心检索逻辑的简化版本，实际系统中还会加入缓存、降级、超时控制等机制：

from sentence_transformers import SentenceTransformer import faiss import numpy as np # 初始化嵌入模型和向量索引 embedding_model = SentenceTransformer('BAAI/bge-small-en-v1.5') index = faiss.IndexFlatIP(384) # 使用内积衡量相似度（需归一化） # 假设已有文档集合 docs = ["doc1...", "doc2...", ...] docs = ["公司成立时间是2020年", "总部位于上海浦东", "主营业务为AI软件"] doc_embeddings = embedding_model.encode(docs) doc_embeddings = doc_embeddings / np.linalg.norm(doc_embeddings, axis=1, keepdims=True) # 归一化 index.add(np.array(doc_embeddings)) # 用户查询 query = "公司的成立时间？" query_embedding = embedding_model.encode([query]) query_embedding = query_embedding / np.linalg.norm(query_embedding) # 归一化 # 检索最相似的文档 D, I = index.search(query_embedding, k=1) retrieved_doc = docs[I[0][0]] print("检索结果:", retrieved_doc)

注意这里使用了余弦相似度（通过归一化+内积实现），比欧氏距离更适合文本匹配。而在真实场景中，我们会结合关键词召回（BM25）与向量检索做混合搜索（Hybrid Search），避免纯语义匹配漏掉关键术语。

多轮对话的本质是状态机，不是记忆堆叠

很多对话系统所谓的“上下文记忆”，不过是把历史消息一股脑塞进prompt。这种做法在超过几轮后就会失控：token爆炸、关键信息被稀释、意图混淆。真正复杂的业务交互，比如办理一笔跨境汇款，涉及金额、币种、收款人、合规条款等多个槽位，必须有明确的状态管理。

Kotaemon 的状态管理器不是简单的变量存储，而是一个事件驱动的状态机引擎。每个对话节点都有明确定义的输入条件、动作和输出事件。例如，在“订单查询”流程中：

• 初始状态：等待用户输入订单号；
• 若用户提供手机号，则触发“通过用户身份查找订单”动作；
• 若连续两次未识别有效输入，则进入“澄清引导”子状态；
• 完成查询后自动发布order_fetched事件，通知下游组件更新UI或发送邮件。

这种设计让我们能清晰定义“中断恢复”逻辑。用户中途说“算了我不想查了”，系统不会傻傻继续追问验证码，而是正确跳转到闲聊模式，并标记当前任务已放弃。

以下是简化版状态机的核心结构：

class DialogueState: def __init__(self): self.slots = {} self.current_intent = None self.turn_count = 0 self.context_stack = [] # 支持嵌套任务（如主流程中插入帮助请求） self.last_active = time.time() def update(self, user_input: str, intent: str, extracted_slots: dict): self.turn_count += 1 self.current_intent = intent self.slots.update(extracted_slots) self.last_active = time.time() def is_complete(self) -> bool: required_slots = ['departure', 'destination', 'date'] return all(slot in self.slots for slot in required_slots) def push_context(self, context_type: str): self.context_stack.append({ 'type': context_type, 'state': self.slots.copy(), 'timestamp': time.time() }) def pop_context(self): if self.context_stack: prev = self.context_stack.pop() self.slots = prev['state'] return True return False

这套机制支持超时清理（防止内存泄漏）、上下文回滚（处理话题切换）、多任务并行（如一边订票一边查天气），而这正是普通聊天机器人难以企及的能力。

工具调用：让AI真正“动手”做事

如果说RAG解决了“知道什么”，状态管理解决了“记得什么”，那么工具调用就是解决“能做什么”。没有行动力的AI，终究只是个高级问答机。

在Kotaemon中，工具调用不是附加功能，而是架构的一等公民。我们采用声明式注册方式，开发者只需提供函数签名和描述，系统自动将其封装为LLM可理解的schema。例如：

def get_weather(location: str, unit: str = "celsius") -> dict: """ 获取指定城市的实时天气 Args: location: 城市名称 unit: 温度单位（celsius/fahrenheit） Returns: 包含温度、湿度、风速的JSON """ # 实际调用第三方API... return { "temp": 20, "humidity": 60, "wind_speed": 3.5, "unit": "°C" } # 注册为可用工具 tool_registry.register( func=get_weather, description="获取某个城市的当前天气情况", params={ "location": {"type": "string", "description": "城市名称"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, required=["location"] )

当LLM输出如下结构时，运行时会自动解析并执行：

{ "function_call": { "name": "get_weather", "arguments": {"location": "杭州", "unit": "celsius"} } }

关键是，我们加入了类型校验、参数补全、失败重试策略。如果用户说“看看杭州天气”，但模型漏传location，系统不会直接报错，而是触发“参数缺失”事件，生成追问：“您想查询哪个城市的天气？”

此外，所有工具调用都经过统一的日志管道，记录输入、输出、耗时、成功率。这对后续分析异常行为至关重要。比如某天发现“支付确认”接口调用量激增，结合日志就能快速判断是正常流量还是潜在攻击。

架构不是图纸，是演进路径的选择

回头看Kotaemon的整体架构，它并非一开始就如此复杂。早期版本只是一个简单的Flask服务加FAISS索引。但随着接入场景增多——从客服问答到运维自动化，再到数据分析助手——我们逐渐意识到：通用性和可靠性必须通过分层解耦来实现。

现在的架构像一辆模块化卡车：底层是稳定的数据引擎（RAG + 存储），中间是灵活的调度中枢（状态机 + 工具总线），上层是多样化的接入方式（Web UI、API、Slack插件）。每一层都可以独立升级，不影响整体运行。

+---------------------+ | 用户接口层 | | (Web UI / API) | +----------+----------+ | +----------v----------+ | 对话管理层 | | - 状态追踪 | | - 意图识别 | | - 流程控制 | +----------+----------+ | +----------v----------+ | 工具与插件层 | | - 外部API调用 | | - 自定义业务逻辑 | | - 插件热加载 | +----------+----------+ | +----------v----------+ | RAG核心引擎 | | - 文本嵌入 | | - 向量检索 | | - 上下文融合 | | - 答案生成 | +----------+----------+ | +----------v----------+ | 数据存储层 | | - 向量数据库 | | - 元数据管理 | | - 日志与监控 | +---------------------+

这种设计带来了实实在在的好处。某政务客户需要对接十几个委办局系统，每个部门有自己的认证方式和数据格式。借助插件机制，他们为每个接口开发了一个独立插件，由Kotaemon统一调度，避免了“一个项目一套代码”的重复建设。

我们到底在造什么样的轮子？

有人说，开源社区已有LangChain、LlamaIndex等成熟框架，为何还要再造一个？这个问题我们也问过自己无数次。

直到有一次，一位开发者告诉我们：“我用现有框架做了个Demo很惊艳，但一上线就崩——响应慢、状态丢失、日志混乱，根本没法定位问题。” 这句话点醒了我们：研究级框架追求功能丰富，而生产级系统追求可维护性。

Kotaemon 不追求成为“全能选手”，而是专注于几个核心目标：
-每一次实验都能复现：相同的输入+配置 → 相同的输出链路；
-每一个错误都能追溯：从用户提问到最终回答，全程留痕；
-每一个组件都能替换：你可以换掉默认的嵌入模型、检索器甚至LLM，而不影响其他部分；
-每一次迭代都可灰度：新版本先对1%流量生效，验证无误后再逐步扩大。

这些听起来像是基础设施的“基本功”，但在AI热潮中常常被忽视。而正是这些“笨功夫”，决定了一个系统能否扛住真实世界的考验。

所以，当我们说“重新造轮子”，其实是在回答另一个问题：你愿意让你的企业知识、客户服务、核心流程，依赖在一个不可控、不可修、不可审的黑盒之上吗？

Kotaemon 的答案很明确：智能不该以牺牲工程严谨为代价。它也许不像某些Demo那样炫酷，但它能在凌晨三点稳定运行，在审计时提供完整证据链，在需求变更时快速适配——这才是企业真正需要的AI。

这条路不容易，但我们相信，只有亲手打造的轮子，才知道它该往哪里转。