企业官网建设流程全解析

最近 AI 圈有一个消息引发了不少讨论：林俊旸官宣创业，新公司叫 Pragmatik Labs。比起铺天盖地的融资新闻，我更关注这个命名传递出的信号——Pragmatik，语感上很接近 pragmatic，也就是“务实、实用”。大模型从实验室走向生产环境的当下，这个命名几乎是在明示：这一轮创业要解决的是工程落地问题，而不是再讲一个新概念。

这篇文章不打算追热点八卦，而是借这个契机，系统梳理大模型创业和 AI 应用落地中的技术选型与工程实践。无论你是刚接触大模型开发的初学者，还是已经在业务里踩过坑的后端工程师，都可以从这篇文章里找到一条可复用的路径：环境怎么搭、RAG 链路怎么写、微调该不该做、推理服务怎么上、遇到报错怎么排查。整篇文章会围绕一个可运行的“企业知识库问答系统”展开，代码完整，配置清晰，照着做就能跑通第一版。

1. 背景与核心概念

1.1 林俊旸官宣创业：Pragmatik Labs 释放了什么信号

Pragmatik Labs 的品牌名直接指向“实用主义”。在大模型行业经历了 2023 年的基座模型竞赛、2024 年的应用爆发之后，行业正在进入一个更理性的阶段：大家不再只关心模型的排行榜分数，而是关心模型在真实业务里能不能稳定产出价值。

林俊旸此前长期活跃在大模型研究与工程一线，官宣创业意味着他将以创业者身份继续推动模型能力走向落地。公开信息目前还不算多，但结合“Pragmatik”这个词，我们可以判断几个方向大概率会出现在这类公司的技术规划里：

• 模型推理服务的低成本化与高可用架构；
• 企业知识库、智能客服、内容生成等真实场景的工程化交付；
• 模型评估、数据治理、安全合规等“看不见但决定生死”的底座能力。

对普通开发者而言，这些方向不是某个公司的专属课题，而是整个行业共同面对的技术挑战。与其关注八卦，不如把精力放在“如果我也要做一家这样的公司，技术栈应该怎么搭”这个问题上。

1.2 大模型创业公司的三条技术路线

围绕大模型创业，目前基本可以分成三条路线：

第一条是基座模型层。从零训练一个通用大模型，投入极高，需要大规模算力、顶尖算法团队和海量高质量数据。这条路线通常只有少数头部团队能玩得起，Pragmatik Labs 这种规模的公司大概率不会从零开始训练基座模型。

第二条是模型中间层。做微调、对齐、评估、推理加速、模型网关、数据标注工具等。这类公司不直接面对终端用户，而是服务那些需要调用大模型的企业。它们的价值在于让大模型更好用、更便宜、更可控。

第三条是应用层。直接面向业务场景，把大模型能力封装成客服机器人、写作助手、数据分析工具、代码生成插件等。这条路线门槛相对更低，但竞争激烈，真正的壁垒在于对业务的理解和数据的积累。

对 Pragmatik Labs 来说，比较务实的做法是同时覆盖第二条和第三条路线：通过模型中间件能力建立技术壁垒，再通过应用层产品获取收入和数据反馈。这也是很多大模型创业公司的共同打法。

1.3 为什么“务实”是当前大模型落地的关键词

过去两年，很多团队在“拥抱大模型”时容易走两个极端：一个是迷信模型能力，认为只要接了 GPT 或开源模型，产品就自动变得智能；另一个是过度设计系统，一上来就搭 Agent、上微调、搞十个服务，结果数据还没准备好，链路已经跑不通了。

务实的做法是把大模型当成一个“能力组件”，先问三个问题：

1. 这个需求是否真的需要大模型？还是规则、检索甚至静态配置就能解决？
2. 大模型在这个场景下的错误，用户能不能接受？如果不能，需要用什么机制兜底？
3. 效果、成本、延迟三者如何平衡？企业用户更在意的是稳定和可控，而不是单次效果的惊艳。

