从RAG实战看大模型应用开发：掌握AI工程能力的关键路径

最近 Anthropic 高薪挖人的话题在技术圈讨论得很热。有消息提到，为了在顶尖 AI 人才争夺战中占得先机，Anthropic 给出了数倍于市场水平的薪资，甚至有说法是市场价的 6 倍。更耐人寻味的是，CEO 随后表达了一个担忧：如果新员工只是冲着钱来，团队的长期使命感和投入度会不会被稀释。网友的回应也很直接——既然担心大家为钱而来，那把薪资降回市场水平试试。

调侃归调侃，这件事对普通开发者其实有两点真实启发。第一，AI 人才需求远没有饱和，关键岗位的薪资空间依然很大。第二，企业愿意花这么高的成本去招人，说明他们需要的根本不是“会调用接口”的初级玩家，而是能把 AI 能力稳定落地到业务系统中的工程人才。本文不打算加入口水仗，而是把“AI 应用工程能力”这件事拆开来讲。

接下来，我会从一段可运行的 Claude API 应用开发实战入手，实现一个带检索增强生成（RAG）的知识库问答助手，并围绕它梳理大模型应用开发的完整链路、常见问题和工程化建议。无论你是刚接触大模型应用开发的新手，还是想转向 AI 应用方向的 Python / Java 后端工程师，都可以按本文步骤完整复现。

1. 事件背景：高薪抢人背后的 AI 人才竞争

1.1 高薪抢人事件的来龙去脉

Anthropic 是 Claude 大模型背后的公司，也是当前 AI 领域最受关注的创业公司之一。围绕这次“6 倍薪资抢人”的讨论，核心信息其实很清晰：头部 AI 公司之间的竞争，已经从模型能力比拼，蔓延到了人才争夺。

这件事之所以引发大量讨论，是因为它同时触动了两个敏感点：

• 高薪：6 倍于市场水平的薪资，确实超出大多数行业的想象空间。
• 动机：当一家公司用远高于行业平均的薪资去吸引人时，员工加入的动机到底是“认同使命”还是“认可价格”，本身就是一个很难回答的问题。

CEO 的担忧并非毫无道理。AI 研究和技术突破往往需要长期投入，如果团队成员的短期利益诉求过强，遇到研究瓶颈时容易出现人员波动。但网友的嘲讽也说出了另一层逻辑：薪资本身就是市场对人才价值的定价，高薪挖人是市场竞争的自然结果。与其纠结员工为什么来，不如关注公司能不能给人才提供持续的成长空间。

1.2 高薪背后：市场真正需要什么能力

抛开情绪化讨论，我们需要看到高薪背后的真实需求。顶尖 AI 公司愿意付出高成本，但他们对“人才”的定义并不局限于会训练模型的算法工程师。

从招聘要求和高频岗位画像来看，当前 AI 领域最紧缺的是以下几类能力：

• 能把大模型 API 接入现有业务系统，完成工程化落地的后端工程师。
• 能处理数据清洗、知识库构建、检索优化等中间环节的数据工程人才。
• 能设计评测集、对模型输出效果做持续评估和回归测试的质量工程师。
• 能处理安全、权限、成本控制、合规风险的 AI 应用架构师。

换句话说，模型能力越来越强之后，真正的瓶颈已经转移到“应用层工程能力”。这也解释了为什么很多 AI 公司不仅高薪招算法研究员，也在高薪招优秀的应用开发者。

1.3 对普通开发者的启示

如果你还停留在“大模型应用开发 = 调 API”的认知阶段，确实应该感到一丝紧迫感。因为调 API 人人都会，这项能力不构成长期竞争力。

但也不用焦虑。大模型应用开发正处于基础设施快速完善的阶段，应用层的创新空间非常大。掌握 LLM 应用开发的基本链路，包括 Prompt 设计、RAG、工具调用、评测和监控，就已经能让你在市场上获得不错的议价能力。本文后面的内容，就是一条低成本、可复制的入门路径。

2. 核心概念：AI 应用开发的关键能力拆解

在开始写代码之前，先建立几个必要的概念。大模型应用开发并不是“把问题丢给模型”这么简单，一个合格的应用需要你理解完整的调用链路。

2.1 LLM 应用开发的基本链路

一个最基础的大模型应用调用链路如下：

用户输入 → Prompt 组装 → 调用模型 API → 解析输出 → 返回给用户

在简单场景下，这个链路就够了。但在真实业务中，你往往需要加入更多环节：

