1，为什么很多RAG项目会失败？
1，检索质量太差，根本没有检索到正确内容
原因：embedding不行，相似度算错，语义没对齐。query没有被改写，完全没有上下文，检索失败。
解法：LLM改写查询，关键词+向量。
2，Chunk切分错误
原因: chunk太大，信息很多，但不相关，模型被噪声干扰。 chunk太小，语义断裂，找不到完整答案。
解法：重叠切分， 按语义切，而不是按字数。
3，top-k策略错误
原因：k太小，找不到信息。 k太大，噪声爆炸。
解法: 重排序，动态调整。
4，Prompt设计不对（模型不会用资料）
原因： 模型不知道"必须用资料"，不知道"怎么用"
解法：请严格基于以下资料回答，如果资料中没有答案，请说"无法回答"。
5，数据源本身有问题，
原因：过时，矛盾，错误数据。
解法: 数据清洗，加时间/版本信息，标注来源。
6，评估方式完全错误
原因: 没覆盖边界case, 没有测失败率，没测hallucination.
解法：构建测试集，指标 ：retrieval recall(成功检索到的相关结果占所有相关结果的比例) , answer accuracy。
2，Agent什么时候该用，什么时候不该用
适合场景：1，多步骤+不确定路径。2，需要动态调用工具。3，任务无法预先写死流程。4，探索型任务，比如，信息汇总，自动化分析。
不适合场景：1，简单回答。 2，流程固定的任务。3，高可靠性场景，如 金融，医疗，法律。
3，蒸馏 vs 微调 vs RAG（怎么选）
RAG适合，知识经常变，需要"查资料"，不想训练模型。
微调适合，任务固定，输出格式重要，想"改变模型"。
蒸馏适合，已有大模型，要做低成本部署，QPS很高，企业私有轻量部署。
4，一个完整LLM系统架构（工业级）
html
[1] 接入层（API / UI / Channel）
👇
[2] 编排层 （Orchestration / Agent Router）
👇
[3] 认知层 （Prompt + Memory + Tools + RAG）
👇
[4] 模型层 （LLM / Embedding / Rerank）
👇
[5] 知识与工具层（Vector DB / sql / search / APIs）
👇
[6] 观测与治理层 (Logging / Eval / Safety / Cost)1，接入层：把用户请求标准化。常见入口：web chat, mobile app。 处理内容：鉴权，session id，用户画像加载。
2，编排层： 这是大模型的cpu, 核心功能：任务分流，判断要不要调工具，要不要RAG。Agent Controller，多步执行。拼prompt, 系统提示词，用户输入，记忆，检索文档。
3，认知层，这一层决定像不像"人类"。 提示系统包括行为规则，少样本示例，结构化提示模板。记忆系统包括 当前会话上下文，用户偏好，历史对话摘要。 RAG，检索增强。工具调用，数据库，函数，搜索引擎。
4，模型层。 LLM，Embedding Model, Reranker.
5, 知识与工具层。 向量数据库，结构化数据库，文档存储，搜索引擎， 其他的API接口。
6，观测与治理层。
Logging(全链路记录)，记录：prompt,retrivel docs,tool calls, output,latency.
评估系统：幻觉率，召回率，准确率。
安全层：越狱检测，提示词注入，输出控制。