因此，RAG（检索增强生成）会成为大多数务实团队的首选方案。它不要求你重训模型，也不需要立刻做复杂的微调，只要把知识库管理好、检索链路做好，就能在大模型能力之上构建出更可信的业务应用。

2. 环境准备与版本选型

2.1 算力环境与模型选择

做 AI 应用开发，第一步是选择算力环境。这里分两种情况：

如果你想调用云端 API，那么开发机不需要独立 GPU，普通的 8 核 16G 云主机就够用。这时候的主要成本是 API 调用费用。

如果你想在本地部署开源模型做推理，建议准备一块显存尽量大的 GPU。以 7B~14B 参数规模的开源模型为例，推理时显存占用通常在 8GB~24GB 之间。如果显存不够，可以优先选择量化版本模型，或者使用 Ollama 这类推理工具来简化部署。

版本方面，我不建议把版本号写死。大模型生态变化极快，LangChain、transformers、vLLM 等组件几乎每个月都有新版本，API 也在不断调整。本文会使用目前比较常见的插件化写法，重点演示配置思路，你落地时要根据实际版本对照官方文档微调。

2.2 技术栈清单

2.3 示例项目结构

为了后续实战案例清晰，我们先约定一个项目结构。你可以直接复制到本地：

knowledge-base/ ├── data/ │ └── faq.txt ├── src/ │ ├── ingest.py │ └── query.py ├── config.py └── requirements.txt

• data/faq.txt：待检索的知识文档，用最简单的文本格式演示；
• src/ingest.py：负责读取文档、切片、生成向量、写入向量库；
• src/query.py：负责加载向量库，构建问答链路；
• config.py：集中管理模型名、API 地址、向量库路径等配置；
• requirements.txt：声明依赖。

这个结构虽然简单，但已经是很多企业项目的最小时原型。等链路跑通后，再把文档解析换成企业内部的 Wiki、数据库或对象存储即可。

3. 核心架构拆解：如何搭建 LLM 应用底座

3.1 RAG：最稳妥的落地路径

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。它的核心思想是：不要把所有希望寄托在模型“记住”知识上，而是先从一个外部知识库中检索出与问题相关的文档片段，再把片段和问题一起交给模型生成答案。

RAG 的优势非常明显：

• 知识更新成本低。企业制度、产品文档变化时，只需要更新索引，不需要重新训练模型。
• 减少幻觉。模型生成的答案基于检索到的资料，而不是凭空想象。
• 可追溯。每条回答都能找到对应的来源文档，这对企业场景非常重要。
• 隐私可控。敏感数据可以留在私有知识库和私有化部署环境中。

RAG 链路的核心环节包括：

1. 文档加载：从 PDF、Word、数据库、网页等来源读取文本。
2. 文本切分：把长文本按固定长度或语义边界切成小块，避免超过模型上下文限制。
3. 向量化：将每个文本块通过嵌入模型转换成向量。
4. 向量存储：把向量写入向量数据库，并保存原始文本。
5. 检索：根据用户问题向量，找到最相似的文本块。
6. 生成：把检索到的文本块拼入 Prompt，调用大模型生成最终答案。

下面这篇文章的实战案例，就是围绕这条链路展开的。

3.2 微调与训练的边界

很多团队一上来就问“我们要不要微调模型”，我的建议通常是“先别”。微调适合三种场景：

• 需要学习特定格式或风格，比如让模型输出固定 JSON 结构；
• 需要补充模型不知道的专业概念，比如公司内部术语；
• 需要降低推理成本，比如用小模型压缩大模型能力。

对于大多数知识类问答场景，RAG 已经足够。微调不仅需要准备高质量标注数据，还要考虑训练和部署成本。即使真的要微调，也建议优先选择 LoRA、QLoRA 这类参数高效微调方法，而不是全量微调。

在工程上，更加务实的路线是先用 RAG 把产品跑通，积累足够的用户反馈和 badcase，再判断是否需要微调。这样可以避免在需求不明确的情况下浪费训练资源。

3.3 推理服务与性能优化

当应用从原型走向生产，模型的推理性能会成为核心瓶颈。这里有几个常用的优化手段：