用户输入 → 意图识别/检索 → Prompt 组装（注入上下文） → 调用模型 API → 工具调用 → 解析输出 → 结果校验 → 返回

其中每一步都有对应的工程问题。比如：

• 用户输入是否需要安全校验？
• 检索出来的资料如何组织进 Prompt？
• 模型输出是不是稳定可解析的格式？
• 调用失败后如何降级？

这些问题的集合，就是“AI 应用工程能力”。它不要求你懂得如何训练模型，但要求你对模型的行为边界有清晰认知。

2.2 Prompt Engineering：应用开发的基石

Prompt 是用户传给模型的指令。Prompt Engineering（提示工程）则是通过设计指令内容，让模型更稳定地完成任务的实践。

一个高质量的 Prompt 通常包含以下要素：

1. 角色设定：告诉模型它是什么身份，比如“你是知识库问答助手”。
2. 任务描述：明确要求模型完成什么任务。
3. 上下文材料：把检索到的资料或业务数据填入 Prompt。
4. 约束条件：比如“只依据资料回答”“不要编造事实”“控制在 200 字以内”。
5. 输出格式：比如 JSON、Markdown 或纯文本。

举个例子，同样的任务，如果只写“回答我的问题”，模型可能给出任意风格的回答。但如果加上约束和上下文，输出的稳定性和可用性会大幅提升。

2.3 RAG：解决模型知识不足的问题

RAG（Retrieval-Augmented Generation，检索增强生成）是目前大模型应用落地中最重要的模式之一。

为什么需要 RAG？因为大模型的知识来源于训练数据，存在三个天然局限：

• 训练数据有截止时间，无法感知最新信息。
• 模型不了解企业私有数据，比如内部制度、产品文档。
• 模型在不确定时会“一本正经地胡说八道”，也就是幻觉。

RAG 的思路是：在调用模型之前，先从外部知识库中检索与问题相关的资料，把资料作为上下文注入 Prompt，让模型“看着资料回答”。这样做的好处有三个：

• 回答有依据，幻觉风险显著降低。
• 知识库可以随时更新，不需要重新训练模型。
• 可以精确控制回答范围，只基于指定资料作答。

RAG 的基本流程：

文档加载 → 文本切分 → 向量化 → 存入向量库 → 用户提问 → 向量检索 → 注入 Prompt → 模型生成

之后的实战部分，我会完整实现这条链路。

2.4 Function Calling：让模型学会调用工具

Function Calling（函数调用/工具调用）是另一个高频能力。它允许模型在对话过程中，根据用户意图输出一个结构化的“调用请求”，然后由你的代码去执行真实操作，比如查数据库、发 HTTP 请求、调第三方服务。

在 Anthropic API 中，工具调用的基本思路是：你预先定义好一个工具列表，模型根据用户输入决定是否调用工具，并返回结构化参数。

