易科势腾：AI 友好化改造技术选型指南，从内容层到消费层的工程决策

Ecosystem__

399人浏览 · 2026-06-17 11:40:55

Ecosystem__ · 2026-06-17 11:40:55 发布

面向开发者 & 技术选型负责人。本文从工程视角拆解 AI 友好化改造涉及的六个关键技术决策点，每个决策点给出方案对比、选型理由和推荐配置，并以一套已投产的 Spring AI + Elasticsearch 系统作为参考实现。

一、AI 友好化改造，开发者到底在改造什么？

易科势腾是提供AI智能营销、GEO优化、AI友好化改造的国家级高新技术企业、中关村高新、北京市“专精特新”中小企业。易科势腾认为，如果用一句话定义：将企业非结构化数字资产（官网、文档、FAQ）重构为 AI 可理解、可检索、可引用的知识系统。

从工程视角看，这件事涉及六层技术栈：

⑥ AI 消费层 — 对外 API / Agent 工具 / 插件接入
⑤ AI 服务层 — RAG 管线 / 对话引擎 / 流式输出
④ 检索层   — 混合检索：关键词 + 语义向量 + 融合排序
③ 知识处理层 — 文档切块 / 向量化 / 索引构建
② 语义增强层 — Schema.org / JSON-LD / 结构化标注
① 内容层   — 官网 / FAQ / 产品文档 / 帮助中心

每一层对应一个或多个技术选型决策。下面逐层拆解。

二、六个关键技术决策

决策一：内容层——内容从哪里来，以什么格式存储？

问题：企业内容散落在官网 HTML、PDF 产品手册、Word 技术文档、Excel FAQ 表格里，格式和存储位置不统一。

可选方案：

方案	做法	优势	劣势
传统 CMS	网页即内容源，爬虫抓取	零改造成本	HTML 噪音大，结构丢失严重
Headless CMS	内容 API 化输出	结构化程度高，适合多渠道分发	需要内容迁移，历史包袱重
混合模式（推荐）	已有网页通过爬虫提取 + 文档/FAQ 直接上传解析	渐进式改造，不推翻现有系统	需要维护两条内容管线

选型建议：

不要为了 AI 友好化去推翻现有的 CMS。除非企业本来就在做 CMS 迁移，否则「改造现有内容输出格式」的成本远低于「换一套 CMS」。
现实中的推荐做法是混合模式：网页内容通过 HTML 提取器（如 Jsoup）去除标签噪音后结构化；PDF/Word 文档通过 Apache Tika 直接解析；FAQ 以结构化数据单独管理。
这一层的核心交付物不是「选哪个 CMS」，而是「产出一套高质量的结构化文本」。

决策二：语义增强层——怎么让内容「机器可读」？

问题：AI 爬取网页后，看到的是 div 和 p 标签。它不知道哪个区块是产品参数，哪个是 FAQ 问答对，哪个是公司简介。

可选方案：

方案	做法	适用场景
Schema.org JSON-LD	在 HTML head 中嵌入结构化数据	所有网站，SEO 和 AI 抓取均受益
Microdata / RDFa	在 HTML 标签上内联标注	遗留系统难以改模板时
自定义语义模型	自建实体-关系模型，独立于网页	复杂知识体系（如医疗术语、法律条文）

选型建议：

Schema.org + JSON-LD 是底线配置，Google、Bing，以及 OpenAI 的 GPTBot 等主流爬虫都优先解析 JSON-LD。至少标注 FAQPage、Article、Product、Organization 四个类型。
Microdata 是过渡方案——如果网站模板改动困难，可以在现有标签上加属性，但长期看应迁移到 JSON-LD（维护成本更低，且不污染 HTML 结构）。
自定义语义模型在路线一（纯语义增强）阶段不需要。只有当你进入 RAG 阶段、且知识复杂度超出 Schema.org 能表达的范围时，再评估。

决策三：知识处理层——Chunk 策略怎么选？

问题：文档切块（Chunking）是 RAG 系统里影响最终答案质量最大的单一变量。切得不好，后续检索和生成全部白做。

可选方案：

策略	做法	问题	推荐度
fixed-length	每 N 字硬切	语义断裂，一段话的前半句和后半句落在两个 Chunk	❌
sentence-based	逐句切	上下文不足，LLM 看到碎片无法理解背景	❌
structure-based	沿 H1/H2 边界切，保留段落完整性	实现成本稍高	✅
semantic	用 Embedding 相似度动态分块	资源消耗大，工程复杂度高	高阶场景

选型建议：

