前端 + AI 学习记录（Day 21–30）：RAG 进阶 / 安全 / 前端基础设施
前端 + AI 学习记录（Day 21–30）：RAG 进阶 / 安全 / 前端基础设施
这一篇是第三阶段总结，覆盖 Day 21–30：重点是 RAG 质量、AI 安全性、和前端通用基础设施。跟前两阶段比，这一段更偏“把东西做稳、做好用”。
一、阶段目标：从“能跑”到“敢用”
这 10 天我给自己的目标是：
- 让 RAG 更稳、更准、更可控（减少答非所问和胡说八道）
- 让前端聊天体验更接近产品级：流式、滚动、错误态、历史会话
- 在前端侧沉淀出一套 可复用的 hooks/组件/工具，以后新项目直接拿来用
二、Day 21–24：RAG 质量 & 可评估性
1. LCEL & 结构化输出（Day 21）
-
把 LangChain 的 LCEL（LangChain Expression Language）搞明白了：
一切都是 Runnable，可以用
.pipe()像流水线一样拼起来。 -
典型链路写法从：
// 之前：手写一堆 await
const text = await prompt.format(values)
const res = await llm.call(text)
const parsed = JSON.parse(res)
变成：
// 现在：RunnableSequence
const chain = RunnableSequence.from([
prompt, // PromptTemplate
llm, // ChatOpenAI
parser // StructuredOutputParser.fromZodSchema(...)
])
const result = await chain.invoke({ question })
- 同时学会了用 zod 做结构化输出（避免到处手写 JSON.parse）：
const schema = z.object({
title: z.string(),
score: z.number().min(0).max(10),
reasons: z.array(z.string())
})
2. RAG 检索优化（Day 22）
这一天主要是把“检索层”的优化点都过了一遍：
-
Chunk 策略：
- 一般 QA：
400~600 tokens + 一点 overlap会比较折中 - 技术/规范文档：尽量按段落/小节切，而不是纯按字数
- 一般 QA：
-
上下文压缩（Contextual Compression）：
- 粗检索 TopK → 再用 LLM 或规则“截取”与 query 强相关的句子
- 目的：减少废话，帮生成阶段减负
-
Multi-Vector & Hybrid：
- 一个文档多个向量（标题/摘要/关键句）；
- 向量相似度 + 关键词命中（BM25）一起算分 → 排序时更稳。
3. 约束式回答 & 引用标注（Day 23）
-
Prompt 级别的约束：
- 「只允许基于提供的上下文回答，如果没有信息，就明确说‘文档中没有相关信息’」
- 「不要使用外部知识，不要编造具体数据/时间/数字」
-
引用标注思路：
- 检索到的文档前加编号
[1],[2],[3]，传给 LLM； - 要求回答中在相关句子后加
[n]； - 响应 meta 里带上 citation 信息，前端可以做“基于哪个片段”的提示。
- 检索到的文档前加编号
-
自检链（Self-Check）：
question + answer + context再丢给一个评估链，让 LLM 判断：- 是否严格基于 context？
- 是否有明显幻觉？
- 前端可以用
isSafe标记高亮，告诉用户“这条回答有点不确定”。
4. RAG 评估 & Benchmark（Day 24）
- 建了一份小型 基准集：
- 真实/常见问题 + 期望的关键点（
key_points[]）
- 真实/常见问题 + 期望的关键点（
- 写了一个简单评估脚本（最初可以只是后端 or Node 脚本）：
- 遍历样本 → 调当前 RAG → 检查 answer 是否包含 key_points 中的大部分 → 算命中率；
- 或者用 LLM 打分：
0~10+ 评语。
意义在于：后面每次你改检索、Prompt、模型，都可以 跑一轮评估，防回归，而不是靠“感觉”。
三、Day 25–27：前端聊天体验 & 安全设计
1. 前端聊天 UX（Day 25）
重点梳理了一个聊天页“该有的样子”：
-
信息架构：
- 顶部（Header）：标题、功能入口、模式说明
- 中部：消息列表（支持流式、时间、操作按钮）
- 底部：输入区（Enter 发送 / Shift+Enter 换行）
- 侧边/弹层：历史会话列表（标题 + 摘要 + 时间）
-
体验细节：
- 流式输出时的自动滚动（尊重用户上滑行为）
- 错误态分种类（网络/超时/服务/权限）+ 明确文案
- “新对话/清空”时重置状态，别让用户搞不清上下文从哪儿开始
- 快捷问题/模板作为引导，而不是空白一片
2. 安全 & 权限（Day 26）
从实际业务角度过了一遍安全问题：
-
Prompt 注入：
- 文档中可能埋“请忽略上面所有指令”等恶意内容；
- System Prompt 里要明确：
- 用户输入和文档内容都是“不可信”的，不能修改系统规则。
-
多租户/权限：
- 文档向量库里要有
tenantId / userId / dept / visibility等元数据； - 检索前先按权限过滤，再做相似度搜索。
- 文档向量库里要有
-
输入输出检查：
- 过滤/限制超长输入（避免 DoS）
- 输出经过 Markdown 渲染 + XSS 防护（你项目里用
marked+innerHTML就需要格外注意这一点）。
-
日志脱敏：
- 在日志里避免直接存手机号/身份证/密码/token；
- 落盘前用正则 mask 关键信息。
3. Function Calling 设计最佳实践（Day 27）
-
函数/工具 Schema 设计要点：
- 单一职责、清晰描述，参数尽可能简单扁平；
- 返回值是结构化“事实数据”，自然语言解释交给 LLM。
-
两阶段调用：
- LLM 只决定「用哪个工具 + 参数是什么」；
- 后端收到 function_call，再做权限/风控/日志 + 实际执行。
这样可以在中间多一层 安全挡板，防止 LLM 直接发出危险操作。
四、Day 28–30：文档 / 报表 / 前端基础设施
1. 文档流水线（Day 28）
- 从“原始文件”到“可检索文档”的完整流程：
- 解析：PDF/Word/Markdown → 抽文本 + 保留结构；
- 清洗：去页眉页脚/广告/重复空行等；
- 切片：根据段落 + token 长度切 chunk；
- 打标签：为每个 chunk 加
docId / section / tags / owner / source； - 入库：写入向量库 + 关系型 DB/搜索引擎里的 meta。
这一整条 pipeline 是 RAG 的地基。
2. 结构化数据 / 报表问答语义层（Day 29）
-
对电商 Demo 归纳了一个指标语义层：
- Metric：
gmv / total_orders / conversion_rate… - Dimension：
date / category / channel / region… - Filter：
date_range / category='手机' / channel='App'
- Metric：
-
设计“自然语言 → 查询意图 JSON”的结构，例如：
{
"metric": "gmv",
"dimensions": ["category"],
"filters": { "date_range": "last_7_days" },
"orderBy": { "field": "gmv", "direction": "desc" },
"topN": 5
}
这个 JSON 就是你后端做安全 NL2SQL 的关键中间表示。
3. 前端 AI 基础设施（Day 30）
-
抽象了一套前端通用能力：
useChat / useStreamingChat / useSSEaiClient（统一的 chat / streamChat 接口）- 通用
Message模型（role/content/meta/timestamp） - 聊天 UI 组件（消息列表 + 输入框 + 状态/错误）
-
目标：以后做任何新场景（客服 / 代码助手 / 报表 QA），前端只需要换：
- Prompt 模板；
- 后端具体路径；
- 少量 UI 文案和样式。
五、这一阶段对我的几点“思维升级”
-
RAG 不只是“加个向量库”
- 质量主要来自：检索策略 + Prompt 设计 + 回答约束 + 评估机制。
-
安全性和工程化必须前置考虑
- Prompt 注入、多租户、日志脱敏、错误分级，如果后一拍脑袋补，会非常痛苦。
-
前端可以成为 AI 应用的“控制台”
- 调试面板、Prompt 实验台、Agent Trace、知识中心，其实都是前端价值最大的部分。
浙公网安备 33010602011771号