尊敬的 IT 部门，请停止尝试构建自己的 RAG
Alden Do Rosario
2025-03-03 10:44:27
你们绝对不会花一百万年时间自建CRM系统或定制CMS——在大多数情况下，也不会自研大语言模型（LLM）。对吧？
但如今放眼望去，我看到无数IT部门正自我催眠，认为自建基于RAG的聊天系统"与众不同"。其实不然。甚至更糟。
上周，我目睹一群才华横溢的工程师演示他们全新的自研RAG流水线。他们自豪、兴奋——因为用上了向量嵌入！做了提示词工程！却浑然不知即将到来的灾难。
相信我，这种剧情我看过无数遍。结局总是相同：工程师精疲力尽、预算超支，以及CTO质问为何不直接购买现成方案。
加上开源工具，或许再来点[Langchain]后面会细说），就完事了？
最近接触的一家中型企业，其"简单"的RAG项目1月启动。到3月时：
最糟的是，他们逐渐意识到：原以为两个月能搞定的项目，将变成持续噩梦。
-
文档与知识库预处理复杂度（试试从SharePoint、Google Drive和网站抓取数据）
-
-
生产环境准确率暴跌（测试完美，实际用户一用就崩！）
-
-
-
-
变更数据捕获（比如网站内容更新后，RAG如何同步？）
-
-
安全漏洞与数据泄露（内部系统能达到SOC-2 Type 2认证吗？）
每一项都能单独成项目，处处暗藏杀机，随时拖垮进度。
讽刺的是：当你们烧钱自建时，竞争对手早已用现成方案投产，成本仅是零头。
因为采购方案经过数千客户验证，研发成本已被均摊。而你们的投入，全由一家独自承担。
想失眠？试试负责一个能访问公司全量知识库的AI系统：
某CISO发现其自研RAG系统意外泄露内部文档标题，修复耗时三周，随后又发现五处同类漏洞。
威胁进化速度远超团队应对能力。上月的防护措施今天可能已过时。攻击面持续扩大，黑产手段日益高明。
记住：每新增一份文档都是潜在风险，每条提示词都是攻击入口，每次响应都需筛查。不仅要构建安全系统——更需在日变的环境中维持安全。
还记得那家用Langchain起家的初创公司吗？后续剧情：
这不是个例，而是自研RAG系统的标准生命周期。更"精彩"的还在后头：
所有这些都需在开发新功能、支持新用例、满足业务需求的夹缝中完成。
在当下市场，招齐这些人才已是难题。即便找到，能否负担薪资？能否留住？毕竟全行业都在抢这些人。
更关键的是：当其他RAG平台持续升级服务、提升准确率和反幻觉能力时，你们的团队能保持同步吗？未来二十年呢？
听着，我并非反对自研，而是建议明智选择建造内容与理由。
-
按需求评估（提示：看案例）
-
查安全资质（提示：要求SOC-2 Type 2）
-
验证企业适配性（提示：索要案例！）
-
测试性能（提示：参考公开基准）
-
考察支持质量（提示：打电话测试！）
因为真相是：五年后，没人关心RAG是自研还是采购。他们只在乎痛点是否解决。
停止重复造轮子。尤其当这个"轮子"实则是需要持续维护、细节出错就会爆炸的AI航天器。
自研RAG就像2024年自建邮件服务器——当然可以，但何必？
未来的你会感谢这个决定。工程师会感谢，预算会感谢，更重要的是：当你在凌晨三点调试准确率问题时，业务会感谢你选择了解决真实问题。
作者丨Alden Do Rosario 编译丨Rio
来源丨网址：https://pub.towardsai.net/dear-it-departments-please-stop-trying-to-build-your-own-rag-4546b4638273
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
如果字段的最大可能长度超过255字节，那么长度值可能…
只能说作者太用心了，优秀
感谢详解
一般干个7-8年（即30岁左右），能做到年入40w-50w；有…
230721