Skip to main content
YUFAN & CO.
返回博客
blog.categories.industry-insights

别再交“上下文架构税”了:一种让中小企业更快用上 AI 的方法

Yufan Zheng
创始人 · 前字节跳动 · 北京大学硕士
1 分钟阅读
· 更新于
Cover illustration for Stop Paying the Context Architecture Tax: A Faster Way to SME AI

你正盯着一张 £3,500 的月度账单发愣。这是一套所谓的“AI 知识库”,但你团队里没一个人信它。

就在前几天,你的运营经理问这系统:新供应商合同的付款期限是多久?它特别自信地吐出四个字:“Net 30(30 天内付款)”。

结果呢?合同原文写的是:“Net 30,但如果订单金额超过 £10k,则为 Net 60。” 你的那笔订单是 £14k。因为系统说错,你提前把钱付了,直接搞残了那一周的现金流。

你打电话给开发外包公司。他们支支吾吾,扯什么“向量嵌入(vector embeddings)”和“分块重叠(chunk overlap)”。最后告诉你,他们还需要两周时间来“调优检索算法”。

这就是目前中小企业(SME)搞 AI 的现状:一堆乱七八糟的活动组件,你根本看不懂的数据库,还有直到钱从银行划走你才发现的隐形错误。

但问题是,当初把你逼进这个坑里的底层逻辑,现在已经变了。

所谓的“上下文架构税”

“上下文架构税”指的是你白白扔给开发者的 £20,000 到 £40,000。你付这笔钱,是让他们把公司的文档切片、索引、再检索,仅仅是因为“一次性处理整个文件”在以前太贵了。

这就是为什么整个 AI 行业都在痴迷“RAG”(检索增强生成)。两年前,把一份 50 页的 PDF 喂给大模型,每问一次都要花掉好几英镑。如果你的财务助理每天要处理 200 份发票和供应商合同,光 API 费就能把你的利润吃光。

于是,业界发明了一个“省钱偏方”。

与其读完整个文档,不如把它切成一段段的。你把这些段落存进一个“向量数据库”。当用户提问时,系统先搜出最相关的三个段落,把它们抠出来,只把这几个碎片传给 AI。

这本质上是一个伪装成“技术标准”的省钱大招。

麻烦在于,这个偏方成了所有中小企业 AI 项目的默认架构。你找个外包或者买个现成的 SaaS 工具,他们上来就开始搭向量流水线。加个 Pinecone,弄个 LangChain,搞一套 RAG 系统。

你在为一套旨在帮你省 Token 钱的基础设施买单。但这套设施带来了巨大的运营成本:你的团队现在得维护一个搜索引擎。

供应商一改格式,分块逻辑就断了。合同第 2 页有个条款修改了第 14 页的内容,向量搜索却只抓取了第 14 页。AI 于是给了你一个错误的答案。

想想这事儿多荒唐。你的运营团队读合同,难道是把合同剪成 500 字一条的纸带,扔进档案柜,等供应商打电话来时再瞎抓三条出来读吗?当然不是。他们会读完整个文档,理解前因后果。

为了省那几分钱的 API 费,你强迫 AI 去读碎片,人为地废掉了它的推理能力。你不是在为智能买单,你是在为一种已经不存在的硬件限制交税。

为什么那些“显而易见”的解法行不通

大多数中小企业试图通过买个现成的 RAG SaaS,或者雇个初级开发用 Zapier 把向量数据库串起来,以此解决文档处理问题。

我直接告诉你:向量数据库是中小企业的陷阱。它们解决的是计算成本问题,而不是推理问题。

这就是“Zapier 连向量数据库”这套流程必死的原因:

你的系统收到一份供应商发来的 40 页服务主协议。Zapier 把它发给一个工具,把文字切成 500 字一块,存起来。

一周后,运营经理问 AI:“延迟交货的罚金是多少?”

向量数据库搜索“延迟交货罚金”的意思。它在第 32 页找到一块文字说:“延迟交货的罚金为订单总额的 5%。” 它把这块发给 ChatGPT。ChatGPT 说:“罚金是 5%。”

但系统漏掉了第 3 页。第 3 页有个定义章节写着:“延迟交货罚金仅在延迟超过 14 个工作日时适用。” 因为第 3 页没出现关于罚金的具体关键词,数据库没把它搜出来。大模型压根没看到。AI 就这样通过“隐瞒真相”,自信地对你的运营经理撒了谎。

当 Zapier 流程断掉时,它不会大声报警。Webhook 照样触发,JSON 照样解析,AI 照样给答案。它只是给了一个错误的答案。你只有在月底供应商来催你交那一笔你压根不知道的滞纳金时,才会发现。

这事儿不仅烦人,而且危险。

根据我审计中小企业流程的经验,一个 50 人的公司,平均每月要在根本不需要的向量数据库和 API 封装上烧掉 £1,200,同时还要忍受 15% 的文档查询错误率。

通常的解法是花更多钱去“调优”检索系统。你投入更多开发工时,调整分块重叠度,试图让搜索引擎更聪明。

你打错仗了。解法不是更好的检索,而是压根不去检索。

真正奏效的方法

真正奏效的方法

现在的上下文填充技术跳过了搜索架构,直接把全文喂给 LLM,成本更低且准确度更高。