• KV Cache：推理时缓存历史 token 的键值，减少重复计算，是所有主流推理框架默认开启的能力。
• 量化：把模型从 FP16 转成 INT8 或 INT4，可以显著降低显存占用和推理延迟，但会带来少量精度损失。
• 动态批处理：把多个请求合并成一批处理，提高 GPU 利用率。
• 流式输出：首 token 尽快返回，再边生成边返回，提升用户体验。

本地部署时，我比较推荐 Ollama 或 vLLM。Ollama 安装简单，适合开发和测试；vLLM 吞吐量更高，适合生产环境。

以 Ollama 为例，部署一个 7B 级别模型的命令很简单：

# 拉取模型，具体模型名以 Ollama 官方模型库为准 ollama pull qwen2.5:7b # 启动服务 ollama serve

启动后，Ollama 会提供一个兼容 OpenAI 的接口：http://localhost:11434/v1。这意味着你不需要改业务代码，只需要把 API 地址和模型名切换一下，就能从云端模型平滑切换到本地模型。

4. 实战案例：从零搭建企业知识库问答系统

下面我们完整实现一个企业知识库问答系统。这个系统不依赖高配置机器，只要 Python 环境和一个可用的模型 API 就能跑通。

4.1 创建项目结构

先创建项目目录：

mkdir -p knowledge-base/data knowledge-base/src cd knowledge-base

4.2 安装依赖

创建requirements.txt，内容如下：

langchain langchain-openai langchain-community faiss-cpu pypdf

执行安装：

pip install -r requirements.txt

需要说明的是，LangChain 在 0.1 版本之后将不同模块拆分到了独立的子包中。如果你安装的是比较新的版本，langchain-openai和langchain-community就是必需的。如果版本较旧，导入路径可能会有差异，请以官方文档为准。

4.3 准备语料

在data/faq.txt中写入一些示例知识内容，这里模拟一个公司内部的常见问题文档：

公司实行混合办公制度，员工每周可选择三天到办公室办公，两天远程办公。 远程办公期间需要通过公司统一的办公协同平台完成打卡和任务协作。 年假申请需要提前三天在行政系统提交，审批通过后生效。 报销流程：发票开具后，在财务系统填写报销单，并上传电子发票。 办公设备申请统一通过 IT 服务台提交工单，紧急情况可以联系值班电话。 绩效评估每半年进行一次，评估结果直接影响年度奖金发放。

实际项目中，这个文件可能是几百页的 PDF，也可能是数据库里的几百张表。这里的核心代码逻辑是一样的：读入、切分、向量化、入库。

4.4 编写配置文件

创建config.py，集中管理模型和路径配置：

# 文件路径：config.py # 模型与向量库配置 # 如果你使用云端 OpenAI 兼容接口，填对应地址和 Key # 如果你使用本地 Ollama，base_url 填 http://localhost:11434/v1 EMBEDDING_MODEL = "text-embedding-3-small" LLM_MODEL = "gpt-4o-mini" API_KEY = "your-api-key" BASE_URL = "https://api.openai.com/v1" # 向量库路径 VECTOR_DB_PATH = "./faiss_index" # 文本切分参数 CHUNK_SIZE = 300 CHUNK_OVERLAP = 50

这里的EMBEDDING_MODEL是嵌入模型，用来把文本转换成向量；LLM_MODEL是生成模型，负责组织最终答案。如果你的公司使用的是国内云厂商的 OpenAI 兼容接口，只需要把BASE_URL和模型名替换成对应值即可。

4.5 编写索引构建脚本

创建src/ingest.py：

