语义路由：为不同问题选择 Prompt 模板

根据问题语义选择不同 Prompt、模型或处理链路。

在 RAG 应用开发中，针对不同场景的问题使用 特定化的prompt模板 效果一般都会比通用模板会好一些，例如在 教培场景，制作一个可以教学 物理+数学 的授课机器人，如果使用通用的 prompt模板，会导致 prompt 编写变得非常复杂；反过来如果 prompt 写的简单，有可能没法起到很好的回复效果。

如果能针对用户的提问，例如用户提问的内容是数学相关的则使用数学的模板，提问的内容是物理相关的则使用物理的模板，针对性选择不同的模板，LLM 生成的内容会比使用通用模板会更好，例如下方有两个 prompt模板：

physics_template = """你是一位非常聪明的物理教授。
你擅长以简洁易懂的方式回答物理问题。
当你不知道问题的答案时，你会坦率承认自己不知道。

这是一个问题：
{query}"""
math_template = """你是一位非常优秀的数学家。你擅长回答数学问题。
你之所以如此优秀，是因为你能将复杂的问题分解成多个小步骤。
并且回答这些小步骤，然后将它们整合在一起回来更广泛的问题。

这是一个问题：
{query}"""

基于这个思想和我们前面掌握的 向量 与 文本嵌入模型，我们其实可以猜测，提问如果是 数学问题(能介绍下余弦计算公式么？)，在向量空间上，正常情况下和 数学模板 的向量靠的更近；映射到 物理问题(黑洞是什么?) 上也是一样的。

用前面的 猫猫向量 表示就是更接近，相似度更高，如下：

所以利用向量执行相似性搜索，不仅可以作用于 向量数据库，我们还可以利用 原始问题 与 prompt模板 的相似性，来找到类型、语义上更接近的模板，从而实现对 prompt模板 的动态路由。

该语义路由的运行流程其实也非常简单，如下：

在 LangChain 中，实现的代码示例如下：

import dotenv
from langchain.utils.math import cosine_similarity
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough, RunnableLambda
from langchain_openai import OpenAIEmbeddings, ChatOpenAI

dotenv.load_dotenv()

# 1.定义两份不同的prompt模板(物理模板、数学模板)
physics_template = """你是一位非常聪明的物理教程。
你擅长以简洁易懂的方式回答物理问题。
当你不知道问题的答案时，你会坦率承认自己不知道。

这是一个问题：
{query}"""
math_template = """你是一位非常优秀的数学家。你擅长回答数学问题。
你之所以如此优秀，是因为你能将复杂的问题分解成多个小步骤。
并且回答这些小步骤，然后将它们整合在一起回来更广泛的问题。

这是一个问题：
{query}"""

# 2.创建文本嵌入模型，并执行嵌入
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
prompt_templates = [physics_template, math_template]
prompt_embeddings = embeddings.embed_documents(prompt_templates)

def prompt_router(input) -> ChatPromptTemplate:
 """根据传递的query计算返回不同的提示模板"""
 # 1.计算传入query的嵌入向量
 query_embedding = embeddings.embed_query(input["query"])

 # 2.计算相似性
 similarity = cosine_similarity([query_embedding], prompt_embeddings)[0]
 most_similar = prompt_templates[similarity.argmax()]
 print("使用数学模板" if most_similar == math_template else "使用物理模板")

 # 3.构建提示模板
 return ChatPromptTemplate.from_template(most_similar)

chain = (
 {"query": RunnablePassthrough()}
 | RunnableLambda(prompt_router)
 | ChatOpenAI(model="gpt-3.5-turbo-16k")
 | StrOutputParser()
)

print(chain.invoke("黑洞是什么?"))
print("======================")
print(chain.invoke("能介绍下余弦计算公式么？"))

输出内容：

