构造问答系统

一、通过 API 调用大模型

1.1 基础调用

• 使用 OpenAI Python SDK，base_url 指向百炼兼容接口：https://dashscope.aliyuncs.com/compatible-mode/v1
• 消息三角色：system（系统指令）、user（用户输入）、assistant（模型回复）
• 模型选择：qwen-max / qwen-plus / qwen-turbo 等

1.2 多轮对话

• 关键：维护 conversation_history 列表，每次调用需传入完整历史
• 大模型 API 是无状态的，不会自动记住上一轮对话
• 对话历史占上下文窗口空间，过长需截断或摘要处理
• 生产环境需将对话历史持久化存储（如数据库），支持跨会话连续对话

1.3 流式输出

• 参数：stream=True
• 效果：逐 token 增量返回，用户无需等待完整回复
• 本质：仅改变展示方式，不影响模型推理过程和最终答案质量
• ⚠️ 流式输出如使用负载均衡，可能需要禁用缓存和数据压缩

二、大模型工作原理（五阶段）

• 自回归生成：每次生成一个 token，追加到输入，循环直至遇到 EOS / 达到最大长度 / 遇到停用词
• 不同模型 EOS 不同：Qwen3 = <|im_end|>，LLaMA/Mistral = </s>，DeepSeek V3.2 = <｜end▁of▁sentence｜>，GPT-OSS = <|return|>

解码策略两大分类

三、随机性参数

• ⚠️ 不建议同时调整 temperature 和 top_p，优先调整其中一个
• ⚠️ 即使 temperature=0、top_p 极小、seed 相同，仍可能因分布式系统/优化引入微小随机性
• 确定性场景（结构化提取）：temperature=0.1, top_p=0.3
• 创意场景（广告文案）：temperature=0.7~0.9, top_p=0.9

拓展：enable_search 参数

• 千问支持 enable_search 参数，让大模型在生成回答时利用互联网搜索结果丰富回复内容

四、上下文工程 (Context Engineering)

为什么需要？

• 大模型知识来自训练数据，不包含私域知识
• 直接在提示词中喂入知识 → 上下文窗口有限 + 效率低 + 成本高 + 信息干扰
• 核心定义：在正确的时间，将最相关、最精准的知识，动态加载到大模型有限的上下文窗口中

四大核心技术

五、RAG（检索增强生成）

5.1 两阶段流程

• 检索是最重要的环节：如果检索不到正确的信息，后面的生成一定出错

5.2 文本向量化原理（扩展）

• Embedding 模型通过对比学习训练：相关文本对向量相似度高，不相关的低
• 检索时：问题向量与库中所有片段向量进行余弦相似度比较 → 返回最相似的 N 个

5.3 RAG 多轮对话

• 挑战：检索只基于当前问题，代词指代丢失上下文（如"他的主管是谁？"不知"他"是谁）
• 解决方案：问题改写
  • 用大模型根据对话历史改写当前问题
  • 例：「他的主管是谁？」→「张三的主管是谁？」
  • 实现：LlamaIndex 的 CondenseQuestionChatEngine

5.4 LlamaIndex 核心用法

# 加载文档 → 创建索引 → 保存/加载 → 查询
documents = SimpleDirectoryReader('./docs').load_data()
index = VectorStoreIndex.from_documents(documents, embed_model=DashScopeEmbedding(...))
index.storage_context.persist("path")  # 保存
index = load_index_from_storage(StorageContext.from_defaults(persist_dir="path"), embed_model=...)  # 加载
query_engine = index.as_query_engine(streaming=True, llm=OpenAILike(...), similarity_top_k=5)
response = query_engine.query('问题')

六、提示词工程

6.1 提示词框架六要素

• 其他分析方法：SWOT分析法、5W2H分析法等也可辅助构建提示词
• 阿里云百炼提供提示词自动优化工具

6.2 六大提示词技巧

• 超越 CoT：思维树(ToT)、思维图(GoT)等方法进一步扩展推理能力
• 发展趋势：大模型从 CoT 提示方法向多智能体(Agent)方向发展

6.3 Meta Prompting 的多角色协作架构

• Critic（评估者）：将生成答案与参考答案对比，输出差距分析报告
• Optimizer（优化者）：根据差距分析报告重写提示词
• Grader（评分员）：按量化标准（如友好度、清晰度、准确性 1-5 分）评分，输出结构化 JSON
• 迭代流程：生成 → Critic 对比 → Optimizer 重写 → Grader 评分 → 循环直到差距足够小

6.4 AI裁判

• 用大模型依据预设量化标准判断"通过/不通过"
• 训练流程类似机器学习：
  1. 准备标注样本（好答案与坏答案）
  2. 7:3 拆分训练集/评估集
  3. 迭代优化（Meta Prompting 改进裁判提示词）
  4. 监控两个准确率：训练集准确率 + 评估集准确率
  5. 过拟合检测：训练准确率持续提升但评估准确率停滞或下降 → 停止优化
  6. 样本质量问题：标注样本含糊或矛盾 → 先修复样本，再优化裁判
  7. 选择标准：采用评估集上表现最好的版本，而非训练集
