RAG 生产环境应用指南
深入探讨如何在生产环境中有效部署和优化 RAG 系统。提供实战经验和最佳实践。
深入探讨如何在生产环境中有效部署和优化 RAG 系统。提供实战经验和最佳实践。
今天,我要给你讲讲 AI 领域那些经过精挑细选、精彩绝伦的新进展:从 Sam Altman 最近上演的 Uno Reverse 事件,到用防熊喷雾驱赶求职工程师。
我简直不敢相信,自上一篇文章以来,AI 世界竟然发生了这么多事。在那篇文章里,我颇有策略地部署了一支由 F 开头单词组成的庞大军团,成功发动了一场声势浩大的战役,目的是让别人来替我们写营销文章。我很高兴地告诉大家,他们立刻放下手头的一切,飞奔出去招来了一整支营销团队。现在,他们几乎每天都会过来感谢我没有再发文章,临走时还会狐疑地看我一眼,仿佛我随时可能突然发起一场满嘴脏话的广告牌宣传攻势。
所以,今天我们不聊营销,而是做新闻速递。我会给你讲述 AI 领域那些经过精挑细选、精彩绝伦的新进展。当然,只讲故事,不讲进展本身,因为那样有趣得多。
临近结尾时,我们还会向某个特定群体颁发一项令人垂涎的特别限量版大奖。如果你属于这个群体,那绝对是你应得的。敬请期待。
如果过去三个月里,你上网的时间超过了大约 257 纳秒,那你一定已经注意到,AI 领域的竞争正变得异常激烈:新公司宣称要用 AI 掀翻大公司;大公司则宣称自己一直在暗中做 AI,只是从来没告诉过任何人;Nvidia 更是给全体员工每人买了一尊纯金打造、原尺寸大小的华尔街铜牛雕像,作为小小的节日谢礼。
你一定也注意到了,大约有十亿亿家初创公司如雨后春笋般冒了出来,名字既直白又富有创意:挑一个自己最喜欢的单词,再创造性地在末尾加上“AI”。其中“AI”增添了一丝大胆气息,而它前面的那个单词则巧妙地概括了公司的明确差异化优势,比如“Irresponsible”。
亿万富翁们也开始注意到这一趋势,尤其是那些争夺“最烦人奖”的俱乐部成员。Musk/X 和 Zuck/Meta 听起来都像是 Old Spice 专为科技圈非自愿单身男性推出的止汗剂产品名,而这两家公司也分别打造了自己的 LLM,与 GPT-4 和 Claude 之流展开竞争。
虽然 Elon 的专有 LLM 目前仍忙着确保自己能贴心地叫广告商滚去和自己发生婚姻关系,但 Zuck 的 LLaMA 模型系列是开放、免费、强大且随手可得的。而且,这可能开创了科技巨头的先河:Zuck 居然没有处决泄露模型的员工。
尽管众所周知,全球经济糟糕透顶,人人都声称自己身无分文,但投资者仍然设法筹集了大约 2.3 千万亿美元,准备砸进 AI 初创公司。因此,如今参加晚宴时,你很可能会发现自己旁边坐着一位神情诚恳、身穿破洞牛仔裤的创始人,向你介绍他们的新公司 catnip.ai。该公司利用微调大语言模型的惊人力量,在你上班时逗猫开心,而且刚刚完成了 4.7 亿美元的种子轮融资。
这已经不只是一股风潮了;我们现在正处于狂热阶段,只要把“AI”放进公司名称里,VC 就会明目张胆地把钱朝你扔过来。任何人都可以把公司名称从 GoingBankrupt 改成 GoingBankrupt.AI,然后从常识水平堪比千层面的投资者那里轻松拿到额外 1 亿美元融资。如此多的公司竟然公然使用这种显而易见的操纵手段,还能全身而退,我个人对此深感震惊。
总之,我们 Sourcegraph AI 一直在密切关注这个领域。这个领域由 OpenAI 主导——这家公司以领先的封闭式 AI 提供商而闻名。重大新闻是,随着 Anthropic 等竞争对手开始认真起来,OpenAI 最近也决定认真还击。为了通过战略举措增强外界对其技术统治力的信心,他们解雇了自己的 CEO。
结果,大约 23,342,971 篇新闻文章纷纷告诉你应该躲进地下室,因为他们已经创造出了 Skynet。几天后,Sam Altman 打完高尔夫回来,大家才发现董事会不小心解雇的是他的一个深度伪造版本。该公司声称,如果你是 LLM 的共同发明者,又是全球最大 AI 公司的首席科学家,犯下这种错误完全合情合理,也十分寻常。
为这场传奇画上句号的是,真正的 Sam 反手一指,说出了那句名言:“不,被解雇的人是你!”他采用了经典的 Uno Reverse 策略,这种策略经常出现在儿童漫画、老派喜剧短剧,以及 Microsoft 支持的财富 500 强企业里。
唉。技术或许会变,但抓马永不过时。
毫无疑问,你已经注意到,GPT 催生了一个由数百个临时拼凑的 AI 助手组成的生态系统,它们像蚊蚋一样蜂拥着包围你。你甚至没法开车去上班而不让其中几个撞在挡风玻璃上。它们贴心地在你耳边嗡嗡作响,叫你试试它们,试试嘛!嗡!它们全都声称可以自动处理生活中各种日常苦差事:从总结你的 Slack 讨论串,嗡;到总结你的电子邮件,嗡;再到总结你的动态消息,嗡;以及总结并丢弃你表兄 Roman 发来的消息,嗡。(“摘要:想去打保龄球。”)
不过,有一类 AI 助手在骚扰用户方面似乎取得了真正、切实的进展,那就是编程助手。世界各地的开发者都会欣然承认,编程助手已经被炒作到了这样的程度:你的 IDE 大约每隔 37 秒就会贴心地提醒你安装一个,而你甚至愿意支付订阅费,只求它别再问了。嗡!
然而奇怪的是,GitHub 的所有月活跃用户中,只有大约 1%~2% 会付费使用 Copilot。Copilot 是一款颇具争议的编程助手,曾宣称自己比耶稣更受欢迎——不对,抱歉,说这话的是 Beatles,不过无所谓,我们都知道 Copilot 获得了大量炒作。打开 VSCode 时,它的 UI 布局会让你觉得,如果没有使用 Copilot,它就会摆出一张皱眉脸评判你。但真正使用它的人只有 1%~2%。其余 98%~99% 的人都在干什么?
当然,你们都知道答案:你们正在找工作。几乎每家公司都在 AI 引发的“创新者窘境”中痛苦挣扎,这让所有人的工作都变得更加困难,于是现在有大批人正摩拳擦掌准备跳槽。但市场上人才泛滥。而且出于种种原因——可能与安全和 ML 有关——所有公司都只招聘安全工程师和 ML 工程师。所以,几乎没有其他人能够跳槽。
你知道我是怎么知道这些的吗?因为我不断遇到下面这样的销售对话。
我:你好啊,同为非销售人员的朋友!我想先发起一段完全与销售无关的友好对话,然后以一种无比自然、毫无推销痕迹的方式,温和地来个剧情反转,把话题带到我的产品 Cody 上。你问 Cody 是什么?这个嘛,我每天都用它,而且作为一名与销售毫无关系的工程师,我发现它对我的工作极其有价值。那么,可以请你的团队看一下演示吗?
对方:能给我一份工作吗?
屡试不爽。我真没编。过去这么多个月里,这种情况至少发生过六到八次。当人们知道你们(a)正在招聘,而且(b)工作得很开心,甚至只是(c)不需要每周偷拿打印机耗材来弥补公司把晋升机会给了 Carl 的损失时,他们就会想加入!
公司当然也注意到了这一点,于是招聘时开始精挑细选。现在,任何人想跳槽都很难。
当然,除非你是 ML 工程师。
对于不了解情况的人来说,ML 工程师就像普通工程师,只不过他们开的是 Ferrari。他们精通现代机器学习基础设施、设计、工具、实践与部署。如果你是一名 ML 工程师,那么到现在你肯定已经意识到,自己需要随身携带防熊喷雾,用来抵挡那些不知从哪里突然冒出来、拿着沉重又危险的大捆现金朝你猛砸的招聘人员。万一有一捆砸中你的脑袋怎么办?如果你现在是一名 ML 工程师,我真的特别同情你。一想到这件事,我的胃里就会涌起一种隐隐的不适感,有点像嫉妒,但当然绝对不是嫉妒。
这让我想起当年我们还年轻又天真,在首尔筹建 Google 韩国首个工程办公室的时候。美国公司经常犯一个错误,那就是想当然地认为,世界各地的人都认同我们这项珍贵的文化传统:说自己经理的坏话。但我们在韩国发现,与西方不同,他们拥有一种丰富多彩的等级社会文化,崇尚级别与地位,并歌颂管理者。顺便说一句,这件事和我们领导团队最近决定只在韩国招聘完全没有任何关系。
但早在那个时候,Google 还不知道该如何看待这一切。我们在首尔面试的每一位符合条件的工程领导候选人,都非常乐意为我们工作,而且会自信地告诉我们,他们对公司豪车的颜色和型号、公司公寓所在的城区,以及私人司机着装的偏好。虽然这显然是首尔的常态,但 Google 还是为此纠结了好一阵子,因为感觉要求实在有点多。
与此同时,正在读这篇文章的 ML 工程师们会说:哈,哈!在韩国,他们居然连艘船都不给吗?因为人才市场上的 ML 工程师想要什么就能得到什么。如果你是一名 ML 工程师,想找份工作,同时还想要一艘船,我猜想你只要通知一下家门外景观绿化带里的随便哪棵灌木,就会有一个招聘人员从里面蹦出来,把你拽到他们车后座,然后直接开去码头,逼你挑一艘船并签下 offer。
事实上,在你被拖向汽车时,可能还得击退其他招聘人员。我听说防熊喷雾在这种时候很有用。
大家嘴上都很强硬,但事实是,大多数公司才刚刚开始摸索自己的 AI 战略。在 Sourcegraph AI,我们几乎会与各行各业中你能想到的每一家大品牌、名字响亮、Logo 光鲜的公司交流,而我们反复进行着同样的对话。
各行各业的公司都很听话地按照各自的 AI 战略进展,分成了几个泾渭分明的类型:
极少数提前交作业、还做额外加分题的尖子生。说的就是你,CapOne。
作业进度大致正常,但不太确定该怎么把它完成的公司。这类大约占所有公司的 30%。
还有一些公司,当我们问它们 AI 评估作业做得怎么样时,它们会从后裤兜里掏出一张纸,展开一看,上面写着:“做作业”。
最后这一类轻松占到《财富》1000 强企业的 50%。我可以把它们的名字说出来公开羞辱,但那样我们得在这里待很久。
我所说的“作业”,当然是指弄清楚你们的 AI 战略。因为这是地球上的每一家公司现在都需要做的作业。然而奇怪的是,你们中的许多人在规划 AI 时,紧迫感大致等同于兑现一张邮寄过来的 17 美分退款支票。“行了,行了,”你说,“我迟早会处理的。”好吧,如果你再不处理,这个数字可能很快就会变成你们的股价。
我可以向你保证,无论你身处哪个行业,至少都会有一两个令人讨厌的全优生,正在为自己的 AI 作业制订五年和十年计划,而且其中许多公司已经在评估供开发人员使用的编程助手这条路上走得相当远了。
我可以告诉你是什么导致了这种情况。每家公司都一样。那就是“创新者的窘境”——Clay Christensen 博士和 Harvard Business School 推出的一项名字滑稽地不贴切的恐怖游乐设施,与其说它是“窘境”,不如说它是“刑具”。我计划另写一篇博客文章,讲讲自己亲历它时的感受。但它正在撕裂各家公司,让它们无法应对 AI 带来的新压力。
所以,我们从那些拖拖拉拉的人那里听到的是:“我们正在做,只是得先完成一次重组;某某刚刚离职;我们正在努力组建一个专项小组,但现在事情真的很混乱”,诸如此类。他们似乎就是无法围绕 AI 组织起来。不知为什么,这件事始终无法成形。
对你们大多数人来说,原因就是“创新者的窘境”,而你们的公司需要培养一种生死攸关的紧迫感,才能渡过难关。不要被竞争对手甩在身后——他们正在从 AI 整体上获得巨大的速度提升,尤其是从编程助手中。
如果你陷入了困境,就来找我聊聊。公司可能提出的几乎所有想法、请求和顾虑,我们都听过,也可以提供帮助。
我觉得你们大多数人都没有意识到自己已经落后了多远。
下面是我和其他公司的工程领导同行聊起这个领域时,一段典型对话的展开方式。
我:你好!我很想认识一下你们的数据科学家,了解你们迄今为止的 AI 之旅,并探讨我们如何能以合作伙伴的身份携手,借助 Cody 帮助你们的工程师更上一层楼——Cody 是我们出色的新型编程助手,它利用我们世界一流的搜索引擎,帮助 LLM 理解你们的整个代码库——同时也想探讨一下,我们是否能展开合作,将 Cody 平台与你们正在构建的其他 AI 驱动系统连接起来。
对方:能给我一份工作吗?
编程助手新近带来的、前所未有的生产力提升,唤醒了许多公司一个令人不安的新想法:它们认为自己需要对这种提升进行衡量。
你大概已经能猜到事情会往哪里发展。许多潜在客户会客气地问我们,能不能修改 Cody,给它加上一个检测器,用来监控工程师的生产力,并通过指标检测他们何时跌破某个阈值;一旦跌破,就把他们绑在火箭上发射到太空,同时支付两个月的遣散费。他们还会问 Cody 是否提供企业管理员控制功能,以防他们不小心把某个在轨员工开除了,而那名员工没有达到生产力目标,只是因为 Susan 承办的公司塔可活动结束后被困在了洗手间;这样等那名员工被拽回地球后,他们还能恢复其系统访问权限。
我们自然绝对、绝对、绝对不会以低于 100 万美元 ACV 的价格打造这种骇人怪物。因此,有鉴别力的公司转而趋同,甚至执着于如今最流行的编程助手指标:补全接受率(Completion Acceptance Rate,CAR)。它衡量的是,在向你展示的全部补全建议中,你有多少次觉得“嗯,这段代码看起来差不多是对的”,然后按下 TAB 接受它。换句话说,CAR 就是人们接受编程助手补全建议的百分比。
恰巧,在 Cody 的众多能力中,CAR 是它尤其擅长的一项。因此,经常会有一些本意良好、但也没那么良好的潜在客户找上门来。他们受到“Be Evil”这一座右铭的启发,试图用某种 1:1 的换算关系,把 CAR 等同于开发人员的生产力。我们就把这些潜在客户叫作 Beevils 吧。干我们这一行,会遇到很多 beevils。我们经常不得不向 beevils 解释——现在我们把这种解释称为 beevilsplanation——如果这个行业以前无法量化开发人员的生产力,那么引入 AI 这样的加速手段,并不会突然让它变得可以量化。
我的意思是,CAR 是个不错的指标——它是响应相关性的一个简单代理指标,易于衡量,也易于理解——但用它来衡量甚至比较开发人员的生产力,就像通过统计 F1 车手踩油门的频率来估算他们在比赛中的名次。这个比喻并不完美,但基本思想是一样的:CAR 并不衡量或建模结果。
因此,虽然 CAR 是了解编程辅助给组织整体效能带来多少提升的诸多有用信号之一,但要拿它把人绑上火箭,恐怕不会非常有效。我已经能感受到来自世界各地那些重要决策者 beevils 的阵阵失望了。
如果你的组织正在努力弄清楚应该使用哪些指标来评估 AI,例如要确定该在 AI 上花多少钱、采用哪些技术,或者哪些东西该买、哪些该自己构建,那就来找我们聊聊。我们在这条路上已经走得相当远了,大概能帮上忙。
只剩两个了!这一篇会以颁奖典礼结束,然后离场前还有最后一篇,接着你终于可以从屏幕前抬起头,伸展一下脖子,然后意识到你的飞机已经在两个小时前起飞了。
我最近最喜欢的一项 AI 发现,与我们这些极少数程序员有关:这么多年来,我们一直坚持给代码写注释,因此饱受嘲笑;吃午饭时不得不独自坐一桌;有人把写着 "// Comment Me" 的贴纸贴在我们背后;大家叫我们“注释小子”;以及其他各种各样的霸凌。这种事情已经持续了四千年——早期穴居人试图把注释刻在洞穴墙壁上时,就会被长矛捅死。
我发誓,我从来都无法理解人们为什么如此痛恨注释。哦不,我感觉自己要开始长篇吐槽了。不——!趁还来得及,快跑!
太迟了。吐槽模式已启动。
你们这些拒绝在代码里写注释的人,到底他妈的有什么毛病?这事真的已经存在了不知道多少年。我记得 1999 年,一位 Amazon 高级工程师告诉我,注释是一条“滑坡”,而且注释总会过时……所以,你绝不应该使用它们。
这家伙当时在内核团队,他的姓恰好是一个常见 C 标准库函数的名字,而且还不是普通单词。不过我不想暴露他的身份,就叫他 Bill Strncpy 吧。老 Strcpy 想把洗澡水、孩子、浴缸、房子、汽车,甚至他几个年纪较大的孩子全都扔掉——再提醒我一下他的理由吧,因为我实在不敢相信他的逻辑——“有时候注释会随着时间推移而过时”?
我是说,对对对,当然不要写那种描述代码做了什么的注释,因为它们确实会随着实现的变化而过时。但你绝对应该写清楚“为什么”!我是说,对吧?然而据 Bill Strftime 先生所言,所有形式和变体的行内注释都很“危险,容易滑坡”。他不建议写。啊!
而且我简直不敢相信,外面竟然有那么多 OSS 仓库看起来就像被注释剥离器处理过一样。我还记得早些年,自己从 Google 舒适的茧房里破茧而出,不再做一只与世隔绝的小毛毛虫,而是勇敢地飞向世界,变成一只又大又丑的飞蛾,开始查看 OSS 时,我曾非常认真地怀疑:是不是存在某种我从未听说过的诡异文化习俗,要求 GitHub 贡献者在上传代码之前必须删除其中的注释,然后戴上奇怪的面具,在满月之夜聚会?这实在令人费解。
我仿佛已经听见 Bill——呃,Putchar,或者随便我们之前到底叫他什么——这样愤愤不平的人寄来的怒斥信了。“你怎么敢让我们解释自己的思路!我们的思路可能会过时!”他们会一边说,一边慢吞吞地试图想明白这件事。但你根本说不通他们。
猜猜怎么着,Bill?我是对的。你错了。事实证明……注释能够提供极其宝贵的上下文,帮助 LLM 推理你的代码!
处理查询时,LLM 可能只会看到某个更大子系统或作用域中的一小段代码,因为为了构造最佳上下文,你往往不得不把许多代码片段都塞进上下文窗口。这些代码片段里的注释不仅能为 LLM 提供更广泛、更准确的上下文,帮助它推理你的代码,Cody 还可以在上游的上下文组装引擎中利用这些注释,增强相似度搜索、图搜索和其他索引。
注释让整个系统都变得更聪明。所以归根结底,这么多年来一直坚持给代码写注释的所有人,都会从编程助手那里获得更好的结果。
哈!接招吧,Memcpy 先生!好吧。他大概不会读到这篇文章。他现在已经富可敌国了。但如果他哪天真看到了,我相信这一定会深深刺痛他。
给你的代码写注释!代码注释终于赢得了这场战争。绝不接受任何反驳!
为了认可并庆祝这场胜利,如果你一直都在给代码写注释,请随意领取下面的任意一枚徽章。这是你应得的。
敏锐的读者应该还记得,m10r 是 modeltrainer 的缩写。即使面对 Bill gmtime_64 之流无休无止的嘲弄,这么多年来你依然坚持给代码写注释;而你的这个习惯,正在为 AI 助手提供宝贵的模型训练数据,既可用于微调,也可用于上下文学习。
所以,正因如此,因此,迄今为止,直到如今,以及从今往后,我谨代表世界各地的编程助手,感谢你为帮助 AI 所做的贡献,并欢迎加入 m10r 俱乐部!你应该把贴在自己背后的那张告示撕下来了。
我想也该收尾了,所以就用今天的最后一条新闻结束吧:Cody 现在已经 GA 了。
作为本时段的最后一条新闻,我很高兴地宣布,Cody——Sourcegraph 基于 LLM、采用 RAG 的 AI 编程助手——现已正式全面开放使用。没错,就是向你开放。
“Generally Available”真是个糟糕的术语;听起来就像你的系统现在“大体上是在线的”,你“偶尔大体上会考虑一下 SLA”,你的“员工大体上会来上班”,诸如此类。听起来实在太奇怪了。“Azure 现在 Generally Available 了!”不过话说出口之后,不知道为什么,我反而觉得这个说法挺合适。
总之,Cody 已经 GA 了!只经历了短短 9 个月的疯狂开发……但它建立在 Sourcegraph 十年代码理解基础设施的根基之上。所以它还是个婴儿,却是宫崎骏电影里那种大得出奇的婴儿。你可以在多种客户端中使用 Cody,包括旗舰版 VSCode(GA)、IntelliJ(Beta)、其他 JetBrains IDE(Experimental)以及 Neovim(Beta)。而且它还提供免费套餐,让你随便折腾。滋滋滋!你的挡风玻璃上又多了一只小飞虫。
既然这不是一篇营销文章,我就不拿 Cody 的功能来烦你了。我的意思是,你直接下载下来,自己摸索就行。相反,我要告诉你的是:自从你上次可能看过它之后,我们这段“从 RAG 走向财富”的传奇故事又有了哪些新进展。
今年早些时候,Cody 还只是 POC 品质——有些人甚至会说是 POS 品质——如今却已迅速成长为一款精致流畅的 GA 产品。它用起来非常有趣,而且安装之后马上就能提升你的生产力。代码补全建议响应迅速,准确得令人满意;Cody 的聊天体验基本上无与伦比,聊天 UI 和上下文指定方式都得到了显著改进。Cody 的整体性能与质量在各个方面都颇具竞争力,可以扩展到企业级,并在 LLM、上下文、托管方案、护栏等方面提供丰富的选择。
Cody 的秘制配方和差异化优势,始终是 Sourcegraph 对代码库的深入理解;Cody 利用这种理解,打造出了完美的、基于 RAG 的编程助手——按照定义,也就是能为 LLM 生成最佳上下文的那个助手。
这正是 RAG(检索增强生成)的全部意义所在。你要检索出尽可能多的信息——多到足以让人类执行某项任务——再把这些信息连同任务指令一起交给 LLM,从而增强 LLM 的生成能力。Cody 的 RAG 是推荐系统的一种变体,它会针对每项任务或查询,向 LLM 推荐相关代码及其他上下文。Latent Space 的朋友们最近也提出了这一点;他们不久前还邀请 Beyang 和我参加了一期播客。优秀的推荐系统需要大量模型、领域知识库、在大规模语料库上进行快速检索的能力,以及其他基础设施,而 Sourcegraph 早已为代码领域基本构建好了这些东西。
如今,生成完美上下文仍是一门黑魔法,但就我所见,我认为 Cody 很可能已经在这方面走得最远。Cody 的 Context 已经从“嘿,我们有向量嵌入”,进化到了“嘿,我们有整整一支引擎战队”。生成的关键在于