企业官网建设流程全解析

1. 从零搭建AI工程能力：为什么我劝你别一上来就啃论文

这两年AI岗位的需求量涨得离谱，打开任何一个招聘平台，搜“AI工程师”，出来的岗位描述里十有八九写着“熟悉大模型原理”“有RAG落地经验”“掌握LangChain/LlamaIndex”这类要求。很多人一看就慌了，转头去买一堆《深度学习》砖头书，或者从Transformer论文原文开始硬啃，结果啃了两个月，连一个能跑起来的问答机器人都没做出来。

我特别理解这种焦虑。我自己当年也是这么过来的——先啃理论，再想动手，结果理论没啃透，动手能力也没练出来，两头空。后来我才想明白一件事：AI工程和AI研究是两条完全不同的路。研究是搞清楚“为什么这样设计有效”，工程是搞清楚“怎么把已有的东西拼起来解决实际问题”。你不需要自己推导反向传播，就像你不需要自己造一台发动机才能开车。

“ai-engineering-from-scratch”这个方向，核心就是解决这个错位问题。它面向的是那些想进入AI工程领域、但被传统学习路径劝退的人。不管你是后端转行、前端想拓展、还是刚毕业的计算机学生，只要你会写基本的Python，能看懂API文档，就可以从零开始搭建一套完整的AI工程能力栈。这篇文章我会把整个学习路径、每个阶段的核心技术点、实操中踩过的坑，以及可以直接抄作业的代码方案，全部摊开讲清楚。

2. 整体学习路径设计：先跑通再深挖，别反过来

2.1 为什么“自底向上”的学习方式在AI工程里行不通

传统计算机科学的教育路径是自底向上的：先学数字电路，再学计算机组成原理，然后操作系统、编译原理，最后才是应用层。这套路径对打基础确实有效，但放到AI工程领域，问题就大了。

AI工程的技术栈迭代速度极快。你今天花三个月啃完的某个框架源码，下个月可能就被新版本重构了。更关键的是，AI工程的核心能力不是“理解某个算法的数学推导”，而是“在不确定的环境下快速搭建可用的系统”。这两种能力需要的训练方式完全不同。

我试过带过几个新人，一开始就让他们读Attention Is All You Need那篇论文，结果一周后他们连PyTorch的DataLoader怎么用都还不熟。后来我换了策略：先让他们用现成的API做一个能对话的机器人，哪怕底层原理一知半解，先跑通再说。结果三天就能出demo，两周后他们自己就开始主动去查注意力机制的细节了——因为他们在调参时遇到了实际问题，有了“想知道为什么”的驱动力。

注意：这不是说理论不重要，而是说学习的顺序应该是“先用起来，再搞明白”。有了实际体感之后再去补理论，效率至少翻倍。

2.2 三阶段能力模型：调用者、构建者、优化者

我把AI工程能力分成三个阶段，每个阶段的目标和产出物都不一样：

大部分人的问题在于，他们想直接从“调用者”跳到“优化者”，跳过了“构建者”阶段。结果就是：demo能跑，但一上生产就崩。我见过太多团队花大价钱调了模型，结果发现瓶颈根本不在模型，而在数据清洗和检索策略上。

2.3 工具选型：别追新，追稳

AI领域的工具更新速度堪比时装周，今天LangChain明天LlamaIndex，后天又冒出个新框架。我的建议是：在“调用者”阶段，只用最基础的库。

具体来说，Python环境下你只需要这几样东西：

• openai或anthropic的官方SDK（用于调用大模型API）
• requests或httpx（用于调用其他HTTP接口）
• python-dotenv（管理API密钥）
• streamlit或gradio（快速搭界面）

就这些。不要一上来就上LangChain，那玩意儿抽象层太多，出了问题你根本不知道是哪里卡住了。等你手写RAG流程写到第三遍，觉得“每次都要重复写这些代码好烦”的时候，再去用框架，那时候你才能真正理解框架帮你解决了什么问题。

3. 核心细节解析：从调用API到搭建RAG的完整技术栈

3.1 大模型API调用的五个关键参数

很多人调API就是复制粘贴官方示例，改个prompt就完事。但实际工程中，有几个参数直接决定了你的应用能不能用：

