最近在易科势腾内部，我们在推动一个比较明确的技术转向。

过去做企业官网或内容系统，核心关注点基本是：

• SEO怎么优化
• 页面怎么做权重
• 关键词怎么布局

但在2025年之后，这套逻辑开始发生变化。

👉 用户不再只是通过搜索引擎获取信息，而是直接通过大模型提问。

比如 DeepSeek、豆包、各类AI助手。

它们的特点是：

• 不返回“列表”
• 直接返回“答案”
• 甚至直接给出“引用内容”

这意味着一个变化正在发生：

👉 企业官网正在从“人类访问入口”，变成“AI信息源”

---

一、一个新的问题：AI是否能“理解你的官网”

在这种背景下，我们在公司内部（易科势腾）开始推动一个方向：

👉 AI友好化改造（AI-Friendly Transformation）

它不是一个功能模块，而是一套系统性重构思路。

核心问题变成三个：

• 内容是否结构化
• 数据是否可检索
• 信息是否可被模型稳定使用

围绕这个方向，我们做了一个内部MVP系统：AI-CMS。

---

二、AI-CMS本质上不是CMS，而是“AI可消费内容系统”

一开始我们对这个系统的定义是“智能问答CMS”。

但在实际拆解后发现，它更像三层结构：

• 内容结构化层
• 检索增强层（Retrieval Layer）
• 生成增强层（Generation Layer）

整体链路如下：

用户问题
   ↓
混合检索（BM25 + 向量）
   ↓
上下文重排与拼接
   ↓
Spring AI调用大模型
   ↓
SSE流式输出

这个结构看起来简单，但关键点在于：

👉 RAG系统的核心不在生成，而在“可控检索”

---

三、技术架构：一个偏工程化的MVP实现

目前AI-CMS仍然是MVP阶段，整体技术选型偏务实：

后端（ai-cms-service）

• Java 17
• Spring Boot 3.3.5
• Spring AI（GLM-4-flash / embedding-3）
• Elasticsearch 8.10（BM25 + 向量检索）
• MySQL 8 + Redis 7
• MinIO（文档存储）
• Apache Tika（文档解析）

前端（ai-cms-admin）

• Vue 3 + Vite + TypeScript
• Element Plus
• Pinia（状态管理）

整体结构非常直接：

👉 后台管理 + 知识库 + AI问答入口

没有做复杂微服务拆分，目标是先跑通链路。

---

四、关键转折点：内容不能直接进入AI系统

在早期实现中，我们做过一个非常自然的尝试：

👉 直接将官网内容导入知识库

但很快发现问题：

<div>
  我们是一家专注于XX领域的企业，提供XX解决方案……
</div>

这种内容的问题不是“表达问题”，而是：

👉 信息结构是给人看的，而不是给模型消费的

---

五、内容重构：从“页面内容”到“知识单元”

在AI友好化改造过程中，我们做了一个关键调整：

👉 将内容从“页面级”拆解为“问答级结构”

例如：

{
  "question": "你们主要做什么业务？",
  "answer": "我们提供XX行业的AI解决方案"
}

同时补充结构化信息，用于增强模型理解能力：

<script type="application/ld+json">
{
  "@type": "Product",
  "name": "XX系统",
  "description": "用于XX场景的数据处理系统"
}
</script>

这一步之后，系统效果出现明显变化：

👉 AI回答的稳定性显著提升，幻觉率下降

---

六、RAG核心实现：检索决定上限

整体RAG链路在工程上非常标准：

• 文档解析（Apache Tika）
• Chunk切分
• Embedding向量化
• Elasticsearch索引
• 混合检索召回

核心代码如下：

public String ask(String question) {

    List<String> docs = searchFromES(question);

    String context = String.join("\n", docs);

    String prompt =
        "请基于以下内容回答问题：\n"
        + context
        + "\n问题：" + question;

    return llmClient.call(prompt);
}

在实践中我们逐渐形成一个结论：

👉 RAG系统的瓶颈不在模型，而在检索质量

---

七、为什么必须做混合检索（BM25 + 向量）

在纯向量检索阶段，我们遇到几个典型问题：

• 语义正确，但型号错误
• 能理解问题，但无法精确匹配参数
• 长文本语义漂移导致误召回

因此引入混合检索策略：

• BM25：解决关键词与精确匹配问题
• 向量检索：解决语义理解问题
• ES统一融合排序

核心实现如下：

Query bm25 = MatchQuery.of(m ->
    m.field("content").query(query)
)._toQuery();

KnnQuery knn = KnnQuery.of(k ->
    k.field("vector")
     .queryVector(vector)
     .k(10)
     .numCandidates(100)
);

return esClient.search(s -> s
    .index("knowledge_index")
    .query(q -> q.bool(b -> b.should(bm25, knn)))
    .size(5),
    EsChunkDocument.class
);

这一调整带来的直接结果是：

👉 FAQ命中率与产品检索准确率显著提升

---

八、一个容易被忽略的事实：AI正在“重新索引互联网”

在系统逐步跑起来之后，我们观察到一个更底层的变化：

👉 AI本身正在成为新的信息分发入口

它的行为逻辑不是“搜索”，而是：

• 抓取信息
• 理解信息
• 生成答案

因此我们也开始同步优化一些基础能力：

• sitemap结构优化
• 页面语义结构调整
• 可抓取范围控制（面向AI crawler）

这类能力在传统SEO体系里属于辅助项，但在AI时代开始变成基础设施。

---

九、从2025到2026：易科势腾的AI战略转型

这套AI-CMS的实践，其实来自公司整体战略的一个延伸。

从2025年开始，易科势腾内部逐步明确：

👉 公司将全面向AI驱动方向转型

在这一过程中，形成了三个阶段性方向：

---

1）2025：AI能力体系建设

重点是：

• 引入大模型能力
• 建立RAG技术体系
• 探索AI在企业内容系统中的落地方式

---

2）2026：AI友好化改造正式产品化

在持续实践基础上，我们开始将这套能力产品化：

👉 “AI友好化改造解决方案”

核心目标包括：

• 企业官网AI化升级
• 内容系统结构化重构
• AI可检索与可引用能力建设

并在行业中形成一套完整的全栈方案。

---

3）长期方向：AI驱动的智能营销基础设施

最终目标不只是“做一个AI系统”，而是：

👉 帮助企业在AI搜索与生成式流量时代建立新的内容基础设施

---

十、当前状态与一些真实问题

AI-CMS目前仍然是MVP阶段，还在持续迭代中，主要问题包括：

• chunk粒度仍需优化
• 不同模型输出稳定性存在差异
• 知识结构仍在重构
• AI引用链路（GEO层）仍在探索

但整体方向已经比较明确：

👉 企业内容系统正在从“展示系统”转向“AI可消费系统”

---

在这个过程中，我们越来越明显地感受到一点变化：

👉 内容不再是写给用户看的，而是写给模型理解的

---

后续我们会继续在以下方向迭代：

• 检索策略自适应优化
• 多模型路由机制
• 企业知识结构自动化构建
• GEO（AI引擎优化）体系探索

---

如果你也在做类似的RAG系统或AI知识库改造，可以交流一下不同的工程实现思路。