一、背景很早之前出现大模型和知识库结合的时候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 其他企业由人和实体资产、软实力资源构成资产和软实力不会创造企业知识只有人能创造企业知识。由于各种主观和客观原因企业是不可能获得“人的所有知识”的所以数据不干净、流程不明确反而符合真实客观规律。三、知识库自检新人测试公司新人入职第一周能不能靠知识库找到80%的工作答案如果新人不停加老员工微信问说明知识没沉淀。但从别的角度讲没有沟通交流也不好只是要把握好度。答案一致性同一个问题问不同部门答案是否一致比如问“今年的休假政策”HR、财务、业务leader答案冲突说明知识没拉齐AI会给出多个答案用户蒙了。权威版本核心文档有没有“唯一权威版本”和负责人好多企业答不出“考勤制度的最新版在哪、谁负责更新”说明流程不顺知识库变成“过期信息集散地”。这个时候其实知道了不需要将所有信息、知识全部塞入知识库可以通过别的方式实现比如门口贴个告示好古法哈哈哈哈.......四、总结很多人说企业AI的瓶颈是算力、模型、数据量但其实真瓶颈是“知识工程”把散落、冲突的知识整理成结构化形态和“流程工程”比如AI嵌进业务流程的责任边界。其实在实际案例中汇总知识存到知识库这种挺不好做的这不是技术问题是一个政治问题毕竟谁想将自己工作收获、沉淀全部无偿奉献给公司呢有个好玩的想法可以把个人所见所闻、经历存到知识库可以写 ***人物传记嘿嘿不过这里也涉及到极其严重的隐私问题。不知道以后知识库还能有什么新玩法......