RAG 之 Prompt 动态选择的三种方式
“如果我有5个prompt模板，我想只选择一个每次都自动五选一能做到吗怎么做？”
完全可以做到。这在复杂的RAG或Agentic工作流中是一个非常普遍且关键的需求，通常被称为“条件路由（Conditional Routing）”或“动态调度（Dynamic Dispatching）”。其核心思想是系统需要根据输入的上下文（Query）或其他中间状态，智能地判断哪一个Prompt模板最适合用于生成最终答案。这远比硬编码一个通用模板要强大，能显著提升LLM在特定任务上的表现。
下面我将详细阐述三种由浅入深、复杂度递增的实现方法，并结合您的技术栈（FastAPI, Python）进行说明。
方法一：基于元数据/规则的路由 (Metadata/Rule-based Routing)
这是最简单、最直接、可解释性最强的方法。它依赖于对输入数据或用户交互的结构化理解。
-
工作原理：
您首先需要为您的五个Prompt模板定义清晰的“适用场景”。这些场景可以被编码为一组规则或元数据。例如，假设您的五个模板分别用于：-
产品功能咨询 (Product Feature Inquiry): 当用户问题明显关于某个具体产品的功能时。
-
价格与套餐对比 (Pricing & Plan Comparison): 当用户问题包含“价格”、“费用”、“订阅”、“套餐”等关键词时。
-
技术集成问题 (Technical Integration Issue): 当用户问题涉及API、SDK、代码、集成等技术术语时。
-
竞品分析 (Competitive Analysis): 当用户提到竞争对手的名字时。
-
通用/兜底模板 (General/Fallback Template): 当以上所有情况都不匹配时。
您的FastAPI后端在接收到前端传来的请求（包含用户问卷回答和个人信息）后，会先通过一个“路由模块”来分析这个请求。这个模块会执行一系列if-elif-else逻辑判断。
-
-
在您的架构中如何实现：
-
定义请求模型： 在您的api/models.py中，使用Pydantic模型来结构化前端的请求。这不仅仅是为了数据验证，更是为了路由。
Generated python 生成的 python# api/models.py from pydantic import BaseModel, Field from typing import List, Literal class UserProfile(BaseModel): industry: str = Field(..., description="用户所在行业") company_size: int = Field(..., description="公司规模") class QuestionnaireAnswers(BaseModel): # 假设问卷中有明确的问题类型 query_type: Literal['feature', 'pricing', 'integration', 'comparison'] = Field(..., description="用户查询的核心类别") keywords: List[str] = Field(default_factory=list, description="从用户回答中提取的关键词") full_text: str class EnhanceRequest(BaseModel): user_profile: UserProfile answers: QuestionnaireAnswers -
实现路由逻辑： 在您的rag_pipeline.py或一个专门的router.py中，创建一个函数来选择模板。
Generated python 生成的 python# rag_pipeline/router.py PROMPT_TEMPLATES = { "feature": "这是产品功能模板: {context} \n\n 用户问题: {question}", "pricing": "这是价格对比模板: {context} \n\n 用户问题: {question}", "integration": "这是技术集成模板: {context} \n\n 用户问题: {question}", "comparison": "这是竞品分析模板: {context} \n\n 用户问题: {question}", "general": "这是通用模板: {context} \n\n 用户问题: {question}", } def select_prompt_template(request: EnhanceRequest) -> str: """根据请求内容选择最合适的Prompt模板""" query_type = request.answers.query_type if query_type == 'feature': return PROMPT_TEMPLATES['feature'] elif query_type == 'pricing': # 还可以增加更复杂的逻辑 if "enterprise" in request.answers.full_text.lower(): # 甚至可以有更细分的模板 pass return PROMPT_TEMPLATES['pricing'] elif query_type == 'integration': return PROMPT_TEMPLATES['integration'] elif query_type == 'comparison': return PROMPT_TEMPLATES['comparison'] else: # 如果前端无法提供明确的query_type，可以退化到关键词匹配 text = request.answers.full_text.lower() if any(kw in text for kw in ['api', 'sdk', 'code']): return PROMPT_TEMPLATES['integration'] # ... 其他关键词规则 return PROMPT_TEMPLATES['general'] # 兜底模板优点：
-
-
-
快速高效： 计算开销极小。
-
完全可控与可预测： 您确切地知道为什么会选择某个模板，便于调试和迭代。
-
实现简单： 不需要复杂的AI模型。
-
-
缺点：
-
僵化： 规则是硬编码的，无法处理模糊或未预料到的用户意图。
-
维护成本高： 随着模板和规则的增多，逻辑会变得非常复杂，难以维护。
-
方法二：基于语义相似度的路由 (Semantic Similarity-based Routing)
当用户输入的意图比较模糊，无法用简单规则判断时，这种方法更优越。它利用了语言模型的“理解”能力。
-
工作原理：
-
模板描述与向量化： 为您的每一个Prompt模板编写一个简短但精确的“描述”。例如，对于“产品功能模板”，描述可以是“这个模板用于回答关于我们产品具体特性的问题”。
-
离线处理： 使用一个预训练的句子嵌入模型（如sentence-transformers库中的模型），将这五个模板的“描述”文本转换成向量，并存储起来。
-
在线查询： 当接收到用户的查询时，同样使用该嵌入模型将用户的查询文本（request.answers.full_text）也转换成一个向量。
-
相似度计算： 计算用户查询向量与所有五个模板描述向量之间的余弦相似度。
-
选择最佳模板： 选择相似度得分最高的那个模板作为本次调用的模板。
-
-
在您的架构中如何实现：
-
安装必要的库： pip install sentence-transformers scikit-learn
-
创建模板描述和向量：
Generated python 生成的 python# rag_pipeline/semantic_router.py from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity import numpy as np class SemanticRouter: def __init__(self): self.model = SentenceTransformer('all-MiniLM-L6-v2') # 一个轻量级但效果不错的模型 self.template_names = ["feature", "pricing", "integration", "comparison", "general"] self.template_descriptions = [ "Answers questions about specific product features, capabilities, and how they work.", "Responds to inquiries about pricing, subscription plans, costs, and billing.", "Handles technical questions related to API usage, SDKs, software integration, and code.", "Provides analysis and comparison against competitor products and services.", "A general-purpose template for questions that do not fit other categories." ] # 离线计算并存储模板描述的向量 self.template_embeddings = self.model.encode(self.template_descriptions) def select_template(self, query_text: str) -> str: query_embedding = self.model.encode([query_text]) # 计算余弦相似度 similarities = cosine_similarity(query_embedding, self.template_embeddings) # 找到分数最高的模板索引 best_template_index = np.argmax(similarities) selected_template_name = self.template_names[best_template_index] # 还可以设置一个阈值，如果最高分都低于阈值，则使用通用模板 if np.max(similarities) < 0.5: return PROMPT_TEMPLATES["general"] return PROMPT_TEMPLATES[selected_template_name] # 使用示例 # router = SemanticRouter() # user_query = "How much does your enterprise plan cost per user?" # selected_prompt = router.select_template(user_query) # print(selected_prompt) # 应该会打印出 pricing 模板
-
-
优点：
-
智能与灵活： 能理解语义，而不是仅仅匹配关键词。用户用不同方式问同一个问题，也能正确路由。
-
易于扩展： 增加新模板时，只需添加描述并重新计算向量即可，无需修改复杂的if-else逻辑。
-
-
缺点：
-
计算开销： 每次请求都需要进行一次向量编码和相似度计算，虽然很快，但比规则法要慢。
-
“黑盒”性： 可解释性不如规则法，有时可能会出现意料之外的路由结果，调试稍难。
-
依赖嵌入模型质量： 路由的准确性完全取决于所选嵌入模型的质量。
-
方法三：LLM作为路由/分类器 (LLM as a Router/Classifier)
这是最强大、最灵活，但也是成本最高、延迟最高的方法。它直接让一个（通常是较小的、快速的）LLM来决定使用哪个模板。
-
工作原理：
您需要设计一个特殊的“元Prompt”（Meta-Prompt）。这个Prompt的任务不是生成最终答案，而是告诉LLM：“你是一个任务分类器。下面是用户的请求，以及几个可用的工具/模板。请判断哪个工具/模板最适合处理这个请求，并以指定的格式（如JSON）返回你的选择。” -
在您的架构中如何实现：
-
设计元Prompt：
Generated pythonMETA_PROMPT = """ You are an expert routing agent. Your task is to analyze the user's query and determine which of the following tools is the most appropriate to use. You must respond with only the name of the chosen tool. Do not add any other text or explanation. Here are the available tools: - "feature_tool": Use this for questions about specific product features and capabilities. - "pricing_tool": Use this for questions about costs, plans, and subscriptions. - "integration_tool": Use this for technical questions about APIs, SDKs, and integration. - "comparison_tool": Use this for questions involving competitor analysis. - "general_tool": Use this for all other general inquiries. User Query: --- {query_text} --- Chosen Tool: """现代的LLM API（如OpenAI, Anthropic）支持“Function Calling”或“Tool Use”功能，这是此方法的更优、更结构化的实现。您可以将每个模板定义为一个“工具”，LLM会返回一个结构化的JSON对象，指明应该调用哪个工具。
-
实现LLM调用逻辑：
Generated python# rag_pipeline/llm_router.py import openai # 假设您已配置好OpenAI客户端 # client = openai.OpenAI(api_key="...") def select_template_with_llm(query_text: str) -> str: # 使用Function Calling/Tool Use会更稳健 response = client.chat.completions.create( model="gpt-3.5-turbo", # 使用一个快速且便宜的模型 messages=[{"role": "user", "content": META_PROMPT.format(query_text=query_text)}], max_tokens=10, temperature=0.0 ) tool_name = response.choices[0].message.content.strip().replace("_tool", "") if tool_name in PROMPT_TEMPLATES: return PROMPT_TEMPLATES[tool_name] else: # 如果LLM返回了意外的结果，进行兜底 return PROMPT_TEMPLATES["general"]
-
-
优点：
-
极高的智能和理解力： 可以处理非常复杂、微妙和长篇的查询，理解上下文的能力最强。
-
最强的适应性： 几乎不需要修改代码就能通过调整元Prompt来改变路由逻辑。
-
-
缺点：
-
成本和延迟： 每次路由都需要进行一次LLM API调用，这会增加金钱成本和响应时间，对于需要快速响应的应用可能是个问题。
-
稳定性： LLM的输出不是100%确定的（即使temperature=0），可能返回意料之外的格式或选择，需要有健壮的错误处理和重试逻辑。
-
结论与建议：
对于一个原型系统，我建议您从**方法一（基于规则）或方法二（基于语义相似度）**开始。
-
如果您的问卷设计得足够结构化，能够明确区分用户意图，方法一是最务实的选择。
-
如果用户输入是开放式的自然语言，方法二是性价比最高的选择，它在智能和成本之间取得了很好的平衡。
-
方法三可以作为未来的一个优化方向，当您发现前两种方法无法满足业务的复杂性时再考虑引入。
技术问题 2：data ingestion 与 intelligent chunking 的关系
问题核心： “data ingestion, intelligent chunking, 二者之间的关系是并列还是包含？”
回答：
这是一个非常好的问题，它触及了RAG管道构建的核心概念。答案是：包含关系。data ingestion（数据摄取）是一个宏观的、端到端的过程，而intelligent chunking（智能分块）是这个过程中至关重要的一个步骤。
把data ingestion想象成一个工厂的生产线，它的目标是把“原材料”（您的原始文档）加工成“标准化的、可用于检索的零件”（带有向量的文本块）。这条生产线包含多个工位，intelligent chunking就是其中一个关键工位。
完整的 Data Ingestion 流程（Pipeline）通常包括以下步骤：
-
数据加载 (Loading):
-
做什么： 从数据源读取原始文件。
-
例子： 从一个Azure Blob Storage容器中读取PDF、Markdown、Word文档、HTML文件，或者从数据库中拉取文本记录。LangChain中的DocumentLoader就是做这个的。
-
-
数据提取与清洗 (Extraction & Cleaning):
-
做什么： 从加载的原始文件中提取出纯文本内容，并进行预处理。
-
例子：
-
从PDF中抽取出文本，忽略页眉、页脚和图片。
-
从HTML中剥离掉
-
-