当前位置：首页 > news >正文

RAG 之 Prompt 动态选择的三种方式

news 2025/7/8 10:08:22

“如果我有5个prompt模板，我想只选择一个每次都自动五选一能做到吗怎么做？”

完全可以做到。这在复杂的RAG或Agentic工作流中是一个非常普遍且关键的需求，通常被称为“条件路由（Conditional Routing）”或“动态调度（Dynamic Dispatching）”。其核心思想是系统需要根据输入的上下文（Query）或其他中间状态，智能地判断哪一个Prompt模板最适合用于生成最终答案。这远比硬编码一个通用模板要强大，能显著提升LLM在特定任务上的表现。

下面我将详细阐述三种由浅入深、复杂度递增的实现方法，并结合您的技术栈（FastAPI, Python）进行说明。

方法一：基于元数据/规则的路由 (Metadata/Rule-based Routing)

这是最简单、最直接、可解释性最强的方法。它依赖于对输入数据或用户交互的结构化理解。

工作原理：
您首先需要为您的五个Prompt模板定义清晰的“适用场景”。这些场景可以被编码为一组规则或元数据。例如，假设您的五个模板分别用于：
1. 产品功能咨询 (Product Feature Inquiry): 当用户问题明显关于某个具体产品的功能时。
2. 价格与套餐对比 (Pricing & Plan Comparison): 当用户问题包含“价格”、“费用”、“订阅”、“套餐”等关键词时。
3. 技术集成问题 (Technical Integration Issue): 当用户问题涉及API、SDK、代码、集成等技术术语时。
4. 竞品分析 (Competitive Analysis): 当用户提到竞争对手的名字时。
5. 通用/兜底模板 (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, Literalclass 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: strclass EnhanceRequest(BaseModel):user_profile: UserProfileanswers: 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_typeif 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)

当用户输入的意图比较模糊，无法用简单规则判断时，这种方法更优越。它利用了语言模型的“理解”能力。

工作原理：
1. 模板描述与向量化： 为您的每一个Prompt模板编写一个简短但精确的“描述”。例如，对于“产品功能模板”，描述可以是“这个模板用于回答关于我们产品具体特性的问题”。
2. 离线处理： 使用一个预训练的句子嵌入模型（如sentence-transformers库中的模型），将这五个模板的“描述”文本转换成向量，并存储起来。
3. 在线查询： 当接收到用户的查询时，同样使用该嵌入模型将用户的查询文本（request.answers.full_text）也转换成一个向量。
4. 相似度计算： 计算用户查询向量与所有五个模板描述向量之间的余弦相似度。
5. 选择最佳模板： 选择相似度得分最高的那个模板作为本次调用的模板。

在您的架构中如何实现：

安装必要的库： 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 npclass 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 python

      META_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中剥离掉<script>, <style>等无关标签，只保留正文内容。
  - 去除多余的空格、换行符、特殊字符等噪声。
  - 您的data_processing/cleaner.py脚本就负责这个阶段。
文本分块 (Chunking / Splitting):
- 做什么： 这是intelligent chunking发生的阶段。将清洗后的长文本分割成一系列更小的、有意义的、大小合适的文本块（chunks）。
- 为什么重要：
  - 嵌入模型限制： 大多数嵌入模型有输入长度限制（如512个token）。你不能把一篇万字长文直接扔进去。
  - 检索精度： 如果块太大，包含太多不相关信息，检索时会引入噪声，降低答案质量。如果块太小，可能丢失上下文，导致检索到的信息不完整。
- “智能”体现在哪里：
  - 普通分块 (Naive Chunking): 按固定字符数（如1000个字符）或固定token数进行硬切分。这种方法简单粗暴，很容易把一个完整的句子或段落从中间切断，破坏语义。
  - 智能分块 (Intelligent Chunking):
    - 递归字符分块 (Recursive Character Text Splitter): LangChain中常用的方法。它会尝试按一系列分隔符（如\n\n, \n, ）进行分割，优先使用最能保持语义完整性的分隔符，是一种更优的策略。
    - 基于语义/句子的分块 (Semantic/Sentence Chunking): 使用NLTK或spaCy等NLP库，按句子边界进行分割，确保每个块都是完整的句子。
    - 基于文档结构的分块 (Layout-aware Chunking): 这是更高级的方法。例如，对于Markdown，可以使用MarkdownHeaderTextSplitter（您计划使用的），它会根据标题（#, ##）来分块，使得每个块都围绕一个特定的主题。对于PDF，有工具可以根据其视觉布局（段落、列表、表格）来分块。这保留了文档的原始结构和上下文，效果通常最好。
