4 篇博文 含有标签「RAG 工程化」

今天，我们正式开源 KnowFlow Analytics。

它是一套面向 AI Agent 与数据应用的语义层和受治理查询引擎，采用 Apache License 2.0。代码已经发布在 GitHub，也可以直接运行 Docker 镜像 knowflowai/analytics:v0.0.1。

我们做这件事，不是因为市场上还缺一个 Text-to-SQL Demo。恰恰相反，今天让大模型根据数据库 Schema 写出一条能执行的 SQL，已经不难。

真正难的是： 当问数进入真实业务，如何保证“销售额”每次都指向同一个指标，Join 不会让金额翻倍，Agent、报表和 API 不会各自使用一套口径，以及模型不确定时不会悄悄返回一个看起来合理的错误数字。

这些问题靠继续堆 Prompt 和 Few-shot 很难根治。于是我们选择把最难、也最值得长期维护的部分，从模型上下文里拿出来，做成语义层。

导语：检索增强生成（RAG）技术发展至今，行业逐渐触碰到一个核心矛盾——"检索到了，但没读懂"。KnowFlow v2.3.4 给出了一个不同的答案：让 AI 像人类专家一样，先定位、再精读、再作答。

一个真实的场景​

某制造业客户的质量工程师，需要从一份 200 页的国标文件中找到"涂层体系的环境适应性要求"。他在企业知识库里输入问题，系统返回了 5 段文本片段——有的来自"术语定义"，有的来自"检测方法"，有的确实来自"性能要求"章节，但只截取了半段话。

前言​

为什么需要 KnowEval？​

在过去一年与众多企业客户的交流中，我们发现一个普遍的痛点：RAG 系统上线后，如何量化评估问答质量？如何系统化提升检索效果？如何在多个优化方案中选择最优解？

很多团队花费大量时间调试 RAG 系统，但往往凭感觉调参，缺乏数据支撑。A/B 测试需要人工逐条对比，效率低下。更关键的是，没有一套标准化的评测体系，就无法形成可持续优化的闭环。

📋 项目背景​

在 KnowFlow 内部交流群的同学都知道，近期我们团队在做一款基于视觉模型的多模态 RAG 系统。经过 2 周左右密集开发，我们进行了全方位的测试，在群内公开召集难啃的文档，现在整体上对于多模态 RAG 有了更加深入的认识。