# AI / RAG 技术选型评估与当前实现对照

## 一、文档目的

本文档用于回答一个非常具体的问题：

> 以 `my-resume` 当前项目阶段来看，我们已经选择并落地的 AI / RAG 技术栈是否合适？

这里不讨论“通用 AI 平台”的最优解，而是只围绕当前仓库的目标、边界和教学节奏，判断：

- 当前技术选型是否匹配项目阶段
- 当前实现是否已经覆盖关键主线
- 哪些地方值得继续优化
- 哪些能力现在不该急着做

## 二、当前目标

当前 AI / RAG 这条线的目标，不是一次性做成复杂知识库产品，而是：

- 服务当前 `my-resume` 的简历分析、建议生成与知识检索能力
- 保持项目结构轻量、清晰、可解释、可写教程
- 让后续博客、开发日志和演示过程都能直接复用当前实现

换句话说，当前追求的是：

- **可跑通**
- **可验证**
- **可讲清楚**
- **可继续演进**

而不是一步到位追求：

- 向量数据库
- 异步任务中心
- 多租户知识库
- 复杂 Agent 编排系统

## 三、当前明确只做什么

结合仓库当前阶段，AI / RAG 技术栈更适合承接这些事情：

- 使用现有 `apps/server` 作为唯一 AI 业务后端
- 复用现有 AI Provider 适配层
- 用结构化语料构建最小 RAG 索引
- 让检索、问答、分析和简历改写共享同一条 AI 基础设施
- 保持本地可运行、开源可验证、教程可复现

## 四、当前明确不做什么

当前阶段不建议扩到下面这些方向：

- 不上本地 embedding 模型运行链路
- 不上 `Chroma`、`pgvector` 等向量数据库
- 不上复杂队列、任务中心、历史版本管理
- 不引入独立的 AI 中台或第二套后端
- 不把当前 RAG 做成通用知识库管理系统

这些方向不是永远不做，而是当前项目还不需要，也不符合教程型渐进重构节奏。

## 五、建议技术栈与当前实现对照

### 1. 运行时与落点

建议：

- 语言：`Node.js`
- 落点：直接放在 `apps/server`

当前实现：

- 已经落在 `NestJS + Node.js` 的 `apps/server`
- AI 与 RAG 均在服务端统一承接

评估：

- **合适**

原因：

- 与仓库“唯一业务后端”原则一致
- 避免前端再单独维护一套 AI 逻辑
- 文件提取、分析、RAG、权限边界都能统一收口

### 2. AI Provider 层

建议：

- 继续沿用当前 OpenAI-compatible 适配层
- 兼容七牛、DeepSeek 等现有提供方

当前实现：

- 已支持 `mock / qiniu / deepseek / openai-compatible`
- 已抽象 `generateText / embedTexts`

评估：

- **合适，且复用价值很高**

原因：

- 当前仓库已经有统一 Provider 边界
- RAG 不需要再另起一套模型接入方案
- 有利于把“分析、问答、改写、RAG”统一到同一基础设施层

### 3. 语料源格式

建议：

- 原始语料可使用 `YAML`
- 切片后统一转标准 chunk / index JSON

当前实现：

- 简历源使用 `apps/server/data/rag/resume.zh.yaml`
- 索引产物写入 `apps/server/storage/rag/resume-index.json`
- 博客目录也会参与知识源构建

评估：

- **非常合适**

原因：

- `YAML` 对结构化简历极其友好
- 可读性好，适合人工维护与教程展示
- 索引 JSON 可以直接观察结果，方便调试和教学

### 4. 切片策略

建议：

- 不按字数硬切
- 按简历语义块切片

当前实现：

- 已按 `profile / skills / education / experience / project / extra` 切片
- 工作经历下的项目也拆成独立 chunk
- 博客知识源按 Markdown 标题语义切块

评估：

- **方向正确**

原因：

- 简历本身就是天然结构化语料
- 语义块切片比“固定长度分段”更稳定
- 更容易做结果解释、来源展示和后续优化

### 5. embedding 方案

建议：

- 优先走远端 embeddings 接口
- 不要在 v1 里引入本地 embedding 模型环境

当前实现：

- 已通过现有 AI Provider 的 `embedTexts` 能力生成向量
- `mock` 模式下也有 deterministic embedding 兜底

评估：

- **合适**

原因：

- 当前目标是学清 RAG 主流程，而不是先折腾本地模型环境
- 复用远端接口，能把重心放在“语料、切片、检索、答案”上
- 对开源版与教程型项目更友好

### 6. 向量存储方案

建议：

- v1 使用本地 JSON 索引
- 暂不引入向量数据库

当前实现：

- 已使用本地 JSON 索引文件保存 chunk 与 embedding

评估：

- **非常适合当前阶段**

原因：

- 当前语料规模很小
- 本地 JSON 更轻、更稳、更容易解释
- 真正需要升级时，也可以从当前结构平滑迁移到更重的存储方案

### 7. API 设计

建议：

- `POST /ai/rag/index/rebuild`
- `GET /ai/rag/index/status`
- `POST /ai/rag/search`
- `POST /ai/rag/ask`

当前实现：

