RAG项目实战

一、rag项目背景

1.问题

知识截止 & 幻觉问题
LLM 的知识被”冻结”在训练数据的某个时间点，之后发生的事情它不知道；面对不知道的问题，模型倾向于”编造”看似合理但错误的答案

私有/领域知识缺失
企业内部文档、个人知识库、最新的漏洞情报这些数据根本不在模型训练集里，模型无法回答这类问题。

2.传统解决方式

Fine-tuning（微调）：把新知识”炼”进模型参数里。成本高、更新慢（每次知识变化都要重新训练），且难以做到精确溯源

扩大 Context Window（长上下文）：把所有资料塞进 prompt。但成本随 token 数线性增长，且信息越多，模型对关键内容的注意力越分散（”lost in the middle”问题）

RAG 的思路是：不改模型、不硬塞全部资料，而是让模型在回答前先”去查资料”，检索出真正相关的片段，再基于这些片段生成答案。这个概念最早由 Facebook AI（现 Meta AI）在 2020 年的论文中系统提出

3.工作流程

索引阶段（离线）：把知识库文档切分成小块（chunk）→ 用 Embedding 模型转成向量 → 存入向量数据库（如 Milvus、Faiss、Chroma）

检索阶段（在线）：用户提问 → 问题也转成向量 → 在向量库中做相似度搜索，找出最相关的几个文档片段

增强阶段：把检索到的片段拼接进 prompt，作为”参考资料”提供给 LLM

生成阶段：LLM 基于问题 + 检索到的资料生成答案，通常还能标注引用来源

image-20260708203131034

4.核心优势与挑战

知识可以实时更新（改文档就行，不用重训模型）答案可以溯源（能标注是基于哪段资料回答的，减少幻觉）成本远低于微调，落地快

RAG 的挑战：

  • 切分策略：chunk 太大浪费 token、太小丢失上下文
  • 检索精度：语义相近但答案错误的片段可能被误检索（需要 rerank 重排序模型辅助）
  • 多跳推理：单次检索可能不够，需要 Agentic RAG / 迭代检索来处理复杂问题

二、项目实战

1.计划模式讨论

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
我的毕设是,通过langchain框架,开发RAG企业级知识问答系统,用户可以通过浏览器进行知识库问答操作;
问答系统主要是针对电商平台售卖商品进行回答,提供的知识库多数是商品相关信息,帮助更好的回答用户关于商品的问题;
技术选型上,我听说AI领域langchain是非常知名的开发框架,所以必须选择langchain,其余技术栈你来决定;

我需要有如下功能:
1. 能够支持用户在浏览器中进行知识库管理
2. 能够支持用户在浏览器中和模型进行知识库问答,问答的时候要尽量引用知识库内容作为参考,在回答中能够显示引用的知识库片段是哪些
3. 能够支持多用户多会话管理,每个用户有每个用户的独立会话
4. 能够保持用户的会话记录,用户不同时间段登录都能找回历史对话
5. 支持基础的用户注册登录功能,支持用户修改密码
6. 管理员用户名admin,密码123456,只有管理员能够打开知识库管理页面,进行知识库管理,其他用户只能进行知识库问答
7. 不仅仅实现基础功能,也要应用各类技术做性能优化,达到企业级使用的效果
8. 其余你觉得有必要可以添加的功能点

你帮我列出来方案计划,我们先讨论;

2.单元测试与bug修复

对话测试

复制日志

上传百炼官方api文件

上传知识库文件失败日志

bug

1
2
3
上传页面，切换之后，ai回复消失
问题2回复问题1的答案
普通用户切换登录，会话混到一起

3.技能迁移

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
你现在要做一次「Agent / Skill / Hook 迁移」任务，请按以下步骤严格执行：

## 第一步：全面盘点源项目
请先扫描并读取以下位置（如果存在），列出所有找到的 agent、skill、hook 文件及其用途：
- .claude/agents/ 下所有 *.md agent 定义
- .claude/skills/ 下所有 SKILL.md 及配套脚本/资源
- .claude/hooks/ 或 settings.json 中配置的 hooks（PreToolUse、PostToolUse、UserPromptSubmit 等）
- CLAUDE.md 中引用到的自定义工具链说明

对每一个文件，简要总结：
1. 名称与用途
2. 触发条件 / 何时被调用
3. 依赖的技术栈或工具（语言、框架、CLI、外部服务等）
4. 是否有硬编码的路径、命令、依赖版本