真正奏效的方法是:暴力塞入上下文(Brute-force context stuffing)。

别再把文档切碎了。把整份 40 页的合同、整个 10,000 行的 CSV、或者整个 50 封邮件的往来记录,每次提问时,直接把全量内容一股脑扔进 Prompt(提示词)里。

直到最近,大规模这么干还会让中小企业破产。但底层硬件的经济账刚刚翻篇了。

Microsoft 已经在其美国数据中心部署了定制的 Maia 100 AI 芯片,专门为了打下 AI 推理的成本。这种新芯片让 Token 生成成本降低了 30% [来源](https://www.enterprisetimes.co.uk/2026/02/02/security-and-ai-news-from-the-week-beginning-26-january-2026/)。再加上 OpenAI 和 Anthropic 过去一年的疯狂降价,现在的 Token 已经便宜到可以随便浪费了。

所以,那就浪费吧。

假设你收到一份复杂的、20 页的发票和合同附件 PDF。

别用那脆弱的 Zapier 流程了,改用 n8n 的 Webhook。Webhook 抓取 Outlook 里的来信,剥离 PDF 附件。不要把 PDF 发给向量数据库,不要切片。

相反,n8n 直接触发一个 API 调用,发给 Azure OpenAI(跑 GPT-4o)或者 Claude API。Prompt 里直接塞进整整 20 页的文字。

你给大模型一个死命令:“读完整个文档。提取供应商名称、总金额、付款条件和任何滞纳金条款。输出必须且仅能是一个符合此格式的 JSON 对象。”

因为大模型一次性拥有了整个文档的上下文,它能同时读到第 3 页和第 32 页。它能看到定义,能看到交叉引用。它在整篇文字中进行推理,就像人类律师一样。

n8n 工作流收到结构化的 JSON。然后通过 API 步骤,直接把这些条目 PATCH 到 Xero 里。

因为 n8n 支持复杂的分支逻辑,你可以加个简单的门控:如果 JSON 里的总金额和各项明细加起来对不上,就把文档转给 Teams 里的真人处理。如果对上了,直接推送到 Xero 生成待付账单。

开发这玩意的成本?你省掉了向量数据库、分块逻辑和检索调优。大概只需要 2 到 3 天的开发时间,成本约 £2,000 到 £4,500,具体取决于你的 Xero 集成有多乱。

运营成本?每个文档的 API 费大概 £0.05。就算你一个月处理 1,000 份文档,也就花 £50。Microsoft Maia 100 芯片带来的 30% 降价意味着,计算力现在比开发者的工时便宜多了。

这种模式主要的失败点不在于漏掉上下文,而在于大模型偶尔会不听你的格式指令,在数据前加一句“这是你要的 JSON:”之类的废话,导致 Xero API 报错。

要解决这个,你可以在 API 调用时强制开启“结构化输出(structured outputs)”,或者加一个轻量级的二次 Prompt,在数据进入财务软件前严格校验 JSON 格式。

这种方法哪里会失灵?

当你遇到物理数据极限时,暴力法就不灵了。比如扫描的陈年旧件、超长页数,或者对实时延迟要求极高的情况。

第一,如果你的发票和合同是 15 年前从老财务系统里扫出来的 TIFF 文件,直接扔给大模型会挂掉。你需要先过一遍专门的 OCR。如果 OCR 把模糊的 “£10,000” 读成了 “£10.00”,大模型会自信地传回错误数字。你的错误率会一夜之间从 1% 飙升到 12% 左右。

第二,上下文限制依然存在。40 页的合同没问题,但 2,000 页的技术手册或者 500,000 条客户支持记录的数据库就不行了。如果你试着把 1GB 的文字塞进一个 Prompt,API 会拒绝,或者模型会出现“上下文衰减”,悄悄忘掉 Prompt 中间页的内容。

第三,速度。如果你是在给网站做实时聊天机器人,往 Prompt 里塞 40 页文档会增加延迟。用户可能要等 8 到 12 秒才有回复。对于后台的 Xero 自动化,12 秒无所谓;但对于盯着聊天窗口的客户,这简直像过了一个世纪。

最后,这要求你的团队知道怎么写严格的 JSON Schema。如果你只是让 API “总结一下发票”,你会得到一堆非结构化的散文,根本没法自动填进 Xero。

如果你碰到了这些边界情况,你还是得交那份“上下文架构税”。但对于 90% 的中小企业日常运营来说,你完全可以不交。

问题不在于 AI 能不能读你的文档,而在于你是否还在为一种已经被 Microsoft 解决掉的硬件限制,支付过时的架构费用。

当算力昂贵时,你付钱给开发者写聪明的代码;当算力廉价时,你扔掉聪明的代码,让处理器直接硬扛。今年能赢的中小企业,不是那些拥有最尖端向量数据库或最复杂 Zapier 网络的,而是那些意识到“把整份文档扔给廉价 Token 才是把干净数据搞进 Xero 最快、最稳的方法”的人。

别再为自己的数据交税了。扔掉整个文件,要求严格输出,然后该干嘛干嘛去。

订阅获取 UK AI 洞察。

针对英国企业的 AI 实战内容 —— 拆解、教程、监管解读。随时取消。

随时取消。