企业官网建设流程全解析

授权与合规声明
本文为技术实操分享，全部示例均运行于作者自建的隔离环境；文中涉及的第三方服务均使用其官方公开接口与公开文档。内容仅代表个人实践经验，不构成任何商业或法律建议；涉及平台规则以官方最新发布为准。

1. 为什么数据少也该先把 RAG 跑起来

很多想入行 AI 应用开发的同事，卡在第一步就放弃了：手里只有几篇产品文档，甚至一份正经资料都没有，就觉得「没数据还玩什么知识库」。

这个判断其实把目标设高了。RAG（检索增强生成）的价值不在于一开始就有海量语料，而在于「让模型回答时先去翻你给的资料，而不是凭记忆编」。哪怕只有 5 篇文档，只要检索链路能正确把相关内容捞出来、喂给大模型，回答质量就已经比裸模型稳很多。

冷启动阶段真正要验证的只有一件事：你的 retrieval 到底 work 不 work。数据少不是不做 RAG 的理由，而是先把最小闭环跑通，再用真实问答反向补数据。

2. 先厘清：冷启动阶段的 RAG 到底是什么

RAG 的标准定义是「检索增强生成」（Retrieval-Augmented Generation，Lewis 等人在 2020 年提出，详见附表 A）。但在冷启动语境下，我更愿意把它拆成一条极简链路：

用户提问 → 把问题向量化 → 去向量库里捞最相关的几块文本 → 连同问题一起喂给大模型 → 大模型基于这些文本作答

注意这里有两处「智能」：一处是向量检索（能不能捞对），一处是生成（能不能基于捞到的内容说人话）。冷启动时最容易出问题的是第一处——捞不对，后面生成再强也是胡说。

所以本文的重心放在「先把检索这条线跑通」，而不是追求生成多惊艳。这也是「先有再优」的核心：先让系统能端到端回答，再逐步把数据、切块、评估做厚。

3. 最小可运行流程：七步走通第一个 RAG

把冷启动拆成七步，每一步都可以单独验证，不必等全部齐活：

1. 文档收集：产品手册、FAQ、内部 wiki、聊天记录导出，能拿到什么算什么。
2. 清洗：去空行、去页眉页脚、统一编码，去掉和问答无关的导航噪声。
3. 切块（chunk）：把长文档切成检索单元（第 4 章细说）。
4. 向量化：用 embedding 模型把每块文本转成向量。
5. 检索：用户提问时向量化问题，从向量库取 top_k 最相似的块。
6. 问答：把命中的块拼进 prompt，交给对话模型生成答案。
7. 评估：用一小批真实问题看检索命中率和回答可用性。

下面用开源向量库 Chroma 给出一个最小可运行的骨架。它能在没有真实 embedding 服务时先用占位逻辑跑通流程，你把自己的接口换进去即可。

⚠️代码待验证

importchromadb# 1) 准备文档（冷启动阶段可能只有几篇）docs=["产品退货需在签收后 7 天内发起申请。","企业版支持 SSO 单点登录，需联系管理员开通。",]# 2) 切块（简化：此处每篇当 1 块，真实场景见第 4 章）chunks=[dfordindocs]# 3) 建库并写入（使用默认 embedding，也可替换为你自己的接口）client=chromadb.Client()col=client.create_collection("kb_demo")col.add(documents=chunks,ids=[f"doc_{i}"foriinrange(len(chunks))],)# 4) 检索 + 拼接（问答阶段把 top_k 结果喂给大模型）hits=col.query(query_texts=["怎么退货？"],n_results=2)print(hits["documents"])

跑通这一步，你就已经拥有了一个「能检索」的 RAG。哪怕数据只有两行，它也能在提问「怎么退货」时把对应那块捞出来——这比想象中更有用，因为它证明了链路是通的。

这份资料是什么：把本文的七步流程拆成可复制的工程模板，含切块与检索的可运行样例。放在资料包里，扫码即可获取：

4. 切块策略怎么选：一张对比表说清

切块（chunking）是冷启动最容易踩坑的环节。块太大，检索粒度粗，一问捞一大片噪音；块太小，语义被切碎，单块又答不全。下面这张表对比常见策略：