使用物理模板
黑洞是一种极为密集的天体，其引力非常强大，甚至连光都无法逃离它的吸引力。黑洞形成于恒星坍缩或者质量非常大的天体的坍塌过程中。在黑洞的中心，存在一个称为“奇点”的点，其中物质密度无限大，空间弯曲度也达到了极限。黑洞周围的区域被称为“事件视界”，在这个视界内，一切进入的物质都无法逃脱黑洞的吸引力。黑洞是宇宙中极为神秘而又引人入胜的天体。
======================
使用数学模板
余弦（cosine）计算公式是三角函数中的一种，用于计算一个三角形的两个边长和夹角之间的关系。

在一个直角三角形中，余弦的定义是：余弦值等于直角边上的斜边与该直角边的比值。

余弦的计算公式如下：
cos(θ) = adjacent / hypotenuse

其中，θ表示夹角的大小（以弧度为单位），adjacent表示夹角边的邻边长度，hypotenuse表示斜边的长度。

需要注意的是，余弦计算公式只适用于直角三角形，当夹角不是直角时，需要使用其他三角函数（如正弦、正切等）来计算。

通过将复杂的问题分解成小步骤，我们可以先计算出夹角的余弦值，然后再将其应用到更广泛的问题中，如求解三角形的面积、边长等。

最新版 LangChain 用法提示

新项目要优先确认组件所在包名。核心抽象通常在 langchain_core，文档分割在 langchain_text_splitters，OpenAI 相关集成在 langchain_openai，大量社区组件在 langchain_community 或独立集成包中。

涉及 Retriever、Runnable、LCEL、LangGraph 的链路，建议用 invoke() / ainvoke() 作为统一调用入口，并把检索参数、路由条件、重排参数和降级策略显式配置出来。不要只照搬旧导入路径。

拓展

语义路由：为不同问题选择 Prompt 模板 不应该孤立使用。RAG 优化通常要和评测集、召回日志、答案引用、用户反馈、成本统计一起看。只优化某一个环节，可能会让另一个环节退化。

工程上建议把 query、改写后的 query、召回文档、metadata filter、重排得分、最终 Prompt 和模型输出都记录下来。否则问题出现时，很难判断是加载、切分、Embedding、检索、重排、Prompt 还是生成阶段出了问题。

常见问题

什么时候需要使用这个策略？

当普通向量检索已经不能稳定命中关键证据，或者复杂问题经常漏召回、召回重复、上下文不完整时，就需要引入该类优化。

它能替代基础 RAG 链路吗？

不能。优化策略依赖基础链路。文档质量、chunk 设计、Embedding 模型、metadata 规范和 Retriever 配置没有打好，后续策略只能缓解，不能根治。

如何判断优化是否有效？

用固定评测集对比优化前后：召回命中率、答案正确率、引用正确率、拒答准确率、延迟和成本。只看单个 demo 很容易误判。

面试题

RAG 优化应该从哪里开始？

先定位问题阶段：文档是否解析正确、chunk 是否完整、Embedding 是否适合、检索是否命中、上下文是否可用、模型是否按证据回答。定位后再选择对应策略。

为什么复杂 RAG 系统需要可观测性？

因为答案错误可能来自任意环节。没有检索日志、重排分数、Prompt 和输出记录，就只能靠猜。

如何避免优化策略越加越乱？

每个策略都要有触发条件、输入输出、评测指标和降级方案。能用简单策略解决的问题，不要过早引入复杂链路。

生产问题排查

问题	常见原因	处理方式
优化后更慢	多路检索、重排或图分支增加调用次数	增加超时、缓存、并行和候选裁剪
召回更多但更乱	多查询或混合检索没有去重和重排	使用 RRF、rerank、source_id 去重
答案仍然无依据	上下文质量低或 Prompt 没有约束证据	增加引用要求、拒答策略和证据检查
成本上涨明显	过多 LLM 改写、摘要或评估调用	缓存中间结果，限制触发条件
线上效果不稳定	缺少评测集和回归流程	固化 golden set，发布前跑回归