• 用于自动化提示词优化流程的停止条件

6.5 推理模型 vs 通用模型

推理模型提示词技巧：

1. 保持简洁清晰 + 足够背景信息
2. 避免添加"一步一步推理"（模型自带深度思考）
3. 可补充角色/受众/输出格式
4. 适合做 Meta Prompting 的"教练"
5. 根据模型响应迭代调整：推理模型回含思考过程，天然适合分析推理逻辑；不断对话补充信息完善提示词；描述太抽象时可增加示例明确
6. 混合分工策略：推理模型做"规划师"/"分析师"（提示词优化、复杂规划、代码调试），通用模型做执行者（信息提取、格式转换、简单问答），最佳性价比

6.6 提示词工程化最佳实践

• 提示词应做成可配置的，方便领域专家参与设计
• 阿里云百炼提供可视化大模型应用构建能力（页面编写提示词、流程可视化搭建）

七、自动化评测

7.1 为什么需要评测？

• 大模型输出有随机性 → 每次调整需量化验证
• 从"感觉变好了" → "指标提升了 X%"
• 评测先行的三大原因：
  1. 避免盲目优化：没有基线，不知道优化是否真的有效
  2. 量化改进效果：从"感觉变好了"变成"指标提升了X%"
  3. 防止跷跷板效应：一处优化可能导致另一处退步，评测发现整体是否提升

7.2 "Lost in the Middle" 与"知识浓度"

• Lost in the Middle：关键信息被埋藏在海量无关信息中，大模型"视而不见"
• 知识浓度：上下文中相关信息密度高、噪音少、与问题直接关联
• RAG精度瓶颈往往不在大模型"聪明"与否，而在于上下文的"知识浓度"

7.3 评测维度与框架

RAG 评测四大维度：

1. 召回质量（Retrieval Quality）
2. 答案忠实度（Faithfulness）
3. 答案相关性（Answer Relevance）
4. 上下文利用率/效率（Context Utilization）

主流评测框架对比：

• LlamaIndex / LangChain 等主流 RAG 框架也内置评估工具

7.4 Ragas 指标分类

7.5 Ragas 三大核心指标详解

• 事实 F1 计算：大模型将 answer 和 ground_truth 分解为观点列表 → 计算 TP/FP/FN → F1 = TP / (TP + 0.5×(FP+FN))
• Faithfulness（忠实度）：评估答案与检索参考资料的事实一致性（是否"胡编乱造"/幻觉）
• Answer Relevancy（答案相关性）：评估生成的答案是否与问题相关
• 低分诊断：

7.6 Ragas 提示词模板可定制

• Ragas 默认提示词模板是英文的，可自定义中文模板以更符合中文问答场景
• Ragas 提示词中包含示例，也可更改示例适配业务场景

7.7 更多评价指标

7.8 评测运营体系

• 问题来源：真实用户场景（工单、反馈、高频问题）
• 标准答案：领域专家编写（技术人员无法判断业务正确性）
• 指标层级对齐：

• 评测先行动作：明确定义目标 → 构建评测集 → 建立自动化评测 → 针对性优化 → 评测验证 → 持续迭代
• 持续运营三举措：
  1. 让业务专家参与AI评测（如电商主管评测促销规则、物流专员评测运费时效）
  2. 从最终用户视角出发，评判答案的正确性、简洁性与可操作性
  3. 建立闭环机制：发现问题 → 改进优化 → 跟踪效果 → 迭代指标

八、RAG 优化

8.1 文档准备阶段

• 意图空间 vs 知识空间：
  • 重叠区 → 优化内容质量 + 工程/算法
  • 未覆盖意图 → 补充知识库
  • 未利用知识 → 优化召回 + 剔除无关内容
• 建立持续收集用户意图的机制，领域专家参与评测

8.2 文档解析与切片

五种切片方法：

• 句子窗口切片解决的核心矛盾：小 chunk 精准定位 vs 大 chunk 上下文完整
• 没有最好的方法，只有最适合场景的方法
• 借助百炼 DashScopeParse 将 PDF/Word 解析为 Markdown，可用大模型润色修正

8.3 向量化与存储

Embedding 模型选择：

• 新版通常更好（text-embedding-v3 > v2）
• 可通过相似度对比和 Ragas 评测验证效果

向量数据库选择：

8.4 检索召回优化

检索前策略：

检索后策略：

8.5 生成阶段优化

8.6 进阶架构

模块化 RAG：

• 结合不同问题路由到不同的 RAG 应用，构建能力更强大的模块化 RAG 系统

GraphRAG：

• 结合检索增强生成(RAG)和查询聚焦摘要(QFS)的优点
• RAG 擅长精确细节信息，QFS 善于理解和总结整体内容
• GraphRAG 既能准确回答具体问题，又能处理需要深入理解的复杂查询