冷启动建议从「递归字符分割」起步，配合固定长度兜底。下面是一个带重叠的固定切块函数，避免边界处把一句话劈成两半：

⚠️代码待验证

deffixed_chunk(text:str,chunk_size:int=300,overlap:int=50)->list[str]:"""固定长度切块，带重叠避免截断语义。"""chunks,start=[],0whilestart<len(text):chunks.append(text[start:start+chunk_size])start+=chunk_size-overlapreturnchunks

经验值：中文场景 chunk_size 取 200–500 字、overlap 取 10%–20% 通常能平衡粒度与连贯。具体数值靠第 7 步评估反推，不必一次定死。

5. 数据极少时的补数策略

当文档真的少到可怜，甚至有「零文档」的极端情况，可以用下面几条策略把冷启动语料先垫起来。注意：补数是为了让检索链路尽快有东西可验，不是伪造权威知识。

其中「合成问答」是冷启动扩样本最实用的手段：拿你仅有的几篇源文档，让 LLM 基于它们生成若干组问答对，再把这些问答对作为检索语料或评估集。下面给出调用示例（接口为伪代码，替换成你自己的即可）：

⚠️代码待验证

importrequests,jsondefsynth_qa(source_doc:str,api_url:str,api_key:str)->list[dict]:"""用小样本源文档，让 LLM 生成合成问答对来扩充冷启动语料。"""prompt=f"基于下面文档，生成 3 组问答对，只输出 JSON：\n{source_doc}"resp=requests.post(api_url,headers={"Authorization":f"Bearer{api_key}"},json={"model":"your-model","messages":[{"role":"user","content":prompt}]},)returnjson.loads(resp.json()["choices"][0]["message"]["content"])

除了补数据，冷启动还应准备规则兜底：当向量检索置信度低、或命中的块太少时，直接走关键词规则返回固定答案，避免模型在没资料时硬编。一个最简兜底配置：

⚠️代码待验证

{"fallback_rules":[{"match":["退货","退款"],"answer":"退货需在签收后 7 天内发起，详见帮助中心。"},{"match":["登录","密码"],"answer":"可点击登录页「忘记密码」自助重置。"}]}

补数 + 兜底的组合，能让你的第一个 RAG 在「数据少」阶段也给出体面、可控的回答。

6. 冷启动路线图与决策表

把前面的内容收敛成一张决策表：根据你当前的数据量，直接对号入座行动。

路线图一句话总结：先让系统能答 → 再让检索捞对 → 最后才谈规模与精致。冷启动最忌在「数据不够」上纠结太久，而不去验证链路本身。

这份资料是什么：冷启动路线图与决策表的完整清单，按数据量分情况给出可直接套用的行动项。放在资料包里，扫码即可获取：

7. 小结：先有再优，用小样本验证 retrieval

回到开头那个误区——「没数据就别做 RAG」。事实恰恰相反：数据越少，越该尽早把最小 RAG 跑起来，因为你要验证的是检索链路本身，而不是语料厚度。

回顾七步：收集 → 清洗 → 切块 → 向量化 → 检索 → 问答 → 评估。冷启动阶段不求每块都完美，只要「提问能捞到对的块」这条主线通了，就有了一个可迭代的基座。数据少时用产品手册、FAQ、合成问答把样本垫起来，再配一层规则兜底，第一个能用的 RAG 就立住了。

截至 2026-10-26，主流开源向量库（Chroma、FAISS、Qdrant 等）与公开 embedding 接口都已成熟，搭第一个 demo 的成本很低。别等数据齐了再开始——先有再优，比完美更重要。

附表 A：本文引用事实与出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，我自己在搭第一个知识库时也卡在「没数据」这一步，于是把踩过的坑和能直接套的模板整理了出来，顺手也整理了几份配套的东西：

• 全套 AGI 大模型学习路线：从 0 到能上手 RAG 的路线与关键节点
• RAG 实战工程模板：本文七步流程的可运行脚手架与切块样例
• 冷启动补数清单：产品手册 / FAQ / 合成问答的采集与整理清单

资料是我自己整理的，放在下面这个码上，扫码即可获取：

资料较多，建议先看「全套 AGI 大模型学习路线」，再挑一个实战项目跟练。