项目背景

1. 现状与挑战

葡萄城作为企业级开发工具与解决方案提供商，已建立了完善的知识服务体系，包括：

• 标准化文档：产品帮助文档、API 文档
• 社区资源：GCDN 技术社区（含求助中心、专题教程、技术杂谈等子板块）
• 搜索平台：现有"葡萄城搜索中心"支持跨平台（官网、博客、社区、视频等）内容检索

虽然现有系统支持模糊搜索和精确搜索，但关键字查询的精准度不足，导致了用户体验欠佳。具体表现在以下典型场景：

• 产品学习：用户难以精准定位帮助文档中的功能说明
• 方案搜寻：用户无法高效找到与自身问题匹配的解决方案
• 问题查重：技术支持人员难以快速确认问题是否已有解决方案

2. 技术探索

随着人工智能技术，尤其是大语言模型技术的快速发展，我们设想了一款产品智能助手，能够像专家一样为用户提供即时、准确的产品答疑服务。该设想基于以下技术调研结果：

• LLM 优势：具备强大的自然语言理解和广泛的知识覆盖能力
• RAG 价值：通过引入外部知识源，有效补充 LLM 的知识局限，提高问答准确率

自研 RAG 的必要性

在技术选型过程中，我们评估了多个开源及商业化 RAG 方案，发现其难以直接适配我们的数据结构与业务需求。此外，为了深入掌握前沿技术、积累研发经验并实现灵活扩展，我们决定自主研发 RAG 系统，主要原因包括：

1. 内容结构差异大
   帮助文档与论坛帖子格式差异显著，通用方案难以适配。
2. RAG 技术路径丰富
   不同增强策略需逐一验证，以选择最适合自身的技术路线。
3. 动态更新频繁
   论坛内容持续更新，需研究高效的增量更新机制，保障知识库时效性。
4. 灵活适配产品设计
   自主研发更能贴合实际场景，支持未来功能演进。
5. 性能与维护可控
   自建系统在部署效率和长期运维成本方面更具优势。

QA 预生成技术的探索

在传统 RAG 方案中，用户的原始问题会直接与文档中的文本段落进行匹配检索。这种方式存在一个本质问题：用户的提问与作为答案的文本段落在语义表达上存在结构性差异，形成了错位匹配的情况。

具体来说：

• 用户提问通常是简洁的疑问句（如"如何设置响应式布局？"）
• 而文档中的答案段落往往是陈述性描述（如"在属性面板中找到布局设置选项，支持三种模式..."）
• 这种问句与陈述句之间的语义鸿沟，导致直接匹配的准确率受限

而在研究大语言模型的过程中，我们发现其具备出色的信息抽取能力，能够将一段自然语言文本中的知识点转化为结构化的形式。于是，我们提出了一个新的思路：问题与问题匹配————使用大语言模型为每段文档生成对应的“预设问题”，再通过用户问题与这些预设问题进行精准匹配。

• 传统方案：用户问题 ↔ 答案文本（语义错位）
• 改进方案：用户问题 ↔ 预设问题（语义一致）

进一步地，我们将原始文档处理为标准的 QA 对形式（一个问题 + 一个答案），一篇文档往往可拆解为多个知识点，从而生成多个 QA 对。经过大量调优，我们成功实现了这一目标，并使其能够适配各种类型和尺寸的文档。

此外，我们还发现，当用户问题同时匹配预设问题和对应答案时，检索效果更佳。因为答案中包含更多信息维度，尤其是其包含了用户的部分输入信息。相关优化细节将在后续“技术原理”章节中详细阐述。

4. 项目决策

基于前期技术验证成果，我们制定了阶段性实施计划：

短期目标（3-6 个月）：

• 为活字格、Wyn、SpreadJS、GcExcel 四款核心产品构建智能问答系统
• 覆盖帮助文档和技术社区的核心内容

长期愿景：

• 建立可持续演进的产品知识中枢体系
• 通过用户反馈驱动系统持续迭代优化

附录 - 首批支持产品

本智能助手首批覆盖葡萄城四大核心产品线，具体如下：

产品	类型	核心能力	官网
活字格	低代码开发平台	企业级应用快速构建、可视化开发	访问
Wyn Enterprise	嵌入式商业智能	自助式数据分析、多维度报表展示	访问
SpreadJS	表格控件	纯前端表格处理、Excel 兼容性	访问
GcExcel	服务端表格组件	高性能批量文档生成、云端 Excel 处理	访问