temperature：控制输出的随机性。做事实性问答时设0.1-0.3，做创意写作时设0.7-0.9。我见过有人做客服机器人设了0.8，结果同一个问题每次回答都不一样，客户直接投诉。

max_tokens：限制输出长度。这个参数不设的话，有些API会默认给一个很大的值，导致你的账单爆炸。建议根据实际场景设置，比如客服回复一般200-300 tokens足够。

top_p：和temperature配合使用，控制采样范围。一般设0.9-0.95，不需要频繁调整。

frequency_penalty和presence_penalty：控制重复内容。做长文本生成时特别有用，能避免模型反复说同一句话。

stop：停止序列。这个参数很多人忽略，但在结构化输出时极其重要。比如你让模型输出JSON，可以设stop为\n\n，防止它输出多余的解释文字。

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def ask_llm(prompt, system_prompt="你是一个专业的AI助手"): response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": prompt} ], temperature=0.3, max_tokens=500, top_p=0.9, frequency_penalty=0.3, presence_penalty=0.3 ) return response.choices[0].message.content

这段代码看起来简单，但每个参数都是我踩过坑之后调出来的。temperature=0.3是保证回答稳定性的底线，max_tokens=500是防止意外长输出，frequency_penalty和presence_penalty各设0.3是避免重复又不至于让语句变得不自然。

3.2 Prompt工程的三个层次：从能用到好用

Prompt工程不是玄学，它有明确的层次结构：

第一层：指令清晰。这是最基本的要求。不要说“帮我写个东西”，要说“帮我写一封给客户的道歉邮件，原因是发货延迟了三天，语气要诚恳但不卑躬屈膝，控制在200字以内”。指令越具体，输出越可控。

第二层：格式约束。如果你需要结构化输出，必须在prompt里明确格式。比如“请以JSON格式输出，包含以下字段：name, age, occupation”。最好再给一个示例，这叫few-shot prompting。

第三层：思维链引导。对于复杂推理任务，让模型“一步一步思考”能显著提升准确率。具体做法是在prompt末尾加一句“让我们一步一步来分析”，或者给一个推理过程的示例。

我实测下来，对于分类任务，few-shot prompting比zero-shot的准确率能高出15-20个百分点。对于数学推理，思维链引导的效果更明显，有时候能从50%正确率直接拉到80%以上。

3.3 RAG系统的核心组件与常见陷阱

RAG（检索增强生成）是目前AI工程落地最广泛的技术方案。它的核心思路很简单：用户提问 → 从知识库检索相关内容 → 把检索结果和问题一起交给大模型 → 生成回答。

但简单归简单，坑一点都不少。我按组件拆开讲：

文档加载与切分：这是最容易被低估的环节。很多人直接把整个PDF丢进去切，结果切出来的chunk要么太大（包含无关信息），要么太小（丢失上下文）。我的经验是：中文文本按500-800字切分，英文按300-500词切分，同时设置10-15%的重叠区域。对于结构化文档（如Markdown），按标题层级切分效果更好。

向量化与存储：embedding模型的选择直接影响检索质量。OpenAI的text-embedding-3-small性价比最高，中文场景下BGE-M3效果不错。存储用FAISS或Chroma都行，数据量小于10万条时两者性能差异不大。

检索策略：纯向量检索在遇到专有名词时经常翻车。比如用户问“XX-2000型号的参数”，向量检索可能返回一堆不相关的内容。这时候需要混合检索：向量检索+关键词检索（BM25），然后用RRF算法融合结果。

重排序：检索回来的top-10结果里，真正相关的可能只有3-4条。用一个小的cross-encoder模型做重排序，能显著提升最终效果。我常用的是BGE-reranker-base，速度快效果也不错。

from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings # 文档切分 text_splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=100, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) chunks = text_splitter.split_text(raw_text) # 向量化存储 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = FAISS.from_texts(chunks, embeddings) # 检索 retriever = vectorstore.as_retriever( search_type="similarity", search_kwargs={"k": 5} )

这段代码里，separators的顺序很关键。中文文本必须把中文标点放在前面，否则切分出来的chunk会在句子中间断开，严重影响检索质量。这个细节官方文档里不会写，是我切了上千个文档之后总结出来的。

4. 实操过程：从零搭建一个可用的知识库问答系统

