LangChain 采购智能 AI 应用

自学实战项目：用 LangChain 搭一个采购智能应用——RAG 检索企业采购文档，LLM 做意图识别，按意图路由到不同 Agent 执行，回答附引用来源。

意图分类4 类

向量检索Chroma

Agent 模式ReAct

背景

这是一个自学性质的实战项目，目的很直接：把 LLM 从"聊天玩具"落到一条真实业务流上，亲手踩一遍 RAG、意图识别、Agent 这三件套的坑。采购场景是个好试验田——文档多（价格表、库存、订单、退换政策）、用户意图杂（询价、下单、查单、退换）、且回答必须可追溯来源，瞎编一个报价就是事故。

问题

1. 文档是静态的，问题是开放的：采购文档几十份，用户不会按文档目录提问，关键词搜索对"这玩意多少钱能不能便宜点"这类口语化输入基本失效。
2. 意图混杂：一句话可能既是询价又是下单（"这个还有货吗，有就来五十个"），单一问答链处理不了。
3. 多步操作：下单要先查库存再生成订单，不是一次检索一次生成能完成的。
4. 可信度：报价类回答必须能指回价格表原文，否则业务方不敢用。

方案

整体架构是"意图识别 → Agent 路由 → RAG + 工具调用 → 带引用的回答"：

flowchart TD
    A["用户采购需求"] --> B["意图识别<br>LLM + few-shot"]
    B --> C{"路由"}
    C --> D["询价 Agent<br>RAG 检索价格表"]
    C --> E["下单 Agent<br>校验库存 + 生成订单"]
    C --> F["查单 Agent<br>检索订单库"]
    C --> G["退换 Agent<br>检索退换政策"]
    D --> H["生成回复<br>含引用来源"]
    E --> H
    F --> H
    G --> H

技术栈：LangChain（Python）做编排，LLM 用本地开源模型 + API 调用混合，向量库 Chroma，Agent 用 ReAct 模式（推理 + 行动循环）。

关键实现

RAG：检索增强生成

# 采购文档向量化入库
vectorstore = Chroma.from_documents(
    documents=docs,
    embedding=OpenAIEmbeddings()
)

# 检索 + 生成
retriever = vectorstore.as_retriever()
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever
)

意图识别：LLM 替代传统分类器

intent_prompt = """根据用户输入判断意图：
- 询价：询问产品价格
- 下单：想购买产品
- 查单：查询订单状态
- 退换：需要退货或换货

用户输入：{input}
意图："""

intent = llm.predict(intent_prompt.format(input=user_input))

不用训练分类模型，靠 prompt + few-shot 示例就能覆盖口语化表达；但 few-shot 示例的质量直接决定边界 case 的准确率，例子得覆盖"一句话两个意图"的情况。

Agent：按意图挂载工具集

每个 Agent 有自己的工具集，ReAct 循环决定调哪个、调几次：

• 询价 Agent：search_prices()、compare_products()
• 下单 Agent：check_stock()、create_order()
• 查单 Agent：query_order_db()

下单这种多步任务最能体现 ReAct 的价值：模型先推理"需要先确认库存"，调 check_stock()，拿到结果后再决定是生成订单还是回复缺货。

指标

项目是自学验证性质，没有线上量化指标，留下的是可复用的能力验证结论：

能力	验证结论
意图识别	4 类意图用 LLM + few-shot 可稳定分类，免训练
RAG 问答	回答可附引用来源，报价类回答可回溯到价格表原文
多步任务	ReAct Agent 能完成"查库存 → 下单"这类工具链调用

复盘

1. RAG 的瓶颈在检索质量，不在模型。文档切片策略（按语义块还是按固定长度、带不带表头上下文）对答案质量的影响远大于换模型。切片没调好，换再大的模型也是在垃圾检索结果上编。
2. 意图识别用 LLM 比传统分类器灵活，但 few-shot 示例是隐性成本。意图边界变了改示例就行，不用重训——但示例库本身得有人维护。
3. Agent 不是万能胶水。多步任务上 ReAct 确实好用，但单步简单查询走 Agent 反而增加延迟和 token 消耗；路由层存在的意义就是把简单请求挡在 Agent 之外。
4. 这套"意图识别 → 路由 → 工具调用 + 确认"的骨架后来直接复用到了飞书 Agent 的意图三层安全路由设计上——区别是生产环境里 LLM 的输出必须再过确定性解析器，不能直连执行。