# 文件路径：src/ingest.py from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS from config import API_KEY, BASE_URL, EMBEDDING_MODEL, VECTOR_DB_PATH, CHUNK_SIZE, CHUNK_OVERLAP def build_index(): # 1. 加载文档 loader = TextLoader("./data/faq.txt", encoding="utf-8") docs = loader.load() # 2. 切分文档 splitter = RecursiveCharacterTextSplitter( chunk_size=CHUNK_SIZE, chunk_overlap=CHUNK_OVERLAP ) chunks = splitter.split_documents(docs) # 3. 初始化嵌入模型 embeddings = OpenAIEmbeddings( model=EMBEDDING_MODEL, api_key=API_KEY, base_url=BASE_URL ) # 4. 构建向量库 vectorstore = FAISS.from_documents(chunks, embeddings) vectorstore.save_local(VECTOR_DB_PATH) print(f"索引构建完成，共 {len(chunks)} 个文本块") if __name__ == "__main__": build_index()

这段代码做的事情很直观：

• 读取faq.txt全文；
• 按 300 字符长度、50 字符重叠切分，保证相邻文本块之间语义连贯；
• 调用嵌入模型生成向量；
• 写入 FAISS 向量库并保存到本地。

切分重叠的意义容易被忽略。如果两个句子恰好被切到两个块里，重叠部分可以让边界处的语义不会完全断裂，检索时匹配率更高。

4.6 编写问答服务脚本

创建src/query.py：

# 文件路径：src/query.py from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain.chains import RetrievalQA from config import API_KEY, BASE_URL, EMBEDDING_MODEL, LLM_MODEL, VECTOR_DB_PATH def create_qa_chain(): # 1. 加载嵌入模型 embeddings = OpenAIEmbeddings( model=EMBEDDING_MODEL, api_key=API_KEY, base_url=BASE_URL ) # 2. 从本地加载向量库 # 注意：allow_dangerous_deserialization 只适用于本地可信文件 vectorstore = FAISS.load_local( VECTOR_DB_PATH, embeddings, allow_dangerous_deserialization=True ) # 3. 构建检索器，取最相似的 3 个文本块 retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) # 4. 初始化大模型 llm = ChatOpenAI( model=LLM_MODEL, api_key=API_KEY, base_url=BASE_URL, temperature=0.2 ) # 5. 组装问答链路 qa = RetrievalQA.from_chain_type( llm=llm, retriever=retriever, return_source_documents=True ) return qa if __name__ == "__main__": qa = create_qa_chain() question = "年假申请需要提前几天？" result = qa.invoke({"query": question}) print("问题：", question) print("回答：", result["result"]) print("\n来源文档：") for doc in result["source_documents"]: print(f"- {doc.metadata.get('source', 'unknown')}: {doc.page_content[:50]}...")

这里有一个安全细节：allow_dangerous_deserialization=True是 LangChain 在加载本地 FAISS 索引时要求显式确认的参数。因为向量库文件可能包含序列化对象，如果文件来源不可信，存在潜在安全风险。在生产环境，请确保索引文件由自己构建，并且存放在可信的存储系统中。

4.7 运行与验证

先执行索引构建：

python src/ingest.py

预期输出：

索引构建完成，共 7 个文本块

然后运行问答：

python src/query.py

预期输出效果类似：

问题： 年假申请需要提前几天？ 回答： 根据公司规定，年假申请需要提前三天在行政系统提交，审批通过后生效。 来源文档： - data/faq.txt: 年假申请需要提前三天在行政系统提交，审批通过后生效。...

到这里，一个最小可运行的知识库问答系统就完成了。你可以继续扩展以下内容：

• 增加 PDF、Word 文档解析；
• 把 FAQ 文本换成数据库内容；
• 增加对话历史，让模型支持多轮追问；
• 将检索结果和答案同时展示到前端页面。

5. 常见问题与排查思路

在实际运行过程中，最容易遇到下面这些问题。我整理了一张排查表：

5.1 检索不到相关内容时怎么排查

如果模型回答“我不知道”，但知识库里明明有对应信息，按下面的顺序排查：

1. 打印检索到的文本块，确认是否真的检索到了相关内容；
2. 调整chunk_size，让文本块更小、更聚焦；
3. 调大k值，让检索器返回更多候选；
4. 检查问题表述是否和文档内容差别过大，必要时改写问题；
5. 更换更好的嵌入模型。

5.2 回答出现幻觉时怎么处理