4.1 环境准备与依赖安装

先把环境搭起来。我推荐用conda创建独立环境，避免和系统Python冲突：

conda create -n ai-eng python=3.11 conda activate ai-eng pip install openai langchain langchain-community langchain-openai faiss-cpu streamlit python-dotenv pypdf

这里解释一下每个包的作用：openai用于调用GPT接口，langchain系列用于文档处理和检索，faiss-cpu是向量数据库，streamlit用来快速搭界面，pypdf用于读取PDF文档。

提示：faiss-cpu在Windows上安装有时会报错，如果遇到问题可以换成chromadb，API基本兼容。

4.2 文档处理Pipeline的完整实现

假设你有一堆PDF格式的产品手册，需要做成问答系统。完整的处理流程如下：

第一步：加载PDF并提取文本。用pypdf逐页读取，注意有些PDF是扫描件，需要OCR处理，这里先假设是文本型PDF。

第二步：清洗文本。去掉页眉页脚、页码、多余的空格和换行。这一步看起来简单，但不做的话检索质量会差很多。

第三步：切分chunk。用上面提到的RecursiveCharacterTextSplitter，chunk_size=600，overlap=100。

第四步：生成embedding并存入向量库。批量调用embedding接口，注意控制并发数，一般5-10个并发比较稳。

第五步：构建检索QA链。用户提问 → 检索top-5相关chunk → 拼接成context → 交给LLM生成回答。

from pypdf import PdfReader import re def load_and_clean_pdf(file_path): reader = PdfReader(file_path) full_text = "" for page in reader.pages: text = page.extract_text() # 去掉页码和页眉页脚 text = re.sub(r'\n\d+\n', '\n', text) text = re.sub(r'\s+', ' ', text) full_text += text + "\n" return full_text def build_qa_chain(vectorstore, llm_client): def qa(question): docs = vectorstore.similarity_search(question, k=5) context = "\n\n".join([doc.page_content for doc in docs]) prompt = f"""基于以下参考资料回答问题。如果资料中没有相关信息，请直接说"根据现有资料无法回答"。 参考资料： {context} 问题：{question} 回答：""" response = llm_client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.1, max_tokens=800 ) return response.choices[0].message.content return qa

这个QA链里有两个关键设计：一是明确告诉模型“资料中没有就说无法回答”，避免幻觉；二是temperature设0.1，保证回答的稳定性。

4.3 用Streamlit搭一个能用的界面

界面不需要花哨，能上传文档、能提问、能显示回答就行：

import streamlit as st st.title("知识库问答系统") uploaded_file = st.file_uploader("上传PDF文档", type="pdf") if uploaded_file: with st.spinner("正在处理文档..."): text = load_and_clean_pdf(uploaded_file) chunks = text_splitter.split_text(text) vectorstore = FAISS.from_texts(chunks, embeddings) st.success(f"文档处理完成，共{len(chunks)}个片段") question = st.text_input("输入你的问题") if question and uploaded_file: with st.spinner("正在检索..."): answer = qa(question) st.markdown(f"**回答：** {answer}")

这套代码加起来不到100行，但已经是一个可用的知识库问答系统了。我拿它处理过200页的产品手册，检索准确率在80%以上，对于内部工具来说完全够用。

4.4 效果评估：怎么知道你的系统好不好用

很多人做完系统就完事了，从来不评估。这是大忌。没有评估，你根本不知道优化有没有效果。

最简单的评估方法是人工构造测试集：从文档里挑20-30个问题，手动写出标准答案，然后让系统回答，对比准确率。虽然土，但有效。

进阶一点可以用RAGAS框架，它能自动评估faithfulness（回答是否忠于检索内容）、answer_relevancy（回答是否切题）、context_precision（检索内容是否精准）等指标。

我自己的习惯是：每次调整chunk_size、检索数量、prompt模板之后，都跑一遍测试集，记录准确率变化。这样你才能知道哪个参数真正有用。

5. 常见问题与排查技巧实录

5.1 检索不到相关内容怎么办

这是RAG系统最常见的问题。排查思路按以下顺序来：

先看chunk切分是否合理。把检索到的chunk打印出来，看看是不是在句子中间断开了。如果是，调整separators顺序，把中文标点提前。