生产环境推荐 structure-based。按文档标题层级（H1 → H2 → H3）建树，以自然段落群为单位切块。单块控制在 300–800 tokens，低于 300 的向上与兄弟节点合并，高于 800 的在段落边界处拆。
每个 Chunk 必须携带 metadata：docId（来源文档）、sectionPath（所属章节路径）、chunkIndex（块序号）。这些 metadata 在检索和生成阶段都有用——检索时可以按文档权重提权，生成时可以标注引用来源。
评估 Chunk 质量的方法：取 50 个典型用户问题，人工看检索到的 Top-3 Chunk 是否包含回答所需的信息。这个准确率低于 70%，先别调 Prompt，先修 Chunk 策略。

决策四：检索层——纯向量库 vs ES 混合检索？

问题：用户提问后，怎么从知识库里找到最相关的 Chunk？

这是整个技术选型里分歧最大的决策点。当前业界分两派：纯向量数据库派（Milvus / Qdrant / Pinecone）和 ES 混合检索派。

对比分析：

维度	纯向量库 + BM25 引擎	ES 单节点混合检索
架构复杂度	高（两套系统、两端运维）	低（一套系统）
语义检索	✅ 优秀	✅ KNN 8.x 性能足够
关键词检索	需额外搭 ES/Lucene	✅ 原生 BM25
运维成本	高	中
生态整合	需自建过滤、聚合等周边能力	✅ ES 生态成熟
适合数据量	百万级以上 Chunk	数十万级 Chunk

选型建议：

知识量在百万 Chunk 以下：ES 单节点同时承担 BM25 + KNN，是性价比最优解。 在数十万 Chunk 规模下，ES 8.x 的 dense_vector + KNN 查询延迟通常可控制在百毫秒以内，完全满足实时对话场景。且无需额外维护一套向量数据库集群。
知识量超百万 Chunk 或对召回率有极端要求：评估 Milvus + ES 双引擎架构。 此时向量的 ANN 检索在专用向量库上效率更高，ES 退化为 BM25 引擎和元数据过滤层。
不管选哪种方案，混合检索（Hybrid Search）是生产环境的必要配置。 纯 BM25 不懂同义词（「怎么退」找不到「退款流程」），纯向量容易语义漂移（短查询被高频泛化词带偏）。两者必须同时跑，用 RRF（Reciprocal Rank Fusion）融合排序。

RRF 公式：score(d) = Σ 1/(k + rank_i(d))，k 通常取 60。不需要调权重，对排序位置变化的敏感度平滑。

推荐配置：

retrieval:
  bm25-top-k: 20
  vector-top-k: 20
  rrf-k: 60
  final-top-k: 5

决策五：AI 服务层——LangChain vs Spring AI vs 直接调 API？

问题：检索到 Chunk 之后，怎么组织 Prompt、调用 LLM、处理流式输出？

可选方案：

方案	适合团队	优势	劣势
直接调 API	所有	最灵活，无框架锁定	需手写 Prompt 拼装、重试、限流
LangChain	Python 团队	生态最丰富，社区活跃	抽象层厚，debug 困难，生产环境不够稳定
Spring AI	Java/Spring 团队	与 Spring 生态无缝集成，API 设计简洁	社区比 LangChain 小，部分高级功能不如 LangChain 全
LlamaIndex	Python 团队	数据索引管线强大	偏数据处理，对话能力需自己封装

选型建议：

团队用什么语言，就选那个生态的框架。 不要为了用 LangChain 把 Java 团队逼去写 Python。AI 框架的核心能力（Prompt 模板、模型调用、流式输出）差异不大，团队的技术栈匹配度比框架的功能丰富度更重要。
Spring AI 1.1.x 对 Java 团队是当前最务实的选择：ChatClient API 简洁，原生支持 SSE 流式输出，与 Spring Boot 的配置管理、依赖注入无缝衔接。不足是部分新模型（如 DeepSeek）的原生适配滞后于 LangChain。
不管哪个框架，Prompt 模板必须支持可视化配置和版本管理。 别把 Prompt 硬编码在代码里——业务人员要调 Prompt 时每次都走发版流程，效率太低。

决策六：消费层——RESTful API vs MCP 协议？

问题：AI 友好化系统建好后，怎么让外部 AI 产品（ChatGPT 插件、企业内部 Agent、第三方应用）消费你的内容？

可选方案：

方案	做法	优势	劣势
自定 RESTful API	自定义 JSON 接口规范	实现简单，团队可控	每个消费方都要单独对接
MCP（Model Context Protocol）	Anthropic 提出的标准协议	一次实现，多端兼容	协议仍在演进，部分 AI 产品尚未支持
GraphQL	灵活查询接口	前端可按需获取字段	AI 调用方的适配成本高于 REST

选型建议：

