wmxpop

别急着上智能体,有些问题一个对话框就够了

  •  
  •   wmxpop · 4h 21m ago · 257 views

    今年我们给一家专业类图书出版社做知识库应用。上线前搞了场内测,开完我感觉,这事我们做复杂了。

    人家要的就是个“对话框” 需求其实评审会上就说清楚了,朴素到有点不像需求:能不能在网页上放个对话框,让人直接问问题。

    就是读者、编辑、律师打开网页,输一句”夫妻共同债务怎么认定”,底下给一段带出处的回答。比搜索框多会说话。

    我们最后交出去的东西技术上高级得多。535 本正版法学图书做了结构化检索,以 API 和 MCP 的形式开放,各种 AI 智能体都能调。

    但要用上它,得走完这几步:先下载一个桌面客户端,网页端不支持;然后在客户端里配置知识库连接;再配置 API Key;然后才能提问。

    内测会上,出版社同事的原话:

    “第一步是要装那个本地化的智能体的这个服务,咱们才能用这个平台。网页端应该是用不了是吧?” “对,网页端用不了。” 现场还有一句更实在的:”关注点一个是这个沃克巴蒂什么的,没用过。”

    后来我们才弄清楚人是怎么流失的。跟产品能力没关系,卡在门口:出版社里几乎没人用笔记本,都是台式机,C 盘还紧。有人压根没装成。

    我们是从自己会做什么出发的,没从用户已经打开的那个窗口出发。

    三种工具,成本差一个量级 这类问题我后来重新理了一遍。同样是解决问题,有三个层次,成本差得挺远。

    能写代码的,就别上模型 很多被包装成”AI 问题”的,本质是查表比对。

    还是这家出版社。编辑抱怨最多的是参考文献核验。一篇书稿一二十条参考文献,要逐条核对书名、作者、出版社、年份。现在靠什么?学生一条一条去知网、超星上人工查。

    这事需要智能体吗。不需要,连大模型都不需要。

    拿这 20 条书目信息,去 535 本的书目库里查一遍,比一下出版社和年份,返回”匹配 / 不匹配 / 未收录”。二十行脚本的事,或者做成网页上的一个表单,粘贴进去点一下出结果。

    关键是它确定性,对就是对,错就是错,不会编。一次五分钱。

    换成智能体来做,用户先装客户端、配 Key,然后问一个会说”我查了一下,这本书好像是……”的模型。一个要精确答案的活,交给了最不擅长精确的东西。

    所以,这件事有标准答案、答案还能被验证,就用代码。

    对话框够用的,别做成智能体 如果确实是自然语言问答,但只有一轮,问一句答一句,那就放个对话框。

    用户输入问题,后台检索片段,模型组织成一段带出处的回答。不用装任何东西,打开就能用。

    这才是那家出版社真正想要的。他们要的不是”接入 AI 生态”,是读者在网页上能问问题。

    这两种做法成本差多少。我觉得不是差个百分之十,是差一个量级。

    用户那边,一个要打开网页,一个要下载、安装、配置、授权,每一步都在筛人。运行那边,一次对话就是一次 API 调用,智能体要跑多轮、要调工具、要维护状态,token 和延迟都翻几倍。论出错,答得不好再问一次就行,智能体中途跑偏可能真的改错文件。

    内测会上有个细节我印象挺深。有编辑问”积分用完了就用不了是吧”,还有人盯着”生成一份 PPT 消耗 31.49 积分”这个数字。用户开始算资源账,就说明你的方案对他来说重了。网页上放个对话框,不会有人焦虑这个。

    智能体留给真正需要它的活 那什么时候值得上智能体。我觉得得同时满足三条:任务本身多步骤,中间结果要喂给下一步;要跨系统动手,读文件、调接口、改东西;用户愿意为它付安装成本。

    比如把一批书稿自动排版,核对法条引用,再生成终稿。或者围绕一个话题把法规、案例、学理观点都检索一遍,最后出一份带引用的研究报告。这些活用户不可能靠问一句话拿到结果,那装一套环境的成本就值。

    反过来,用户就想打开网页问个问题,你的智能体再强,他也不会为这个去装客户端。

    我们为什么会选错 我后来复盘,原因有三个。

    一个是想问题的方式不对。 做技术的人容易先想”这个我能不能做出来”“用新架构是不是更优雅”,我自己也是这样。但用户不关心你用了什么,他只关心自己现在的手在哪儿。他开着浏览器,你的方案就得从浏览器开始。

    一个是”先进”这词有诱惑。 MCP、Agent、多智能体协作,这些词说出来有面子,做出来有成就感。给网页加个对话框太朴素了,朴素到不像个值得汇报的成果。但朴素常常是对的,因为朴素意味着用户不用学新东西。

    还有一个,安装成本是用户掏的,不进你的账。 算成本的时候算的是 API 调用费、服务器、研发工期,没人会把”用户下载客户端失败”写进报表。它不在你表上,但它是真发生的。那场内测我们丢掉的不是钱,是第一天就没装成的那些人。

    而且被筛掉的人不会告诉你为什么,他们只是不来了。

    上手前问自己几句 有标准答案吗。有就写代码,别上模型。

    用户现在在哪儿。如果他已经开着浏览器,入口就该在那儿。

    这活需要多步骤、跨系统吗。一问一答能解决的,对话框够了。

    他会为这件事装个客户端吗。一周只用一次的,答案是不会。

    顺序大概是这样:能不能不做,能不能用代码,能不能用对话框,最后才轮到智能体。

    最后 我不是说智能体没用。它贵、重、强,所以更不该拿去拧螺丝刀就能拧的那颗螺丝。

    那家出版社要的东西最后看下来特别简单,一个网页上的对话框。我们做得出来,当时只是没往那个方向想。

    4 replies  •  2026-10-23 18:27:58 +08:00
    syyyyy
        1
    syyyyy  
       4h 5m ago via iPhone
    正好我在基于 openhands sdk+deepseekapi+向量库。也是做的网页版。智能体先理解问题、提取关键词,通过同义词处理和语义匹配,同时找“字面相符”和“意思接近”的资料,再合并排序。接着阅读候选原文,必要时补查上下文,核对版本、条件和出处。差不多这样吧,没智能体检索的准确度差很多。
    wmxpop
        2
    wmxpop  
    OP
       1h 31m ago
    @syyyyy 稠密向量和稀疏向量检索,最后加权平均吗
    syyyyy
        3
    syyyyy  
       23 mins ago
    加权排名融合( RRF )
    syyyyy
        4
    syyyyy  
       21 mins ago
    加权排名融合( RRF ),因为是先给智能体看哪些原文,然后让它更精确的使用。智能体是自建的 deepseek ,然后一些自用的知识库(量不大的)。不联网。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   2747 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 10:49 · PVG 18:49 · LAX 03:49 · JFK 06:49
    ♥ Do have faith in what you're doing.