以下摘要由GPT-4o生成:
自2022年11月ChatGPT发布后，基于Transformer的LLM技术迅速发展，但早期LLM在回答即时性问题时存在局限性，容易出现幻觉或无法获取最新信息。为了解决这些问题，提示词工程（Prompt Engineering）技术应运而生。进一步地，通过构建检索增强生成（RAG）系统并结合工具调用（Tool Use）功能，AI能够实时访问网络信息或企业内部私有数据，大幅优化了回答的准确性与时效性。然而，在实际落地中仍面临数据处理、向量检索阈值设置、工具调用容错等诸多工程挑战。未来的分享将探讨模块化RAG与Agentic RAG等进阶内容。

自2022年11月ChatGPT发布以来，以Transformer为核心的大语言模型（LLM）技术迎来了爆发式的发展。如今，我们在日常生活中经常使用DeepSeek、Qwen、Kimi等大模型来解答各种疑惑。

传统LLM存在的局限性

然而，在早期的LLM中（即尚未引入联网搜索 Web Search 和检索增强生成 RAG 之前），我们会发现AI在回答问题时，常常会出现“幻觉”或给出过时的信息。

比如用户提问：

    1. “今天西安天气怎么样？”
    1. “XXX公司XX工具如何使用？”
    1. “西安2026年5月最新重要新闻都有哪些？”

AI可能回复：

    1. “西安今天天气55度”或者“你好，我无法查询天气，我的知识库截止时间为2025年5月。”
    1. “你好，我不了解XXX公司的具体内部工具信息。”
    1. “你好，我无法了解最新的新闻信息，因为我的知识库截止时间为2025年5月。”

之所以会出现这些问题，本质上是因为LLM的工作原理类似于“词语接龙”，它仅能基于预训练阶段见过的数据生成回答，无法实时获取最新信息或外部领域的私有知识。

一种简单的解决方式是：在提问时，直接将AI所需的背景信息提供给它。比如在提问时附带上“今天西安的天气是31度”，这样AI在进行推理时就能参考这些最新信息进行交流。

举个例子：

  1. 你问AI：“你好，我是mcc。”
    AI回复：“你好，mcc，有什么可以帮助你的吗？”

  2. 你问AI：“你好，我今天准备去户外玩，今天西安天气31°。”
    AI回复：“今天西安天气较热，温度达到31度，户外活动请注意避暑和降温。”

这种通过精心设计提示词（Prompt）来引导大模型生成预期输出的技术，被称为提示词工程（Prompt Engineering）。一些高阶的提示词技术包括：

  • 让LLM把大任务拆分为可逐个求解的小任务，一步一步执行（Step By Step）。
  • 让LLM在给出最终答案前先输出思考过程，基于思考脉络回答原始问题（Chain of Thought, CoT）。
  • 给予模型少量示例参考，让它照葫芦画瓢作答（Few-shot learning）。

突破传统LLM局限的解决方案

为了让AI给出准确且实时的回答，我们需要解决的核心问题是：如何让AI自主获取最新的网络信息或企业内部的私有信息？

1. 应对企业内部私有数据的挑战（RAG技术）

模型在预训练阶段无法接触到企业的内部私有数据。我们不可能每次都手动查好内部资料再喂给AI让它总结（这属于本末倒置）；同时，我们也不能把整个企业文档直接丢给大模型，因为这很容易超出模型的上下文长度限制（Context Window，尽管目前已有支持1M上下文的模型，但成本和延迟依然很高）。

因此，我们需要在后端程序中进行预处理：提前构建企业专属知识库。当用户提问时，系统会先在知识库中检索与问题相关的信息，然后将检索到的数据片段与用户的提问拼接成一个完整的Prompt交由AI处理。此时，AI便拥有了问题背后的背景知识，从而给出精准的回答。这种技术即为检索增强生成（Retrieval-Augmented Generation，简称RAG）。

构建RAG系统涉及四个核心流程：

  1. 数据收集与处理：将企业内部文档解析并进行智能切块处理。
  2. 向量转换与存储：使用Embedding模型将文本块转换为向量，并存储至向量数据库中。
  3. 向量检索与召回：将用户的提问转为向量，并从数据库中检索出最相似的数据块。
  4. 回答增强与生成：将检索到的数据块内容作为上下文，连同用户问题一起输入LLM，生成最终回答。

借助RAG，LLM已经可以顺利解答企业内部的专属问题了。但这依然无法完全解决对时效性要求极高的问题，例如：“今西安天气多少度？” 或 “西安2026年5月最新新闻有哪些？”。

2. 解决信息时效性问题（Tool Use / Function Calling）

对于实时性极强的信息，我们不可能将其随时同步构建到知识库中。因此，我们引入了工具调用（Function Calling / Tool Use）能力。

