本文讲解如何突破 rag 的局限性，通过 openai 函数调用（tools）机制让 llm 主动触发 python 原生逻辑（如邮件数量统计），从而准确回答“多少封”“是否发送过”等需精确计算而非语义匹配的问题。
本文讲解如何突破 rag 的局限性，通过 openai 函数调用（tools）机制让 llm 主动触发 python 原生逻辑（如邮件数量统计），从而准确回答“多少封”“是否发送过”等需精确计算而非语义匹配的问题。
在基于 LangChain 构建的邮件智能问答系统中，RAG（检索增强生成）是处理语义型问题（如“我上次给谁发了关于合同的邮件？”）的理想方案——它通过向量相似度召回最相关的几封邮件内容，再交由 LLM 理解并归纳作答。但正如你在实践中发现的：当问题转向结构化统计（例如“张三给我发了多少封邮件？”）或布尔判断（例如“2024 年 3 月是否有来自财务部的未读邮件？”）时，单纯依赖相似性检索会失效。原因在于：
- FAISS 检索返回的是语义最接近的 k 个文档片段（默认仅 3 条），无法覆盖全量数据；
- LLM 的上下文窗口有限，无法承载数百封邮件的原始内容；
- 更关键的是：这类问题本质不依赖“理解内容”，而依赖“执行查询”——它需要的是数据库式的精确计数，而非语言模型的文本推理。
✅ 正确解法：引入 Function Calling（函数调用），也称 Tool Use（工具调用）。它让 LLM 充当“智能调度员”：分析用户意图 → 判断是否需调用外部工具 → 生成结构化工具调用请求（含参数）→ 你用 Python 执行真实逻辑 → 将结果回填给 LLM 生成最终自然语言回答。
以下是整合到 LangChain 工作流中的关键实践步骤：
1. 定义可调用工具（Python 函数）
首先编写一个真正能查询邮件数量的函数（以 IMAP 为例）：
import imaplib
import email
from email.header import decode_header
def count_emails_by_sender(email_address: str, username: str, password: str, imap_server: str = "imap.gmail.com") -> int:
"""安全地连接邮箱并统计指定发件人的邮件数量（简化版，生产环境请加异常处理与 SSL）"""
try:
mail = imaplib.IMAP4_SSL(imap_server)
mail.login(username, password)
mail.select("inbox")
# 搜索发件人包含该地址的邮件（IMAP SEARCH 支持模糊匹配）
status, messages = mail.search(None, f'FROM "{email_address}"')
if status == "OK":
msg_ids = messages[0].split()
return len(msg_ids)
return 0
except Exception as e:
print(f"邮件统计失败: {e}")
return 0
finally:
try:
mail.logout()
except:
pass
2. 在 LangChain 中注册工具
LangChain v0.1+ 提供 StructuredTool 或直接使用 ChatOpenAI.bind_tools() 集成。推荐方式如下：
from langchain_core.tools import StructuredTool
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field
class EmailCountInput(BaseModel):
email_address: str = Field(description="目标发件人的完整邮箱地址，如 'alice@example.com'")
# 将函数包装为 LangChain 工具
email_count_tool = StructuredTool.from_function(
func=lambda addr: count_emails_by_sender(addr, "your@gmail.com", "your_app_password"),
name="count_emails_by_sender",
description="统计收件箱中来自指定发件人的邮件总数。输入必须是标准邮箱格式。",
args_schema=EmailCountInput,
)
# 初始化支持工具调用的 LLM
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
llm_with_tools = llm.bind_tools([email_count_tool])
3. 构建带工具调用的链式流程
避免手动解析 JSON，使用 LangChain 的 AgentExecutor 自动处理工具选择、执行与结果注入：
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个专业的邮件助理。请优先使用提供的工具完成精确查询；仅当工具无法满足时，才基于已有知识作答。"),
("human", "{input}"),
MessagesPlaceholder(variable_name="agent_scratchpad"), # 存储工具调用历史
])
agent = create_openai_tools_agent(llm_with_tools, [email_count_tool], prompt)
agent_executor = AgentExecutor(agent=agent, tools=[email_count_tool], verbose=True)
# 执行查询（自动触发工具）
result = agent_executor.invoke({
"input": "How many mails have been sent by alice@example.com?"
})
print(result["output"]) # 输出类似：共收到 17 封来自 alice@example.com 的邮件。
⚠️ 注意事项与最佳实践
- 安全第一：切勿在提示词或工具参数中硬编码邮箱密码；应使用环境变量（os.getenv("EMAIL_PASS")）或密钥管理服务。
- 工具粒度：为不同统计需求（按发件人、收件人、日期范围、主题关键词）分别定义工具，保持单一职责。
- Fallback 机制：在 AgentExecutor 中设置 handle_parsing_errors=True，防止 LLM 输出格式错误导致中断。
- 性能优化：对高频查询（如“本月邮件数”）可增加本地缓存层（如 functools.lru_cache），避免重复 IMAP 连接。
- RAG + Tools 混合策略：复杂问题（如“列出张三近一周发的所有含‘发票’的邮件”）可先用工具获取 ID 列表，再用 RAG 加载对应邮件正文——二者互补，而非互斥。
总结来说，你的“失误”并非代码错误，而是对 RAG 能力边界的认知偏差。真正的 AI 应用不是非此即彼（RAG or not），而是构建多模态能力协同体：用向量检索解决“是什么”，用函数调用解决“有多少/有没有/怎么做”。掌握这一范式，你的邮件助手将从“语义搜索引擎”进化为“可操作的智能代理”。
