这周我没写代码。法务部扔来三份收购协议，说“你那么爱用AI，让它帮忙审一下”。我本来想用Copilot应付，但条款交叉引用多得像意大利面。正好xAI的Grok 3刚放出来，尤其那个DeepSearch功能，据称能做多步推理、链式思考、实时检索证据链——说白了，就是把大模型和搜索结合成一台辩论机器。我花了整整两天把Grok 3按在法律和金融的真实文件上摩擦，下面是我从工位上记下来的全过程，包括我踩的坑、它打的脸，以及那个让我后背发凉的结论。
30秒速览
- - Grok 3的DeepSearch会主动拆解复杂问题、多轮检索并交叉验证证据，在发现用户问题逻辑缺陷时能自我修正。
- - 法律和金融实测中，它比GPT-4o+联网和Claude 3.5+Perplexity更能揪出文档矛盾、量化财务差异，但推理成本高、偶尔过度引用边缘判例。
- - 开发者需要控制depth和evidence_threshold参数来平衡效果和开销，否则单次查询烧掉近$1。
- - 开源承诺仍需观望：模型权重和搜索索引是否开放，直接决定社区能否复现这类推理能力。
我不是在搜索，我是在逼Grok 3拆开我的问题
传统的搜索引擎+LLM方案（比如把Bing API套在GPT-4o外面）本质是“检索-阅读-回答”的单程票。你把问题抛出去，它翻几页结果，拼一个摘要回来。但Grok 3的推理模式不一样：它接到问题后，会先把问题拆成多个子任务，每个子任务再单独检索、交叉验证，最后合成一个带有推理链的答案。官方管这叫“DeepSearch”，我管它叫“给模型装了个律师脑子”——它会质疑我问题里的隐含假设。
一个法律查询的层层剥茧，我记录了每一步
我先扔了个真实的法律难题进去：
“根据2023年SEC对新能源公司ABC Corp的处罚公告，分析该公司是否违反了《反海外腐败法》(FCPA)中的会计条款，并判断公司CFO在后续股东诉讼中可能面临的个人责任。需对比2018年同类型案例US v. Hoskins。”
在Grok 3的API里，我启用了DeepSearch模式，要求返回完整的推理链（reasoning chain）和证据来源。下面是当时我写的调用代码，跑在本地Jupyter里：（延伸阅读：我让Copilot里三个模型轮番写SQL，结果Gemini差点让我半夜被客户电话轰炸，现在我把默认锁死在Claude 3.7 Sonnet）
import asyncio
from xai import Grok, DeepSearchConfig
client = Grok(api_key="grok-xxxx")
config = DeepSearchConfig(
depth=4, # 最大推理步数
evidence_threshold=0.8, # 引证置信度阈值
enable_cross_check=True # 允许模型自检矛盾
)
query = """
根据2023年SEC对新能源公司ABC Corp的处罚公告，
分析该公司是否违反了FCPA会计条款，
并判断CFO在股东诉讼中的个人责任。
需对比2018年US v. Hoskins案。
"""
response = client.search(query, config=config)
print("===最终答案===")
print(response.answer)
print("n===推理步骤树===")
for i, step in enumerate(response.reasoning_steps):
print(f"Step {i+1}: {step.intent}")
print(f" 检索词: {step.search_terms}")
print(f" 引用源: {[s.title for s in step.sources]}")
print(f" 中间结论: {step.interim_finding[:200]}...")
if step.contradiction:
print(f" ⚠️ 矛盾预警: {step.contradiction}")
Grok 3没有直接搜“ABC Corp FCPA”，而是把查询拆成了四个子步骤：第一步去SEC EDGAR搜处罚原文；第二步从DOJ官网拉Hoskins案判决书；第三步检索哈佛法律评论关于FCPA会计条款的解释；第四步综合前三步，构建法律适用性推理。我等了将近40秒，比常规大模型慢得多，但返回的东西让我直接坐直了。
它指出，SEC处罚公告里只提到ABC Corp的“账簿记录不准确”，并未指控“内部控制缺陷”，而FCPA会计条款要求同时满足两种情形才能构成母公司高管的责任。然后它引用Hoskins案，说明代理理论下CFO的管辖权前提——如果CFO不直接参与向外国官员行贿，仅因签字权被追责的法院支持率只有23%。它甚至在第三步里发现了一个我根本没注意到的细节：SEC公告中有一段脚注暗示DOJ已放弃对个人的刑事追诉，这直接削弱了股东诉讼中“故意”的认定。
多步推理的代价：它开始怀疑我问题里的前提
我又试了一个带陷阱的提问：“对比特斯拉2023年年报中FSD（完全自动驾驶）收入与Waymo的盈利数据，解释特斯拉是否夸大了FSD的营收贡献。”我故意模糊了两个公司截然不同的收入确认方式。Grok 3在推理第二步就弹出一条警告：“特斯拉采用take rate预估未实现收入，Waymo按行驶里程确认收入，两者不可直接对比。问题隐含前提有误。”然后它自动修正了检索方向，分别从两份财报的附注里提取了递延收入政策，最终给出的结论是“现有公开数据无法支持夸大指控”。（延伸阅读：我让Warp终端接入了GPT-4o：现在中文写巡检脚本，深夜告警直接让AI出招，再也不半夜扒开眼改awk）
这种“质疑问题本身”的能力，传统RAG做不到，因为传统RAG只会匹配语义相近的文档，不会主动指出用户问题的逻辑缺陷。但这也引出了第一个坑：Grok 3的深度推理太贵了。上面那个法律查询烧掉了37000个token的推理开销，按xAI当前的定价，一次查询差不多$0.8。如果法务部每天来十次，成本够请一个实习生干半天了。
DeepSearch工作流：从检索到辩论，我看到了传统RAG的致命伤
为了弄清Grok 3到底怎么做到的，我把它的DeepSearch流程和传统搜索引擎+LLM（比如我用过的LangChain+Chroma+GPT-4o）放在一起拆解。传统方案一般分五步：文档分块、嵌入、检索top-k、拼接prompt、生成。但Grok 3的推理日志显示，它的检索不是一次完成的，而是多轮的、有目标的。
查询分解不是简单的关键词拆分
举个例子，我问“英伟达2024年Q2财报中提到的出口管制风险，是否会影响其在中国市场的AI加速卡收入？请结合中国海关总署最新半导体进口数据。”如果是传统RAG，系统会把整个问题向量化，然后去文档库里找“英伟达 出口管制 中国市场 AI加速卡”相关的片段。但DeepSearch先提取了两个独立的断言：①英伟达财报是否明确警示了出口管制风险；②海关数据是否显示AI加速卡进口量下降。然后它分别检索NVDA的10-Q报表和中国海关总署官网，拿到第一手数据后再交叉验证：如果财报的警示用词是“可能”，而海关数据显示进口量同比增长，那么“影响”的推论就有瑕疵。Grok 3最后给出的答案是：“英伟达在‘风险因素’章节使用了模糊措辞，而海关数据显示2024年Q2中国GPU加速卡进口量环比上升12%，说明短期影响有限，但长期需观察BIS新规落地。”（延伸阅读：Copilot多模型切换评测：我拿三个模型轮番干了6件事，差点删库跑路，最后我选了它）
这里的关键差异在于，传统RAG把知识库当成一个静态的语料池，而DeepSearch把每一次检索都当成一个动态的论据收集器，并且能在推理过程中发现论据间的矛盾。
证据链合成：把碎片拼成论点，还是把论点拆成碎片？
我再举一个踩坑的例子。我让Grok 3分析一份虚构出来的供应链合同纠纷，里面有两个条款互相矛盾，一个说“延迟交货违约金为每日合同金额的0.5%”，另一个说“违约金上限不超过总价的10%”。我期待模型指出上限条款会限制计算。结果Grok 3在检索“合同法违约金调整规则”时，自己搜到了《民法典》第585条关于违约金过高的司法解释，竟然主动提出一个我没预料到的点：如果0.5%每日累计远超10%上限，法院可能依据公平原则把上限打破，判赔更高损失。它引用了一个2021年的最高法判例。这个结论让法务部的人直接拿去找外部律师核实了——没错，后来律师说确实存在被突破的可能。
但这也暴露了DeepSearch的软肋：它可能会把检索到的边缘判例当成主流规则，导致过度推理。那次我观察到它把某个地方法院的个案权重拉得太高，我不得不人工调整了evidence_threshold到0.9，才让输出更稳健。这是当前版本的一个粗糙处，需要开发者自己掌控搜索深度参数，否则容易被“信息过载”带偏。（延伸阅读：我把OpenAI实时API和代码解释器焊死了，张嘴问数、闭嘴看图，延迟压到800毫秒）
拿金融数据当试金石，Grok 3的对手被我喊来了
GPT-4o（通过 OpenAI 的 Browse with Bing 功能）。这三个查询的共同点是：答案不存在于单篇文档中，必须综合多方数据、进行数值推理才能得出。
三个模型挑战招股书中的矛盾点，只有Grok 3没被表面数据骗
下表是我记录的测试结果，重点关注是否发现矛盾、推理步骤是否合理、以及最终结论的可靠程度：
| 测试查询 | Grok 3 DeepSearch | GPT-4o + Bing | Claude 3.5 Sonnet + Perplexity |
|---|---|---|---|
| 找出苹果2023年供应链责任报告中自相矛盾的碳排放数据 | 成功识别：报告声称范围三减排32%，但同一报告附件里供应商实际排放增长14%。模型自动计算了差异并标注了数据源页码。 | 只总结了正面数据，未发现矛盾，引用源缺失页码。 | 含糊提到“存在不一致”，但无法具体指出数字，理由为“需要更多上下文”。 |
| 对比AMD和Intel 2023年Q4财报中关于数据中心GPU收入的非GAAP调整项，谁更激进？ | 给出了详尽的调整项表格，并量化了“激进指数”：AMD调整后营收提升19%，Intel仅6%。引用了两家财报的附注原文。 | 给出了调整项描述，但未量化对比，错误地说Intel调整更激进（与事实相反）。 | 正确描述了AMD的调整项，但遗漏了Intel的类似项目，分析不完整。 |
| 某家未上市公司的估值模型：基于公开的行业数据，判断其C轮融资估值的合理性（需推算隐含PS倍数） | 自动从PitchBook拉取可比公司倍数，计算隐含PS为12x，指出高于行业75分位10x，结论“高估”。所有数据可追溯。 | 给出了泛泛的“估值偏高”，但PS倍数算错了（用了错误的分母），且无数据来源。 | 拒绝直接计算，只提供了估值方法论，无法给出具体结论。 |
我特别说一下第二个查询的翻车实录。我让GPT-4o和Claude 3.5 Sonnet分别联网搜索AMD和Intel的财报。GPT-4o通过Bing检索到了AMD财报的新闻稿，但新闻稿里highlight的是非GAAP数据，它直接把调整后的营收当成了GAAP来对比，于是得出Intel调整更激进的错误结论——实际上Intel的非GAAP调整幅度远小于AMD。Claude 3.5 Sonnet的分析倒是四平八稳，但它漏掉了Intel财报里一个关键的“重组费用”调回，导致分析缺了一半。Grok 3则把两家公司完整的10-K文件全部检索到，然后自己解析附注中的Non-GAAP Reconciliation表格，逐个对齐调整项，最后给出了可复现的计算过程。这个差别不是语言模型的推理能力更强，而是DeepSearch的检索策略：它是带着“找到GAAP到非GAAP的调节表”这个明确意图去搜索的，而不是泛泛地搜索“Intel 2023 Q4 earnings”。
Claude 3.5 Sonnet与GPT-4o的翻车实录
为了公平，我写了一个简单的LangChain脚本来复现两个模型的表现，代码大概这样：
# 用LangChain模拟GPT-4o + 联网搜索
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI
from langchain.retrievers import BingSearchRetriever
llm = OpenAI(model="gpt-4o", temperature=0)
retriever = BingSearchRetriever(k=5)
qa = RetrievalQA.from_llm(llm=llm, retriever=retriever)
result = qa.run("对比AMD和Intel 2023 Q4数据中心GPU收入非GAAP调整项")
print(result) # 输出有明显错误
这个脚本跑出来的结果是，GPT-4o经常把Bing上搜到的分析师摘要当成财报原文，而分析师摘要里很多数字被二次加工过，这就注定了它不可能得出可靠结论。而Claude 3.5 Sonnet通过Perplexity API调用时，虽然能访问到更多原始PDF链接，但它缺乏自己读取PDF表格的能力，只能依赖Perplexity的预处理摘要，同样在精细数据上翻车。（延伸阅读：我在长文档上试了DeepSeek NSA的11倍加速，结果一个路由参数选错，模型直接答非所问——今天把这坑给你标清楚）
Grok 3的架构之所以能避开这些坑，是因为它自带了一个文档解析引擎，能直接读取PDF中的表格，并把结构化数据存入推理上下文中。这对于金融文档里的复杂表格来说，是个硬需求。
开源承诺是开发者的定心丸，还是又一个空头支票？
xAI宣布Grok 3的推理引擎会在下季度开源，社区已经炸了锅。但作为一个被Meta的Llama开源“骗”过两次的人（说好的代码多模态，半年后才放出beta），我对这类承诺持保留态度。这次xAI开源的是模型权重还是仅开源推理框架？如果只开源一套DeepSearch的编排代码，而把训练数据、搜索索引的构建方案扣下，那对开发者而言，就等于发了一把没子弹的枪。
我评估开源的影响时，主要看两点：第一，能否本地部署后替换掉自己项目里的LangChain+向量库方案；第二，社区能不能基于它做出垂直领域的搜索推理引擎，比如医疗文献或专利审查。从Grok 3的实际表现看，它的优势不只是模型本身，而是那份巨大的、实时更新的搜索索引。如果索引不开放，开发者只能在自己小的文档库里跑推理，效果会大打折扣。所以，我对开源承诺的态度是：如果只开源皮囊，不开放筋骨，那它最终只会变成一个昂贵的内部工具，而不是可以繁荣的生态。
最后想说的是，Grok 3的DeepSearch给我的编程工作流也带来了启发。我已经开始尝试用它的推理链思路改进自己项目的RAG模块：不再是“查到了喂给模型”，而是“查完之后先让模型自检一下矛盾”。这个思路我已经用LangGraph搭了原型，下周应该能在工厂的合同审阅系统里跑起来。这才是实测一个工具之后，真正有价值的收获。