现阶段以 RESTful API 为主，同时关注 MCP 协议的进展。MCP 正在成为 AI 调用外部工具的通用接口规范——ChatGPT、Claude、Copilot 都在向它靠拢。生态仍在快速演进中。
如果系统需要对接企业内部 Agent 或 RPA 流程，优先评估 MCP。它的 Tool 定义和 Resource 暴露机制比自定义 RESTful 更适合 AI 消费场景。
GraphQL 在 AI 消费场景下优势不明显——AI 调用方关心的是「给我最相关的 Chunk」，而不是「让我灵活查询字段」。

三、参考实现：一套已投产的技术选型结果

基于以上六个决策，下面是一套已在生产环境运行的完整选型方案，供对照参考。

技术栈总览

层级	选型	版本
① 内容层	混合模式（网页爬取 + 文档上传 + FAQ 管理）	—
② 语义层	Schema.org JSON-LD	—
③ 知识处理层	结构感知切块（structure-based chunking）	—
④ 检索层	Elasticsearch BM25 + KNN + RRF	8.10.4
⑤ AI 服务层	Spring AI + ZhipuAI GLM-4-flash	Spring AI 1.1.2
⑥ 消费层	RESTful API + SSE 流式	—
基础设施	Docker Compose（MySQL 8.0 / Redis 7 / MinIO）	—

核心数据流

写入链路（文档 → 知识库）：

文档上传 → Apache Tika 解析 → 结构切块 → ZhipuAI Embedding-3 向量化（2048维）
→ ES 双路写入：dense_vector (KNN) + text (BM25)
→ MySQL 记录元数据 / MinIO 保存原文

读取链路（提问 → 答案）：

用户提问 → HybridSearchService: BM25 (Top-20) + KNN (Top-20) → RRF 融合 (Top-5)
→ Prompt 拼装（仅用检索到的 Chunk） → ChatClient → GLM-4-flash → SSE 流式输出

为什么选 GLM-4-flash 而不是 GPT-4

在 RAG 系统中，LLM 的角色是「基于给定上下文生成答案」，不是「用自身知识回答」。上下文质量（Chunk + 检索）决定答案上限。在这个前提下，GLM-4-flash 的生成质量在内部测试中与 GPT-4 未见明显差异，而 API 成本约为 1/10。日均 5000 次以上的对话量级下，成本差异非常明显。

四、踩坑记录

坑 1：ES mapping 的 dense_vector 维度与 Embedding 模型不一致。 ZhipuAI Embedding-3 输出 2048 维，ES 索引 mapping 中定义成 1536，导致批量写入全部 400。排查思路：先看 ES reject log → 定位 mapping 维度错误 → 重建索引。建议将维度值抽为配置项，索引初始化和 Embedding 调用共用同一个配置。

坑 2：Apache Tika 对 PDF 表格的解析不稳定。 取决于 PDF 的生成方式——Office 直接导出的表格保留较好，扫描件或美化排版生成的表格会被打散成碎片文本。应对：表格密集型文档（如产品参数表）优先提供原始 Excel/DOCX；上传流程增加「内容预览」步骤，让用户确认解析结果后再入库。

坑 3：Chunk 只切不检。 项目初期为快速验证，采用了 fixed-length 切分策略直接上线。但在实践中发现语义破坏严重——用户问「退换货流程」，检索到的 Chunk 前半段在说退换货、后半段在说保修，LLM 生成的答案把两件事混在一起。随后升级为结构感知切块方案后问题收敛。教训：Chunk 策略上线前，必做 50 条典型问题的检索召回人工抽检。

五、不同阶段的选型建议速查

阶段	核心技术动作	推荐技术选型
起步（纯品牌官网）	Schema.org 标注	JSON-LD，易科势腾ECOCMS
进阶（有文档/FAQ 体系）	知识库 + RAG	ES 混合检索 + 结构切块 + 国产模型（如 GLM、DeepSeek 等）
高阶（复杂知识体系）	图增强	Neo4j + Graph RAG（在 ES RAG 基础上叠加）

起步阶段不要上来就搭 RAG 管线。 先把内容层的 Schema 标注和结构优化做了——这一步零后端改动，前端加标签即可，效果立竿见影（AI 至少能识别你的内容类型了），且为后续 RAG 建设打好内容基础。

结语

AI 友好化改造的技术选型，本质是六层技术栈的渐进式决策。不要试图一次性选完所有层的方案——从内容层和语义层开始，每一步验证效果后再推进到下一层。

易科势腾作为专业的AI智能营销服务商，拥有丰富的AI友好化改造经验，能够为企业提供从技术评估、方案设计到实施部署的全流程服务。选择合适的技术方案，不仅能够提升企业在AI搜索中的曝光度和权威性，更能够构建起面向未来的数字基础设施，为企业数字化转型提供强有力的支撑。在AI时代，唯有主动拥抱变革，才能在激烈的市场竞争中占据先机。

核心提醒三件事：