tools = [ { "name": "get_weather", "description": "查询指定城市的实时天气", "input_schema": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如 北京" } }, "required": ["city"] } } ]

这个能力让大模型从一个“问答机器”升级为“能行动的智能体”。日常工作中常见的订单查询、工单流转、数据报表生成，都可以通过 Function Calling 与内部系统打通。

3. 环境准备与版本说明

3.1 技术选型

本文实战项目的技术栈如下，大家可以根据自己环境做等价替换：

• 操作系统：Windows / macOS / Linux 均可。
• Python：建议 3.10 及以上版本。
• Anthropic Python SDK：用于调用 Claude API。
• sentence-transformers：用于本地文本向量化，生成检索用的向量。
• numpy：用于向量相似度计算。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。如果项目对 Python 版本有严格限制，请先确认各个依赖包对 Python 版本的支持情况。

3.2 创建项目与虚拟环境

先创建项目目录并初始化 Python 虚拟环境。

mkdir rag-bot cd rag-bot python -m venv venv

激活虚拟环境：

Windows：

venv\Scripts\activate

macOS / Linux：

source venv/bin/activate

然后安装依赖：

pip install anthropic sentence-transformers numpy

如果你需要使用固定版本，可以在 requirements.txt 中写清楚版本号。本文为了保持可复制性，先不固定版本，实际操作时建议生成 lock 文件。

3.3 获取并配置 API Key

调用 Claude API 需要 Anthropic 官方账号和 API Key。请根据你的网络环境和账号申请情况准备，申请后把 Key 保存到环境变量中，避免硬编码在代码里。

macOS / Linux：

export ANTHROPIC_API_KEY=sk-ant-xxxxxxxx

Windows PowerShell：

$env:ANTHROPIC_API_KEY="sk-ant-xxxxxxxx"

这里需要特别强调：API Key 等同于账号的访问凭证，不要把它提交到 Git 仓库，不要写死在代码中，更不要截图发到公共平台。如果怀疑泄露，第一时间到控制台吊销并重新生成。

3.4 准备测试文档

为了让 RAG 有东西可以检索，我们准备一份测试文档。在项目根目录下创建 data 目录，并新建 knowledge.txt 文件。

# 产品研发项目管理规范 ## 需求评审 每个迭代开始前，产品经理需要组织需求评审会议，开发和测试必须参加。需求文档需要包含背景、目标、范围、验收标准四个部分。没有通过评审的需求不能进入开发。 ## 代码审查 所有代码合并前必须通过 Code Review。每次评审至少需要一名高级开发参与。重点检查业务逻辑、异常处理、安全权限、日志埋点。 ## 发布流程 正式环境发布前，需要在预发环境完成冒烟测试。发布窗口为每周二和周四下午。发布失败时，必须优先执行回滚操作，然后再排查原因。 ## 线上故障处理 发生 P0 故障时，值班人员需要在 5 分钟内响应，第一时间恢复服务，然后同步故障信息。事后需要输出故障报告，包含时间线、根因、改进措施。

这份文档内容不长，但足够演示完整的检索问答流程。

4. 完整实战：基于 Claude API 的 RAG 知识库问答助手

下面进入核心环节。我们的目标是实现一个命令行问答程序，用户输入问题，程序从知识库中检索相关片段，再调用 Claude 生成回答。

4.1 项目结构设计

先规划好项目结构，后续每个文件都有明确职责。

rag-bot/ ├── config.py # 配置项 ├── document_loader.py # 文档加载与切分 ├── vector_store.py # 向量化与检索 ├── rag_bot.py # RAG 问答逻辑 ├── main.py # 程序入口 └── data/ └── knowledge.txt # 测试文档

按职责拆分文件，是为了让代码更容易测试和扩展。比如后续想换 embedding 模型，只需要修改 config.py 和 vector_store.py。

4.2 编写配置文件

config.py 集中管理所有配置。注意 API Key 从环境变量读取，不进代码仓库。

# 文件路径：config.py import os # 从环境变量读取 API Key，避免硬编码 ANTHROPIC_API_KEY = os.environ.get("ANTHROPIC_API_KEY", "") # 模型名称以官方文档为准，不同时期可用模型会有变化 CLAUDE_MODEL = "claude-3-5-sonnet-20241022" # 本地向量化模型 EMBEDDING_MODEL = "all-MiniLM-L6-v2" # 测试文档路径 DOCUMENT_PATH = "./data/knowledge.txt"

这里有两个注意点。第一，模型名称需要以官方文档为准，因为 Anthropic 会不定期更新可用模型列表。第二，embedding 模型首次运行时需要联网下载，后续会缓存在本地。

4.3 实现文档加载与切分

document_loader.py 负责读取文本，并按长度切分成片段。

# 文件路径：document_loader.py from typing import List def load_document(file_path: str) -> str: """读取本地文本文件内容。""" with open(file_path, "r", encoding="utf-8") as f: return f.read() def split_text(text: str, chunk_size: int = 500) -> List[str]: """按段落切分文本，并合并到接近 chunk_size 的片段。""" paragraphs = [p.strip() for p in text.split("\n") if p.strip()] chunks: List[str] = [] current = "" for para in paragraphs: if len(current) + len(para) + 1 > chunk_size and current: chunks.append(current) current = para else: current = f"{current}\n{para}" if current else para if current: chunks.append(current) return chunks

为什么需要切分？因为模型对上下文长度有限制，而且过长的片段会引入无关信息，降低检索精度。这里用的切分策略很简单：按段落合并到 500 字左右。实际项目中可以引入滑动窗口、标题感知切分等更精细的策略。

4.4 实现向量化与检索

vector_store.py 负责把文本片段向量化，并在收到查询时返回最相关的片段。

# 文件路径：vector_store.py from typing import List import numpy as np from sentence_transformers import SentenceTransformer class VectorStore: def __init__(self, model_name: str): self.model = SentenceTransformer(model_name) self.chunks: List[str] = [] self.vectors = None def add_documents(self, chunks: List[str]) -> None: """将文档片段向量化并保存。""" self.chunks = chunks self.vectors = self.model.encode(chunks) def search(self, query: str, top_k: int = 3) -> List[str]: """检索与查询最相似的 top_k 个片段。""" query_vec = self.model.encode([query])[0] scores = np.dot(self.vectors, query_vec) / ( np.linalg.norm(self.vectors, axis=1) * np.linalg.norm(query_vec) + 1e-9 ) top_indices = np.argsort(scores)[-top_k:][::-1] return [self.chunks[i] for i in top_indices]

检索的核心是余弦相似度：先计算查询向量，再和所有片段向量做点积并进行归一化，得分最高的片段就是最相关的上下文。这里用了一个很小的 embedding 模型，实际业务中建议根据语言类型和领域数据选更合适的模型。

4.5 实现 RAG 问答逻辑

rag_bot.py 是最核心的文件，负责组装 Prompt 并调用 Claude。

# 文件路径：rag_bot.py import anthropic from config import ANTHROPIC_API_KEY, CLAUDE_MODEL from vector_store import VectorStore class RAGBot: def __init__(self, vector_store: VectorStore): self.vector_store = vector_store self.client = anthropic.Anthropic(api_key=ANTHROPIC_API_KEY) def build_prompt(self, question: str, top_k: int = 3) -> str: """根据检索结果构建 Prompt。""" contexts = self.vector_store.search(question, top_k=top_k) context_text = "\n\n---\n\n".join(contexts) prompt = f"""你是知识库问答助手。请根据以下参考资料回答用户问题。 回答要求： 1. 只依据参考资料回答，不要编造事实。 2. 如果资料中没有相关信息，请明确回答“资料中未找到相关信息”。 3. 回答尽量简洁，控制在 200 字以内。 参考资料： {context_text} 用户问题：{question} """ return prompt def answer(self, question: str, top_k: int = 3) -> str: """回答用户问题。""" prompt = self.build_prompt(question, top_k=top_k) message = self.client.messages.create( model=CLAUDE_MODEL, max_tokens=1024, messages=[{"role": "user", "content": prompt}], ) return message.content[0].text

这段代码里有几个值得注意的细节。

第一，Prompt 中明确写了“只依据参考资料回答”“不要编造事实”，这是抑制幻觉最关键的一步。第二，要求模型输出控制在 200 字以内，避免回答过长。第三，max_tokens 限制了模型最多生成的 token 数，既能控制成本，也能防止异常输出。

4.6 运行与验证

最后编写 main.py 入口程序。

# 文件路径：main.py from config import DOCUMENT_PATH, EMBEDDING_MODEL from document_loader import load_document, split_text from rag_bot import RAGBot from vector_store import VectorStore def main(): print("正在加载文档并构建向量索引...") text = load_document(DOCUMENT_PATH) chunks = split_text(text) print(f"文档已切分为 {len(chunks)} 个片段") store = VectorStore(EMBEDDING_MODEL) store.add_documents(chunks) print("向量索引构建完成") bot = RAGBot(store) while True: question = input("\n请输入问题（输入 exit 退出）：").strip() if question.lower() == "exit": break if not question: continue print("正在生成回答...") answer = bot.answer(question) print(f"\n回答：{answer}") if __name__ == "__main__": main()

运行程序：

python main.py

预期输出：

正在加载文档并构建向量索引... 文档已切分为 4 个片段 向量索引构建完成 请输入问题（输入 exit 退出）：发布流程是什么？ 正在生成回答... 回答：正式环境发布前，需要在预发环境完成冒烟测试。发布窗口为每周二和周四下午。发布失败时，必须优先执行回滚操作，然后再排查原因。

可以再尝试问一个文档里没有的问题，比如“公司年假制度是什么”，模型应该会回答“资料中未找到相关信息”，而不是编造一个答案。

5. 常见问题与排查思路

在实际运行中，你大概率会遇到一些报错或效果问题。下面把高频问题整理成表，再逐个展开说明。

5.1 API 调用类问题

401 错误通常发生在两个阶段：一是环境变量没有正确设置，二是 API Key 已经失效。排查时可以先在终端打印环境变量确认是否生效，再到控制台检查 Key 状态。

404 错误则是模型名称填写问题。大模型厂商会不断更新模型列表，旧的模型名可能被下线，因此建议在代码中把模型名称放到配置项里，方便统一修改。

5.2 检索效果类问题

如果模型回答的内容和知识库明显不符，问题通常不在模型，而在检索环节。可能的原因包括：

• 文本切分粒度不合适，片段太短缺少上下文，片段太长引入噪音。
• top_k 设置过大，把不相关的内容也注入 Prompt。
• embedding 模型对中文或领域术语支持不够好。

排查时可以先打印检索结果，确认注入 Prompt 的资料是否真的和问题相关。只有检索准确，RAG 的效果才有保证。

5.3 长文本与上下文问题

当知识库很大时，会出现两个问题：一是检索性能下降，二是注入片段超出模型上下文上限。

建议方案是：

• 使用专门的向量数据库（如 Chroma、Qdrant、Milvus）替代内存存储。
• 控制 top_k 的大小，一般 3 到 5 个片段足够。
• 对超长文档做更细的切分，并保证切分边界尽量与语义边界一致。

6. 最佳实践与工程建议

完成了可运行的 Demo，只能算入门。真正到生产环境，还需要解决很多工程问题。下面几条经验是从项目实践中沉淀下来的，建议收藏备用。

6.1 API Key 与配置管理

配置管理的核心原则是“代码与配置分离”。API Key、数据库连接串、模型名称这些内容，在开发环境用环境变量或本地配置文件，在测试和生产环境用配置中心或 CI/CD 变量注入。

另外建议为 API Key 设置访问控制，只授予必要权限。在团队协作中，不要把真实 Key 放到共享文档里。

6.2 Prompt 版本管理

Prompt 是 AI 应用的核心资产，值得像代码一样管理。建议把 Prompt 模板单独放到文件或配置中，而不是散落在业务代码里。

prompts/ ├── rag_answer.txt ├── summarizer.txt └── classifier.txt

每次修改 Prompt 后，记录变更原因，并通过评测集验证效果，避免“改好一个问题，搞坏另一个问题”。

6.3 建立评测回归机制

AI 应用的输出具有不确定性，因此更需要一套评测机制。最简单的方式是准备 20 到 50 个标准问题，每次改完 Prompt 或检索逻辑后，批量运行一遍，对照期望答案人工打分。

更进阶的做法是把评测纳入 CI/CD，用自动化指标（如召回率、答案相似度）监控效果变化。没有评测体系，AI 应用的迭代就是在“盲调”。

6.4 成本控制与缓存

API 调用按 token 计费，成本会随用户量增长快速上升。控制成本可以从三个方向入手：

• 对重复问题做缓存，命中缓存就直接返回。
• 合理设置 max_tokens，不要给模型无限生成空间。
• 在 Prompt 中要求简洁回答，减少输出 token。

此外，日常开发阶段可以使用更小的模型做联调，上线前再切换到效果更好的模型。

6.5 安全与合规边界

在涉及安全、权限、认证、数据库操作等场景时，必须强调合法授权、测试环境验证、备份和最小权限原则。大模型应用也不例外：

• 对用户输入做长度和内容校验，防止恶意 Prompt 绕过限制。
• 不要在 Prompt 中注入过于敏感的信息，日志中避免记录完整用户输入。
• 如果 RAG 检索的是企业私有数据，必须做好权限隔离，确保用户只能检索到授权范围内的文档。
• 涉及删除、修改类工具调用时，必须二次确认并保留操作日志。

7. 总结与下一步学习路线

回到开头的话题。Anthropic 高薪抢人的新闻，反映出 AI 行业对人才的强烈渴求。但高薪从来不是衡量人才价值的唯一标准，真正能让你在行业中立住脚的，是把技术转化为业务结果的能力。通过本文的实战，你已经完成了一个 RAG 知识库问答助手的开发，掌握了文档加载、文本切分、向量检索、Prompt 组装、模型调用这条完整的 AI 应用链路。

如果接下来想继续深入，建议按这个顺序推进：

1. 先把本文代码跑通，并用自己的文档替换测试数据。
2. 学习 Function Calling，让模型能够调用工具、执行动作。
3. 了解 Agent 的工作方式，尝试做一个简单的多步任务。
4. 熟悉日志、监控、评测，把 Demo 改造成可上线的服务。
5. 再回头补充大模型原理知识，比如 Tokenizer、Transformer、微调方法。

大模型应用开发的技术栈还在快速演进，但核心的工程能力是通用的：清晰的思路、稳定的 Prompt、可靠的检索、可观测的运行状态。如果你在复现本文代码时遇到问题，欢迎在评论区贴出报错信息，也可以分享你实际构建的知识库场景。实践是最好的学习方式，动手跑一遍，比看十篇教程都有用。