企业官网建设流程全解析

一、背景

很早之前，出现大模型和知识库结合的时候，RAG企业知识库十分火热，感觉蛮惊艳的，但因为技术发展早期，体验感是没有现在这么好。可惜当时没有记录的习惯，没能记下这技术转变，不然有以时间为基准的照片、视频，以及大家的评论或者新闻的话，感受会更加直观、具体。

后面自己去做了一个企业知识库，才慢慢理解到这个项目的大致流程。下面讲讲我的一些粗浅且粗糙看法，可能会有些认识偏差。(*^▽^*)(*^▽^*)

知识库首先要有存放的载体，那必然得有数据库，根据数据结构的不同，一般分为存储原始文档的数据库MySQL、MinIO对象存储等（）、作切块向量化和语义检索的Milvus向量数据库等、以及像百度百科那样炫酷的知识图谱（这个抽取实体、关系等等还是蛮大的工作量的）、关键词匹配的Elasticsearch（电商搜索主力）、缓存Redis等等

电商搜索

现在企业知识库免不了语义搜索的向量数据库，那就需要嵌入模型将文档转成向量放进向量数据库。检索出来的上下文是很多的，需要总结，大模型就派出用场了。当然，大模型还可以进行查询扩展等操作就不细说了，这里的逻辑不一定是大模型后出场，只是我这么表述可能顺口些。

前端交互界面的搭建，与后端API的连接，基本上构成了RAG知识库了。

其实每一个步骤看似简单，其实有蛮多深挖的地方的。比如索引构建（预索引、后索引）、检索方式等等，以一个看似简单的嵌入模型的选择为例：支持多语言、高维模型拥有更丰富、准确的语义、资源考虑、是否多模态等等都是需要考虑的，每个模型的特点决定了不同的应用场景，比如1024维虽然有更丰富语义，但是储存占用空间比较大、转成向量时间也慢些。

技术细节就不深入了，这里探讨一些别的看法。

我原本以为，只要大模型够强，就能造出达到预期的知识库。后面发现，大模型并不是好的RAG知识库的全部，其实大部分工程是花在了文档处理上（梳理原始文档、拆分知识块、测试badcase），后来发现，需要存储的信息预处理好了才是好的知识库的关键。

二、知识库的几大难题

显而易见，储存的信息是需要处理的，不是所有信息数据都可以无脑存的。换言之，知识库最大的问题不是技术，而是数据不干净，流程不明确。

2.1 文档散落

核心知识藏在“边边角角”，比如一份产品手册的核心信息全在Excel合并单元格里，解析后全是乱码，相当于“白搭”。

2.2信息冲突

同一个问题有多个版本，比如报销制度有2022、2023、2024年三个版本，AI不知道该用哪个，可能乱挑一个，员工发现错了就不用了。这个其实蛮麻烦的，有些知识无从求证。

2.3 格式复杂

文档格式模型读不懂，比如带表格的Word、跨页PDF、Excel里嵌套公式，人能看懂但模型不一定。人工介入+转markdown是个不错的办法，能解决很多问题。

2.4 主题混杂

一份文档里有产品介绍、定价、法务条款，切片后每一块都不完整（比如“一刀切”导致信息断裂）。切块也是门大学问，好多需要考虑的点^_^

2.5 其他

企业由人和实体资产、软实力资源构成，资产和软实力不会创造企业知识，只有人能创造企业知识。由于各种主观和客观原因，企业是不可能获得“人的所有知识”的，所以数据不干净、流程不明确反而符合真实客观规律。

三、知识库自检

1. 新人测试：公司新人入职第一周，能不能靠知识库找到80%的工作答案？如果新人不停加老员工微信问，说明知识没沉淀。但从别的角度讲，没有沟通交流也不好，只是要把握好度。
2. 答案一致性：同一个问题问不同部门，答案是否一致？比如问“今年的休假政策”，HR、财务、业务leader答案冲突，说明知识没拉齐（AI会给出多个答案，用户蒙了）。
3. 权威版本：核心文档有没有“唯一权威版本”和负责人？好多企业答不出“考勤制度的最新版在哪、谁负责更新”，说明流程不顺（知识库变成“过期信息集散地”）。这个时候其实知道了，不需要将所有信息、知识全部塞入知识库，可以通过别的方式实现，比如门口贴个告示（好古法，哈哈哈哈）.......

四、总结

很多人说企业AI的瓶颈是算力、模型、数据量，但其实真瓶颈是“知识工程”（把散落、冲突的知识整理成结构化形态）和“流程工程”（比如AI嵌进业务流程的责任边界）。其实在实际案例中，汇总知识存到知识库这种挺不好做的，这不是技术问题，是一个政治问题，毕竟谁想将自己工作收获、沉淀全部无偿奉献给公司呢？

有个好玩的想法，可以把个人所见所闻、经历存到知识库，可以写 ***人物传记，嘿嘿！！不过，这里也涉及到极其严重的隐私问题。不知道以后知识库还能有什么新玩法......