什么是”真正能用”的 AI 应用
2025 年的时候,市面上充斥着各种”AI 应用”——AI 写作助手、AI 翻译工具、AI 聊天机器人。大多数都不过是把一个大模型的 API 包了一层 UI。它们有一个共同的问题:当模型”不知道”的时候,它们就开始编造。
真正有价值的 AI 应用必须解决两个问题:第一,让模型知道它不知道什么;第二,当模型不知道的时候,它能从外部获取正确的信息。这就是 RAG(Retrieval-Augmented Generation)要解决的问题。
而 Agent 更进一步——它不只是给模型提供信息,还让模型有能力”做”事情:调用工具、查询数据库、执行代码、发送邮件。
DeepSeek 在这两个方向上都提供了非常好的支持。V4-Flash 的 100 万 token 上下文让 RAG 的检索范围大幅扩大,而 API 层的 Tool Calls 支持让 Agent 架构变得简单。这篇文章我就从架构设计到代码实现,完整讲一遍。
RAG 架构设计
什么是 RAG
RAG 的核心思想很简单:在让模型回答用户问题之前,先从外部知识库中检索相关信息,然后把检索到的内容作为上下文提供给模型。模型的回答就基于这些检索到的信息。
1 | 用户提问 → 向量检索 → 检索结果 + 用户问题 → LLM 生成回答 |
为什么 DeepSeek 特别适合 RAG
第一,V4-Flash 的 100 万 token 上下文是 RAG 的杀手级能力。传统的 RAG 系统受限于模型的上下文长度(通常 8K-32K tokens),只能检索少量相关文档。V4-Flash 的 100 万 token 意味着你可以直接把大量文档塞进上下文,让模型自己筛选——这是一种更简单、更强大的 RAG 范式。
第二,DeepSeek 的训练数据规模(32T+ tokens)让它对中文和英文都有很好的理解能力,适合做跨语言检索。
第三,价格优势。RAG 系统的输入 token 消耗通常很大(因为要检索大量文档),V4-Flash 的输入价格(3 元/百万 tokens)让大规模 RAG 在成本上变得可行。
RAG 的两种模式
模式一:传统 RAG(检索增强)
适合场景:文档库较大(10 万+ 文档),用户问题多样化。
流程:
- 将文档切片并计算向量嵌入
- 用户提问时,计算问题的向量
- 在向量数据库中搜索最相似的 K 个文档片段
- 将检索结果拼接为上下文,发送给模型
模式二:超长上下文 RAG(直接塞入)
适合场景:文档库较小(1000 篇以内),模型上下文长度足够大。
流程:
- 把所有相关文档直接拼接到上下文中
- 告诉模型”下面这些是你的参考资料”
- 模型基于完整上下文生成回答
在 V4-Flash 的 100 万 token 上下文支持下,模式二变得非常实用。对于 500 篇以内的文档库,直接塞入的方式反而更简单、更可靠——不需要复杂的向量检索系统。
RAG 实现:完整代码示例
方案一:基于 LangChain 的传统 RAG
1 | from langchain_deepseek import DeepSeekChat |
方案二:基于超长上下文的简单 RAG
这是 V4-Flash 的 100 万 token 上下文带来的简化方案——不需要向量数据库,不需要检索器:
1 | from openai import OpenAI |
这种方案虽然简单,但对于中小规模的文档库(几千篇以内)效果非常好。它避免了向量检索中常见的”检索不到相关文档”的问题。
Agent 架构设计
Agent 的核心组件
一个完整的 Agent 系统包含三个核心组件:
- LLM(大语言模型):负责理解用户意图、规划任务步骤、决定调用哪些工具
- Tools(工具集):可以被 LLM 调用的外部功能,比如搜索、计算、查询数据库
- Memory(记忆):存储上下文信息,让 Agent 在多轮对话中保持一致性
DeepSeek 的 Tool Calls 支持
DeepSeek 的 API 原生支持 Tool Calls,格式完全兼容 OpenAI:
1 | from openai import OpenAI |
一个完整的 Agent 应用:智能知识库助手
下面是一个更完整的 Agent 应用示例,结合了 RAG 和工具调用:
1 | import json |
架构决策:什么时候用 RAG,什么时候用 Agent
纯 RAG 适用场景
- 用户问题有明确的知识来源
- 不需要执行外部操作
- 答案可以从现有文档中找到
- 典型的 QA 系统、文档问答、知识库助手
纯 Agent 适用场景
- 需要调用外部 API 获取实时数据
- 需要执行多步骤操作
- 需要与多个系统交互
- 典型的自动化工作流、数据分析助手、操作型机器人
RAG + Agent 结合
对于复杂场景,两者结合效果最好:
1 | 用户请求 |
性能与成本控制
RAG 和 Agent 系统的 token 消耗通常比普通对话大很多。一些优化建议:
RAG 优化
- 控制检索数量:通常检索 3-5 个文档片段就足够了。过多的上下文反而会降低模型的回答质量。
- 使用缓存:相同系统提示词的缓存命中率可以显著降低输入成本。
- 考虑文档预处理:在检索前对文档做摘要或提取关键信息,减少发送给模型的 token 量。
Agent 优化
- 限制工具调用轮数:设置合理的
max_iterations(通常 3-5 轮),防止 Agent 陷入无限循环。 - 选择正确的工具:工具越多,Agent 的选择成本越高。只暴露真正需要的工具。
- 思考模式的权衡:Agent 的思考模式有助于做出更好的工具调用决策,但会增加 2-3 倍的 token 消耗。对于简单任务,可以关闭思考模式。
实际项目的架构建议
如果你正在开发一个基于 DeepSeek 的 AI 应用,我的建议架构是:
1 | 前端层:Web UI / 移动端 / CLI |
关键设计原则:
- Agent 编排层是核心——它决定何时调用 LLM、何时检索、何时调用工具
- 用 V4-Flash 处理 80% 的请求,V4-Pro 处理 20% 的复杂请求
- 所有外部依赖(向量数据库、API 等)都应该有 fallback 策略
- 记录完整的对话日志,用于后续分析和调试
总结
DeepSeek 为 RAG 和 Agent 应用提供了非常好的基础:100 万 token 的上下文长度、原生 Tool Calls 支持、以及极具竞争力的定价。这三个条件的组合,让构建真正”有用”的 AI 应用在技术和成本上都变得可行。
但技术从来不是唯一的问题。我在这条系列文章中反复强调的一点是:真正的价值不在于你能调用多强的模型,而在于你能否构建一个系统——它能知道什么时候该用模型,什么时候该检索,什么时候该调用工具。
把 DeepSeek 作为一个组件,而不是一个产品,这才是它真正的价值所在。