一、项目背景
在学习大模型应用的过程中，我发现：
- 通用大模型无法回答私有知识
- 在线API存在成本和隐私问题
于是我尝试搭建一个本地RAG智能客服系统，实现： 👉 私有知识问答 + 本地推理 + 可控成本
二、整体架构
系统核心流程如下：
文档 → 切分 → 向量化 → 存储 → 检索 → 构建上下文 → LLM生成答案
技术选型：
- 前端：Streamlit
- 向量数据库：Chroma
- Embedding：HuggingFace
- LLM：Ollama（DeepSeek-R1）
💡 这里的关键在于：RAG并不是简单“拼接上下文”，而是通过向量检索，将用户问题映射到语义相似的知识片段，从而让大模型具备“基于私有知识回答”的能力。
相比直接调用大模型，这种方式的优势是：
- 可控：回答来源于已有知识
- 可解释：可以追溯到具体文档片段
- 成本低：无需频繁调用外部API
三、核心流程实现
3.1 文档处理
将原始文档进行切分（chunk），保证语义完整性。
3.2 向量化
使用 HuggingFace Embeddings 将文本转换为向量。
3.3 向量存储
使用 Chroma 存储向量数据，支持快速相似度检索。
3.4 检索（RAG核心）
根据用户问题，检索 top-k 相关文本片段。
这里 top-k 的选择会直接影响回答效果：
- k太小：信息不足，回答不完整
- k太大：引入噪声，影响生成质量
因此需要根据实际场景进行调优。
3.5 LLM生成
将检索结果拼接为上下文，交给本地大模型生成回答。
四、效果展示
系统可以基于私有文档进行问答，例如：
用户提问：xxx
系统回答：xxx（基于检索内容生成）
相比传统问答，回答更加准确且可追溯。
五、总结
这个项目让我完整理解了：
- RAG 的核心流程
- 向量数据库的使用方式
- 本地大模型部署与调用
同时也发现了一些问题：
- chunk切分策略会影响效果
- embedding模型质量很关键
后续优化方向：
- 引入更强的embedding模型
- 增加多轮对话能力
- 优化检索策略
从工程角度来看，这个项目本质是一个最小可用的AI应用系统（AI Agent雏形）：
- 数据层：文档 + 向量数据库
- 检索层：相似度搜索
- 生成层：本地大模型
它让我第一次把“大模型能力”真正落地到具体系统中，而不是停留在调用API层面。