- 已有 `status / rebuild / search / ask`

评估：

- **已经基本对齐**

原因：

- 接口面足够支撑教学、调试、前端展示和后续演进
- 没有一次性扩出过多抽象

## 六、为什么这套技术栈适合 `my-resume`

### 1. 它贴合项目真实规模

`my-resume` 当前不是知识库平台，不是多租户 SaaS，也不是企业级 AI 工作流系统。

它首先是：

- 一个教程型 monorepo
- 一个可演示的个人简历系统
- 一个可以承载 AI 分析、RAG 和 Agent 学习实践的真实项目

因此，技术选型必须优先匹配“真实问题”和“当前规模”。

### 2. 它贴合仓库当前边界

当前仓库一直强调：

- 单后端
- 渐进式重构
- 先短链路闭环，再做复杂系统

所以 AI / RAG 这条线也应该遵守同样原则：

- 先把最小链路做稳
- 先把输入、索引、搜索、问答讲清楚
- 再考虑更复杂的存储、任务与编排

### 3. 它贴合教程输出需求

这套技术栈的一个重要优势，是**每一层都能讲得清楚**：

- 原始语料看得见
- 切片规则讲得清
- 索引结果能打开看
- 检索过程可解释
- Provider 层复用现有基础设施

这对于“项目即教程、实践即内容”的路线很重要。

## 七、当前实现已经做得比较好的地方

从当前仓库看，AI / RAG 这条线已经不只是“计划正确”，而是已经有了比较稳的基础：

- 已有统一 AI Provider 适配层
- 已有简历分析、结构化建议、草稿应用链路
- 已有最小 RAG 状态、重建、检索、问答接口
- 已有简历 YAML 知识源与博客知识源同步
- 已有本地 JSON 索引落地
- 已有 `mock` 兜底，适合开源与教学环境

这意味着：

当前更应该做的是**收口、补稳和继续沉淀文档**，而不是推倒重选技术栈。

## 八、我建议继续优化的点

### 1. 拆分 chat model 与 embedding model

当前 Provider 抽象里，文本生成与向量化共用了同一个 `model` 概念。

这在部分 OpenAI-compatible Provider 中会有隐性耦合：

- 聊天模型不一定支持 embedding
- embedding 模型未必应该和对话模型同名

后续建议：

- 增加 `chatModel`
- 增加 `embeddingModel`
- 保持默认值兼容当前配置

这样后续迁移不同 Provider 时会更稳。

### 2. 增加索引过期判断

当前索引不存在时会重建，但如果源文件已更新，系统还不能直接判断“索引是否过期”。

后续建议：

- 给简历源和博客源计算 hash
- 在索引中记录 `sourceHash`
- `status` 中返回是否过期

这样更有利于：

- 后台状态展示
- 手工调试
- 后续 Agent 化的自动决策

### 3. 丰富 source metadata

当前 chunk 已经有 `sourceType / sourcePath / section`，这已经足够做最小闭环。

后续可继续增加：

- `topic`
- `entity`
- `period`
- `company`
- `project`
- `tags`

这样以后做更细的筛选、重排序和引用展示会更自然。

### 4. 继续把“可解释性”做厚一点

当前系统已经能回答问题，但后续如果要更贴近 Dao-is-Coding 的“状态可接”，可以继续补：

- 本轮检索命中了哪些 chunk
- 为什么命中这些 chunk
- 最终答案基于哪些来源生成
- 哪些结论是上下文不足时的保守表达

这会让 RAG 不只是“能用”，而是“更容易被人接住和判断”。

## 九、当前不建议急着做的事情

如果当前阶段就去做下面这些东西，容易让项目节奏失控：

- 接本地 embedding 模型
- 上 `Chroma` 或 `pgvector`
- 加重排序模型
- 做复杂多轮 Agent 编排
- 做知识库后台管理系统
- 做分析历史、任务中心和复杂异步流转

这些方向不是没有价值，而是**现在做，教学收益未必高，复杂度却会明显上升**。

## 十、阶段性结论

如果只站在 `my-resume` 当前阶段来判断，这条技术路线是成立的：

- `Node.js + apps/server`
- 现有 AI Provider 适配层
- `YAML` 原始语料
- 语义块切片
- 远端 embeddings
- 本地 JSON 索引
- 最小 RAG API

它的优点不是“最重最全”，而是：

- 足够轻
- 足够稳
- 足够清晰
- 足够适合教学和持续演进

所以当前更合理的判断不是：

> 要不要重新选择技术栈？

而是：

> 当前技术栈已经选对了，下一步应该继续做哪些补稳和收口？

## 十一、建议的下一步顺序

如果继续沿着当前路线迭代，建议优先顺序是：

1. 拆分 `chatModel / embeddingModel`
2. 增加索引过期判断与状态字段
3. 丰富 chunk metadata
4. 补更强的来源解释与调试信息
5. 再考虑更重的检索增强或存储升级

## 十二、一句话总结

`my-resume` 当前的 AI / RAG 技术栈不是“临时凑出来的过渡方案”，而是一条**非常贴合项目阶段、实现成本、教程目标与后续演进节奏的正确路线**。