简单来说，就是提前赋予模型使用工具（如网页搜索 Web-search、天气查询 get_weather 等）的能力。我们只需与LLM约定一种交互格式（通常是基于模型经过微调后具备的结构化JSON输出能力），例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
{
	"type": "function",
	"function": {
		"name": "NAME",
		"description": "DESCRIPTION",
		"parameters": {
			"type": "object",
			"properties": {
				
			}
		}
	}
}

在上述定义中，工具提供方需要详细定义各个字段。其中 description 描述了工具的作用和适用场景，以便大模型判断何时该使用它；parameters 定义了成功调用该工具所需的具体参数。大模型在理解上下文后，会严格按照 JSON Schema 生成带有相应参数（arguments）的 JSON 对象，以此来发起工具调用。

以Web Search查询“最新西安5月重要新闻”为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
	"type": "function",
	"function": {
		"name": "search",
		"description": "通过搜索引擎搜索互联网上的内容。当你的知识无法回答用户提出的问题，或用户请求你进行联网搜索时，调用此工具。请从与用户的对话中提取用户想要搜索的内容作为 query 参数的值。搜索结果包含网站的标题、网址及简介。",
		"parameters": {
			"type": "object",
			"required": ["query"],
			"properties": {
				"query": {
					"type": "string",
					"description": "用户搜索的内容，请从用户的提问或聊天上下文中提取。"
				}
			}
		}
	}
}

简而言之，LLM调用工具的全过程如下：

  • 第一轮交互：

    • User：2026年5月西安最新新闻有哪些？
    • AI：判断需要最新信息，输出工具调用指令 tool_use(web_search(query="2026年5月西安最新新闻"))
    • System：拦截指令并执行搜索，返回结果：Tool result(1. 某某地方20号线通车了，方便出行，URL: www.example.com；2. 西安未来投资20亿着重发展互联网企业，URL: www.example2.com)

  • 第二轮交互：

    • System：将第一轮对话、工具调用的过程以及返回的检索结果全部投递给大模型。
    • AI：结合最新信息生成最终回答：“根据最新消息，西安5月的重要新闻有：1. 某某地方20号线已通车，市民出行更加方便；2. 西安计划投资20亿，着重发展互联网企业等。”

总结与工程挑战

通过引入RAG技术和Tool Use功能，我们能在向LLM提问时动态补充背景信息和实时数据，从而大幅提升回答的准确性与时效性，有效降低模型的“幻觉”。然而，在实际的工程落地中，仍然面临诸多细节挑战：

RAG 面临的挑战

  • 数据收集与处理：
    • 企业文档格式繁多（PDF、Word、Markdown等），程序需具备多格式解析能力。
    • 如何进行智能切块（Chunking）？例如，确保切块时不会将完整的URL链接截断。
    • 相邻的文本块之间，重叠度（Overlap）大小该如何合理设置？
  • 向量转换与存储：
    • 向量维度应设置为多少？（如1024或2048维）。
    • 是使用传统的PostgreSQL（搭配pgvector），还是选择Milvus等专业的向量数据库？
    • Embedding模型如何选择？针对中文偏多的知识库，需挑选对中文更友好的向量模型。
  • 向量检索与召回：
    • 向量检索的相似度阈值如何设置？是0.5还是0.6更合适？
    • 若用户提问（Query）表述不清，该如何进行问题改写（Rewrite）？
    • 如何将用户的单一问题扩展（Expand）为多个方向进行并行检索？
    • 跨语言检索问题：用户用英文提问，而知识库是中文的，如何提前处理转换？
    • 多路并行检索后如何去重？如何通过MMR算法兼顾结果的相关性与多样性？
    • 如何通过父子块（Parent-Child Chunks）检索策略确保信息的语序和上下文完整？
    • 意图消歧与排序问题：知识库A包含“XX工具使用教程”，知识库B包含“入职流程”。当用户提问“入职流程”（流程中涉及领取某工具）时，系统该如何区分主次并排序？
    • 如何引入Reranker模型对初步召回的数据块进行二次精准排序（精排）？
  • 回答增强与生成：
    • 上下文干扰：即使检索到了正确的文本块A，但由于输入给大模型的上下文过长，大模型可能依然未基于该文本块作答。
    • 检索召回为空：若检索阈值设置过高导致无数据召回，AI是否会在缺乏背景知识的情况下强行回答（从而产生幻觉）？

Tool Use 面临的挑战

  • 容错处理： 当工具调用失败或大模型指令遵循能力不佳，输出无法解析的非结构化数据时，系统该如何兜底处理？
  • 调用时机不准： 用户明明询问“最新新闻”，但模型却没有调用 web_search 工具。这是否是因为工具的描述（Description）不够清晰，或是参数说明存在歧义？
  • 工具路由问题： 若系统集成了大量工具，所有的工具描述会占据过多的上下文空间，此时大模型该如何快速、准确地选择需要的工具？

未来的分享中，我们将进一步探讨模块化RAG与Agentic RAG的演化，以及Agent Memory（智能体记忆）和长线任务（Long-running Task）的产生背景与解决方案，敬请期待！