幻觉是大模型应用的固有风险，无法完全消除，只能通过工程手段压制：

• 在 Prompt 中明确要求“只能基于提供的资料回答，资料中没有的信息请回答不知道”；
• 使用RetrievalQA时，把return_source_documents打开，便于追溯；
• 增加答案校验逻辑，如果检索结果与问题的相似度低于阈值，直接返回兜底文案；
• 定期收集 badcase，建立评测集，持续优化检索链路。

6. 最佳实践与工程建议

6.1 以评测驱动迭代

没有评测的 AI 应用迭代就是“盲人摸象”。建议从第一天就建立评测集，哪怕只有 50 条测试问题也比没有强。每条问题标注标准答案和期望来源文档，每次改动索引、提示词、模型后，都跑一遍评测集，统计正确率。

有了评测集，你就能把微调和检索优化的收益量化。比如，调整chunk_size后正确率从 70% 提升到 78%，这个结论可以在周报里一目了然。

6.2 不要一开始就追求复杂的 Agent 架构

Agent 是当前热点，但它不等于产品能力。很多场景下，简单流程编排已经足够。如果业务确实需要 Agent，建议先把单工具调用跑通，再逐步增加工具数量。Agent 的核心风险在于不可控，工具越多，越容易出现长时间无效循环或错误调用。

在工程上，更稳妥的做法是“流程为王、Agent 为辅”：能写死流程的场景就用代码控制，只有真正需要动态决策的部分才交给模型。

6.3 成本与延迟控制

大模型应用的成本不是固定不变的，和三个因素强相关：

• 输入 token 数量。Prompt 越长，成本越高；
• 检索到的文本块大小。返回的上下文越多，生成成本越高；
• 模型规格。越大越贵，但小模型不一定效果差。

建议在 LangChain 中对输入内容做截断和精简，只保留与问题最相关的部分。还可以通过缓存机制复用相似问题的回答，降低调用频率。

6.4 数据安全与合规意识

在开发阶段就要思考数据边界：哪些知识可以进向量库？哪些数据不允许发送到第三方模型？如果涉及敏感信息，优先选择私有化部署方案，把向量库和模型都放到内网环境。

日志中不要记录完整的用户问句和模型输出，尤其是涉及个人信息的内容。生产环境需要具备权限管控、审计能力和数据删除能力，这些都是企业采购时非常看重的部分。

6.5 从 0 到 1 的启动顺序

如果你今年打算做某个大模型应用，我的建议是：

1. 先找 100 条真实业务问题；
2. 手动整理答案，形成基线数据；
3. 用 RAG 搭建第一版系统，跑通链路；
4. 建立评测集，评估正确率；
5. 针对失败案例优化切片、检索和 Prompt；
6. 效果稳定后，再做部署、监控和权限体系；
7. 只有当 RAG 无法满足需求时，再考虑微调。

这个顺序可以最大限度减少无效投入，让你把每一分算力和人工花在刀刃上。

7. 总结与学习路线

这篇内容从林俊旸官宣创业公司 Pragmatik Labs 这个热点切入，落回到一个更实际的问题：大模型项目到底怎么落地？围绕这个问题，我们梳理了大模型创业的三条技术路线，搭建了一套基于 RAG 的企业知识库问答系统，完整覆盖了文档加载、文本切分、向量化、检索、生成、运行验证的整个流程，同时整理了常见报错、幻觉问题、成本控制和数据安全等工程层面的注意事项。

如果你能亲手把上面的项目跑通，你已经掌握了大多数企业级大模型应用的最小必备技能。下一步可以往两个方向深入：

• 一是往“训”的方向走，学习 LoRA 微调，理解 SFT、RLHF 的基本流程；
• 二是往“工程”的方向走，研究 vLLM 推理部署、Agent 任务编排、流式输出、模型网关等更高阶的主题。

最后留一个建议：不要等到所有技术都学会了再动手。找一份你熟悉的业务文档，先把 RAG 链路跑起来，再慢慢优化。Pragmatik 这个词的核心，就是把事情做扎实，而不是一开始就追求宏大叙事。