再看embedding模型是否适合中文。text-embedding-3-small对中文的支持还行，但如果你的文档有大量专业术语，建议换成BGE-M3或者m3e-base。

然后看检索数量。k=5可能不够，试试k=10，然后加重排序。我遇到过一个问题，正确答案在top-15里，但top-5里没有，加了重排序之后就解决了。

最后看query本身。用户的提问方式可能和文档表述差异很大。这时候可以加一个query改写步骤，让LLM先把用户问题改写成更适合检索的形式。

5.2 模型回答出现幻觉怎么处理

幻觉的根源是模型在“编造”而不是“引用”。解决方法有三个层次：

Prompt层面：明确要求“只基于参考资料回答”，并给出无法回答时的标准话术。

检索层面：提高检索精度，确保交给模型的context里确实包含答案。如果context里没有答案，模型编造的概率会大幅上升。

后处理层面：让模型在回答时标注引用来源，比如“根据文档第3页...”。这样即使有幻觉，用户也能快速判断。

我实测下来，prompt层面能解决60%的幻觉问题，检索层面能解决30%，剩下10%需要后处理兜底。

5.3 响应速度太慢怎么优化

AI应用的响应速度直接影响用户体验。优化手段按性价比排序：

流式输出是最容易做的优化，用户看到文字一个个蹦出来，感知等待时间能减少一半以上。缓存的话，对于FAQ类场景特别有效，命中率能到40%以上。

5.4 常见问题速查表

6. 进阶方向：从能用走向好用

6.1 Agent工作流的设计思路

当你把RAG跑通之后，下一步自然是让系统能“做事”而不只是“回答”。这就是Agent的概念。Agent的核心是让LLM能够调用工具：查数据库、发邮件、调API、执行代码。

设计Agent工作流时，最关键的是工具描述要清晰。LLM根据工具的名称和描述来决定调用哪个工具，如果描述模糊，它就会乱调。比如一个“查询天气”的工具，描述要写成“根据城市名称查询当前天气状况，输入参数为城市名，返回温度和天气描述”，而不是简单的“查天气”。

另一个关键是错误处理。Agent调用工具失败时，要能让LLM知道失败了，并决定是重试还是换一种方式。这需要在工具返回值里包含明确的错误信息。

6.2 微调小模型的适用场景

不是所有场景都需要微调。我的判断标准是：如果你的任务用prompt engineering能做到80分，就不要微调。微调的成本包括数据标注、训练资源、部署维护，加起来远超你的预期。

微调真正适用的场景是：任务非常垂直（比如法律文书分类）、对延迟要求极高（不能调API）、或者数据隐私要求不能出本地。这时候微调一个7B参数的小模型，效果可能比GPT-4还好。

6.3 成本控制的五个实用技巧

AI应用的成本大头在API调用。控制成本的手段包括：用更小的模型处理简单任务、缓存常见问题的回答、压缩prompt长度、批量处理请求、设置预算告警。我见过一个团队，光是优化prompt长度这一项，每月就省了40%的API费用。

7. 我踩过的坑与实操心得

第一个坑是过度依赖框架。刚开始用LangChain的时候，觉得什么都能做，结果一个简单的检索问题排查了三天，最后发现是框架内部的一个默认参数导致的。后来我养成了一个习惯：核心逻辑自己写，框架只用来做辅助。

第二个坑是忽略数据质量。我做过一个项目，花了两周调模型参数，效果一直上不去。后来把训练数据拿出来一看，30%的标注是错的。数据清洗花了一天，效果直接提升了20个百分点。这件事让我明白：在AI工程里，数据质量比模型选择重要十倍。

第三个坑是不做评估就上线。我曾经把一个问答系统直接部署给内部同事用，结果第一天就收到一堆投诉。后来补了评估流程，发现检索准确率只有60%。如果上线前跑一遍测试集，这些问题完全可以在内部解决。

最后一个心得是：保持简单。AI领域的新概念层出不穷，但真正能落地的方案往往是最简单的。一个清晰的prompt、一个合理的检索策略、一个稳定的API调用，比一堆花哨的框架组合起来管用得多。我现在的习惯是，每引入一个新工具或新框架之前，先问自己：不用它我能不能做？如果能，就不用。