ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

06_为什么我没用LangChain_三节速览后的对照

06_为什么我没用LangChain_三节速览后的对照 为什么我没用 LangChain三节速览之后的对照你为什么不用 LangChain这是 LLM 应用岗几乎必问的一题。常见的两个回答都不太好「我觉得它太重了」——这是没看过就下的结论「自己写更可控」——太笼统追问两句就没了。正确的回答是我知道它封装了什么我为什么在这个场景选择自己写。而这两句话的前提是你真的去看过。下面是我看完 Chat models / Output parsers / Tool calling 三节之后整理的对照。一、五个环节的对照环节LangChain我写的差别在哪调用层ChatOpenAI封装 SDKapp/llm.py纯标准库 urllibSDK 帮你处理重试与序列化自己写省一个依赖且错误码映射能按业务说话结构化输出PydanticOutputParser 重试链completion.py剥 fence → Pydantic 校验 → 把错误喂回去自修框架的 parser 通用但报错抽象自己写能把「上一次错在哪」原话回传工具调用tool装饰器自动生成 schematools.py手写 schema Pydantic 参数模型装饰器省事但描述质量不可控手写能写清「什么时候不该调用」循环编排LangGraph/AgentExecutoragent.pywhile 循环 max_turns 熔断框架适合复杂分支单链路工具调用手写更短、更可控成本可观测callback / tracer成本账本 X-Cost-CNY响应头 trace框架要额外接自己写的从第一天就在响应头里调用层# LangChainfromlangchain_openaiimportChatOpenAI llmChatOpenAI(modeldeepseek-flash,base_url...,api_key...)# 我的rescall_chat(s,messages,providerdeepseek,modeldeepseek-flash)差别不在代码量在错误发生后的信息量。SDK 抛的是APIConnectionError之类我抛的是deepseek 返回 HTTP 429触发限流免费模型通常并发为 1改成串行调用加上retryableTrue这个标记上层直接知道该不该重试。结构化输出这是我觉得差别最大的一环。框架的重试链通常是「解析失败 → 再生成一次」而我是把上一次的错误原话喂回去REPAIR_TEMPLATE你上一次的输出没有通过结构化校验 error{error}/error last_output{raw}/last_output 请修正后重新输出只输出 JSON 对象本身。重新生成模型不知道自己上次错在哪喂回错误它看到了confidence 超出 0–1下一次就知道收敛。这跟人改代码一个道理。工具调用tool装饰器从函数签名和 docstring 自动生成 schema很省事。但代价是描述质量不由你控制tooldefget_current_weather(city:str)-str:查询某个城市当前的天气实况。这个 docstring 里没写未来预报不要调它而这一句恰恰是稳定调用的关键实测写了之后模型在没给订单号时不会编造而是反问用户。手写 schema 麻烦但你能把五条规则都落实进去。二、真正的判断标准框架解决的是「从零到一」我这项目已经过了那个阶段要的是可控、可观测、能报成本。而这三点恰恰是框架封装掉、出问题最难查的部分成本藏在 callback 里要额外接才看得见降级链要自己搭框架不管主用挂了换哪家出问题时框架的抽象层反而挡在中间。反过来如果明天要做多分支、多智能体、带人工确认的复杂流程就该上 LangGraph别为了自己写的而自己写。知道什么时候该用框架比不用框架更值钱。三、三个可以量化的对照数据同一个两跳问题先统计、再查明细我的实现实测项值轮数4工具调用次数4成本¥0.004433延迟3.457strace 可见是框架侧跑同样的任务你得到的是AIMessage要看中间过程得挂 callback。这不是说框架不好是说两者的可观测性起点不同。四、顺带RAG 语料该怎么选既然讲到选型把另一个技术决策也记下来。选 RAG 语料时我用了三条硬标准有规则冲突—— 同一件事在不同文档里写法不同才能测出检索与综合的能力有适用范围约束—— 哪些模型支持什么这类有边界的问题你能判断答案对错—— 这一条最重要也最容易被忽略。第三条决定了你能不能做出高质量的 golden set。很多人选语料只看内容够不够多结果标注时自己也不知道标准答案是什么。我的选择是三家 LLM 平台官方 API 文档前两条天然满足第三条因为过去一周亲手实测过几乎所有相关事实而成立。另外一条经验先看能不能拿到再看合不合适。我在选型当天就跑了可得性探测BFS 两层 正文长度判定确认三家都可达、平均 2600–3650 字/篇才定下来。否则到开抓那天才发现是 JS 渲染整个计划就废了。小结问题我的答案为什么不用 LangChain我知道它封装了什么这阶段我要可控、可观测、能报成本什么时候该用多分支、多智能体、带人工确认的复杂流程最值钱的一句知道什么时候该用框架比不用框架更值钱上一篇LLM 成本精算。
返回列表