- 您的data_processing/chunker.py脚本就负责这个阶段。
向量化 (Embedding):
- 做什么： 将每一个文本块（chunk）输入到嵌入模型（如OpenAI的text-embedding-ada-002或开源模型）中，生成一个高维的浮点数向量（embedding）。这个向量可以被认为是该文本块在语义空间中的“坐标”。
- 例子： 将文本块 "The API key is required for authentication" 转换成一个 [0.012, -0.045, ..., 0.089] 这样的1536维向量。
数据存储/索引 (Storing / Indexing):
- 做什么： 将文本块及其对应的向量存储到一个专门的数据库中，这个数据库能够进行高效的向量相似度搜索。
- 例子： 这就是您的Azure AI Search所扮演的角色。您会将文本块和它的向量一起存入Azure AI Search的一个索引中。数据库会为这些向量建立索引（如HNSW），以便快速找到与给定查询向量最相似的邻居。

所以，data ingestion是整个从A到Z的过程。intelligent chunking是这个过程中确保“零件”质量的关键一步。在简历中，将它们并列是不准确的，会显得您对RAG的理解不够深入。正确的表述应该是，在您设计的data ingestion pipeline中，您实现了一个intelligent chunking策略来提升数据处理质量。

技术问题 3：在您的工作流中，ingest 的是谁？

问题核心： “前端是用户与问卷的交互，用户填问卷和个人信息，后端检索的query是问卷问题和其个人信息，那么ingest的是谁？”

回答：
这是一个至关重要的概念混淆，必须澄清。您的描述混淆了**“离线数据摄取（Offline Ingestion）”和“在线查询（Online Querying）”**两个完全不同的阶段。

被 ingest（摄取）的是您的“内部知识库”，而不是用户的信息。

让我们把您的系统流程拆解成两个独立的部分：

阶段一：数据摄取与索引构建 (Data Ingestion & Index Building) - 【离线阶段】

这个阶段在用户与系统交互之前就已经完成了，而且可能会定期重复执行以更新知识库。

对象： 您的内部知识库。这可能包括：
- 产品手册、功能说明文档。
- 销售话术、成功案例。
- 市场分析报告、竞品对比资料。
- 技术白皮书、集成指南。
- 所有您希望AI能够学习并用来回答销售咨询的资料。
流程：
- 您作为工程师，运行您的data_processing脚本（包含cleaner.py和chunker.py）。
- 这些脚本会读取上述的知识库文档（PDF, Markdown等）。
- 对文档进行清洗、智能分块。
- 将分好的文本块进行向量化。
- 将（文本块 + 向量）的配对数据，**批量上传并存储（ingest）**到您的 Azure AI Search 索引中。
结果：
- 一个填充完毕的、可供检索的Azure AI Search索引。这个索引就是您的AI的“大脑”或“长期记忆”。它包含了所有它需要知道的背景知识。

阶段二：查询与应答 (Querying & Answering) - 【在线/实时阶段】

这个阶段是当一个真实用户开始与您的前端应用交互时发生的。

对象： 用户在前端填写的信息。这包括：
- 用户的个人/公司信息（行业、规模等）。
- 用户对问卷问题的回答。
流程：
- 前端收集用户的输入，并将其打包成一个JSON对象。
- 前端的Next.js服务器（作为代理）将这个JSON对象发送到您的FastAPI后端的/enhance-answer端点。
- FastAPI后端接收到请求。现在，它需要根据用户的输入，构造一个或多个“查询（Query）”。
  - 例如，后端逻辑可能会将用户的“问卷回答”和“公司行业”组合成一个更丰富的查询字符串，如：“For a company in the manufacturing industry, what is the best solution for tracking inventory?”
- 后端将这个构造好的查询字符串进行向量化，得到一个查询向量。
- 后端拿着这个查询向量，去查询（Search/Retrieve）那个在阶段一就已经构建好的Azure AI Search索引。
- Azure AI Search会返回与查询向量最相似的N个文本块（这些是来自您的内部知识库的片段）。这就是**检索（Retrieval）**步骤。
- 后端获取到这些检索到的文本块（context），并根据我们之前讨论的逻辑选择一个合适的Prompt模板。
- 后端将context和用户的原始问题question填入模板，形成最终的Prompt。
- 后端调用GPT API（或其他大模型），将这个最终的Prompt发送过去。
- GPT生成一个答案。
- 后端接收到答案，可能会进行一些后处理（如格式化），然后将其返回给前端。
- 前端将最终答案展示给用户。