## 第二步：确认目标技术栈
目标项目技术栈是：[在此填写，例如：Java + Spring Boot + Maven / Python + FastAPI / Go 等]
目标项目结构是：[粘贴目标项目目录结构，或说明关键路径]

## 第三步：逐项迁移
对第一步盘点出的每个 agent/skill/hook：
- 判断是否与源项目技术栈强耦合（如调用了特定语言的 linter、build 工具、包管理器命令）
- 如果耦合，改写为适配目标技术栈的等价实现（如 mvn → gradle，pip → uv，pytest → junit 等，视实际情况替换命令、配置文件格式）
- 如果是通用逻辑（如 git 操作、通知类 hook、纯文本分析类 skill），保持逻辑不变，仅调整路径引用
- 迁移后的文件按 Claude Code 规范放入目标项目对应目录（.claude/agents/、.claude/skills/、.claude/hooks/ 或 settings.json）

## 第四步：输出迁移报告
完成后给我一份表格，列出：
| 原文件 | 类型 | 迁移状态（保留/改写/废弃） | 改写说明 | 新路径 |

对于「废弃」的项，说明原因（例如目标技术栈没有对应工具、功能已被目标项目其他机制覆盖等）。

## 注意事项
- 不要凭空编造源项目中不存在的 agent/skill/hook
- 改写命令时要确认目标技术栈的真实语法（如有不确定，先搜索或询问我）
- 涉及 hook 的 JSON 配置（matcher、command）迁移后请给出可直接替换进 settings.json 的完整片段

4.压力测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
你现在要为我的系统设计一份「100 并发用户压力测试方案」，请按以下结构输出，要求具体可执行，不要空泛描述。

## 系统背景（请先基于以下信息设计，缺失信息请合理假设并标注）
- 系统类型：[Web API / Web 应用 / 微服务集群 / 其他，请填写]
- 技术栈：[语言、框架、数据库、缓存、消息队列等]
- 部署环境：[本地 / 测试环境 / 云环境，配置规格如 CPU/内存/带宽]
- 核心业务场景（用户在系统里主要做什么）：[登录、下单、查询、上传文件等，列出 3-5 个关键路径]
- 是否有现成的压测工具偏好：[JMeter / Locust / k6 / wrk / Gatling / 无偏好]

## 请按以下模块输出压测方案

### 1. 测试目标
- 明确本次压测要验证什么（吞吐量、响应时间、错误率、资源占用、系统瓶颈定位等）
- 给出量化的成功标准（如：P95 响应时间 < 500ms，错误率 < 0.5%，CPU 使用率 < 80%）

### 2. 场景建模
- 针对每个核心业务路径，设计对应的虚拟用户行为脚本（含请求顺序、思考时间/间隔、参数化数据）
- 说明 100 个并发用户如何分配到不同场景（如 40% 登录+浏览，30% 下单，30% 查询）

### 3. 压测工具与脚本
- 推荐一个具体工具（结合我给的技术栈和偏好），说明选择理由
- 给出可直接运行的压测脚本骨架（如 Locust 的 locustfile.py 或 k6 的 test.js），覆盖上面的核心场景
- 包含参数化、鉴权（token/cookie）、断言（状态码、响应内容校验）

### 4. 压测执行计划
- 分阶段加压策略（如：预热 10 并发 → 阶梯升至 100 并发 → 持续稳定负载 → 峰值突刺测试）
- 每阶段的时长、目标并发数、观察指标

### 5. 监控与数据采集
- 需要监控哪些指标（应用层：QPS/响应时间/错误率；系统层：CPU/内存/磁盘IO/网络；数据库层：连接数/慢查询/锁等待）
- 建议使用的监控工具（如 Prometheus+Grafana、APM 工具、数据库自带慢查询日志）

### 6. 风险与注意事项
- 压测环境隔离建议（避免影响生产）
- 数据污染与清理方案（测试数据如何标记、事后如何清理）
- 限流/熔断/降级机制是否需要提前确认，避免压测触发误报警

### 7. 结果分析框架
- 给出压测报告应包含的核心章节和图表建议（如响应时间分布图、错误率随并发变化曲线、资源使用趋势图）
- 常见瓶颈的排查方向提示（数据库连接池、GC、线程池、网络带宽等）

请确保脚本部分是可以直接运行或稍加修改即可运行的真实代码，不要用伪代码占位。