考点23：讲讲LangChain核心架构
Models（模型层）
-
定位：类似 interface ，抽象模型调用标准
-
能力：支持多模型（OpenAI、Gemini 等 ），类比 Java 中 JDBC 接口（适配不同 “模型数据库” ）
Prompts（提示工程）
-
定位：类比模板引擎（如 Thymeleaf ），构建模型输入的 “引导模板”
-
作用：通过预设模板，让模型输出更贴合需求
Chains（任务链）
-
定位：类比 Activity 工作流，串联多个操作形成任务流
-
能力：动态重组流程，适配复杂业务逻辑
Memory（记忆层）
-
定位：类比 HTTP Session ，管理对话上下文
-
作用：保存交互历史，让模型理解对话延续性
Indexes（索引层）
-
定位：类比数据库索引 + JDBC ，结构化外部文档
-
能力：支持文档提取、切割、向量存储，优化模型交互效率
Agents（智能体）
-
定位：类比策略模式 + 工厂模式，动态选择工具 / 流程
-
能力：自主决策下一步操作（调用工具、编排流程等 ）
考点24：什么是LCEL表达式
LCEL全称为LangChain Expression Language，是 – 3版本后推出的声明式编程语言，用于简化AI流程编排。核心思想是通过管道符连接组件，包括提示词、模型和输出解析器等。管道符类似于Linux系统中的管道符，具有代码简洁、支持流式响应的特点。所有组件接口标准化，输入输出均为字典格式，且均实现Runnable接口协议。内置调试、重试和并行等高级功能。
新版语法通过管道符实现链式组合，左侧组件输出作为右侧组件输入。适用于复杂工作流，如多模型协作、动态路由和生产级高并发场景。支持与LangSmith跟踪工具整合。
例题:问答链构建
组件连接逻辑：提示词 → 模型 → 输出解析器
优势：相比显式对象构建，管道符语法更简洁
执行流程：调用invoke方法即可完成链式调用
考点25：为什么需要输出解析器
主要有：StrOutputParser，CommaSeparatedListOutputParser，JsonOutputParser
核心痛点：大模型原生输出为非结构化文本，无法直接被业务系统（如前端、数据库）解析使用。
核心作用：
将非结构化文本转换为 JSON/XML/ 列表等结构化数据；
处理大模型输出的格式错误，确保数据符合业务预期；
配合提示词工程，强制大模型输出指定格式的内容。
替代方案：可直接在提示词中指定输出格式（如 “返回 JSON 格式”），与解析器原理一致，但解析器更易标准化、工程化。
考点26：为什么需要使用Pydantic
-
Python 数据验证与管理库
-
类似 Java 的 Hibernate Validator
-
核心能力：
-
声明式属性定义
-
数据格式校验（长度、邮箱、格式等）
-
数据序列化（对象 ↔ JSON / 字典）
-
-
解决：用户输入不可信，需强制校验格式、类型、非空
-
主要用途：
-
类型提示与校验
-
数据序列化 / 反序列化
-
复杂配置管理
-
考点27：怎么自定义验证器Pydantic
-
作用：扩展 Pydantic 默认校验规则，实现复杂业务逻辑的字段校验
-
核心工具：@field_validator 装饰器
-
触发时机：字段通过基础类型校验和内置规则校验（如 Field 配置）后执行
-
扩展能力：支持通过 mode 参数调整验证模式
@field_validator 是实现自定义业务校验的核心，支持单字段 / 多字段、简单 / 复杂规则校验；
校验失败需抛 ValueError，且必须返回处理后的值，这是避免数据异常的关键；
多规则校验可聚合错误信息，提升报错可读性，符合业务开发的用户体验需求。
考点28：为啥用Pydantic做解析
对比单纯 JSON 解析器，Pydantic 解析的核心优势：
| 优势点 | 具体价值 |
| 结构化输出 | 将文本 / 大模型输出转为可编程对象，直接对接业务逻辑 |
| 自动数据验证 | 校验类型（如 int/str）、条件约束（如 age>0），避免脏数据 |
| 提升开发效率 | 简化数据处理流程，无需手动写类型判断、格式校验代码 |
Pydantic 解析的核心价值是结构化 + 自动验证，解决了纯 JSON 解析无校验、数据不可靠的问题；
大模型场景中，通过「定义 Pydantic 模型 + PydanticOutputParser」可将非结构化文本转为可编程的模型对象；
落地时只需按业务需求定义模型字段 + 约束，解析后的数据可直接对接业务逻辑，大幅简化开发。
考点29：大模型如何修复
OutputFixingParser
-
作用：修复大模型输出的格式错误（如 JSON 语法错、字段缺失），是 Pydantic 解析器的「兜底工具」
-
核心优势：解析失败时自动调用大模型二次修正，提升解析鲁棒性，避免程序中断
-
扩展方案：可搭配 RetryParser 实现重试逻辑（替代 / 补充修复机制）
| 功能点 | 具体说明 |
| 自动纠错 | 修复 JSON 引号错误、字段缺失、格式不规范等问题 |
| 容错机制 | 结构化输出验证，兜底处理模型输出不稳定场景 |
| 链式调用 | 解析失败时，将错误信息反馈给模型重新生成 |
-
微服务调用：作为数据降级兜底方案
-
字段合规性：处理模型输出不符合业务字段规范的情况
OutputFixingParser 是大模型结构化解析的「兜底工具」，核心解决输出格式错误问题，搭配 Pydantic 使用；
核心用法是通过 from_llm() 包装原始解析器，配置修复模型和重试次数；
生产落地需关注提示词清晰度、模型能力匹配度，同时监控修复成功率。
from pydantic import BaseModel from langchain.output_parsers import PydanticOutputParser, OutputFixingParser from langchain_openai import ChatOpenAI # 1. 定义Pydantic模型（业务字段规范） class Actor(BaseModel): name: str film_list: list[str] # 2. 创建原始Pydantic解析器 original_parser = PydanticOutputParser(pydantic_object=Actor) # 3. 包装为修复解析器（核心步骤） fix_parser = OutputFixingParser.from_llm( parser=original_parser, # 原始解析器 llm=ChatOpenAI(model="gpt-3.5-turbo"), # 用于修复的大模型（可与生成模型分离） max_retries=2 # 最大重试次数（默认1次，需合理设置） ) # 4. 调用解析（自动处理错误→修复→解析） # result = fix_parser.parse(模型错误输出文本) # print(result.model_dump()) # 修正后转为标准字典
考点29：大模型幻觉产生的原因
大模型常见问题，指生成看似合理、逻辑通顺，但实际错误或虚构的信息（本质：基于不完整/错误知识，输出失实内容）。
1. 训练数据局限性（首要原因）
训练数据含错误/谣言，导致模型学习错误知识；数据缺乏时效性（如2021年前数据无法回答后续事件）。
2. 模型生成机制
概率驱动生成（预测下一个最可能的词），而非验证事实；缺乏常识判断能力，无法区分合理表达与客观事实。
3. 模型策略副作用
温度参数影响：较高温度（>0.7）提升创造性，但增加虚构概率（如小说生成不合理情节）。
幻觉输出的4种表现形式
-
虚构事实：生成不存在的信息（如《时间简史》为鲁迅所著、错误的秦始皇统一六国时间）。
-
错误推理：推导逻辑通顺，但结论错误（如2×3=5，反映模型参数/逻辑缺陷）。
-
过度泛化：特定领域知识错误迁移（如用医学术语解释物理现象、混淆“苹果”语义）。
-
矛盾内容：同一段文本存在逻辑冲突（如先称“地球是平的”，后说“地球绕太阳公转”）。
考点30：幻觉输出的缓解方案
1. 技术改进（核心）
-
检索增强生成（RAG）：实时检索外部知识库，提供事实依据（主流方案）。
-
微调训练：用标注数据修正模型认知。
-
强化学习：通过人类反馈，奖励准确回答、惩罚幻觉内容。
2. 生成策略优化
-
降低温度参数：减少生成随机性，降低幻觉概率。
-
双模型校验：A模型生成内容，B模型验证准确性（适用于高精度需求）。
3. 用户侧应对
-
优化提示词：明确约束条件（如“基于2023年前数据回答”“不虚构未证实信息”）。
-
多元验证：结合权威外部信息源，交叉核对模型输出。
总结
幻觉是大模型核心痛点，根源集中在数据、生成机制、参数设置；缓解关键是RAG技术+数据质量管控，搭配策略优化和用户侧约束，可有效降低幻觉概率。
考点31：RAG架构的链路
1）核心架构链路
用户问题输入 → 检索相关片段 → 组合输入大模型 → 生成最终答案。
2）关键技术组件
-
文档加载器（如PDF Loader）：加载各类格式的原始文档；
-
文档分割器：将长文档切分为可检索的短片段；
-
元数据处理：标注文档来源、时间等信息，便于追溯；
-
向量数据库：存储和检索向量化后的文档数据。
| 步骤 | 技术动作 | 代码核心实现 |
| 1 | 文本加载 | 使用TextLoader加载本地qa.txt文件，校验文件存在性 |
| 2 | 文本分割（带重叠） | 采用RecursiveCharacterTextSplitter，设置chunk_size=1000、chunk_overlap=200，保证文本片段语义完整性 |
| 3 | 文本向量化 | 调用阿里云通义千问text-embedding-v2嵌入模型，将文本片段转为向量 |
| 4 | 向量数据库构建 | 基于 Chroma 向量库存储向量数据，配置检索器返回 Top3 相关片段（search_kwargs={"k": 3}） |
| 5 | 大模型初始化 | 初始化通义千问qwen-plus大模型，配置 API 密钥、请求地址及生成温度（temperature=0.7） |
| 6 | 提示模板构建 | 采用ChatPromptTemplate构建含context（上下文）和question（问题）双占位符的模板，适配千问模型的[INST]/<SYS>格式 |
| 7 | RAG 链组装与执行 | 串联 “检索 – 提示词 – 大模型 – 输出解析” 全流程，通过invoke方法接收用户问题并返回答案 |
