结论
二三十份通常足够起步，前提是它们覆盖得到用户实际会问的问题。份数从来不是这类项目的关键指标，真正决定效果的是两件事：覆盖度和口径一致性。
怎么判断覆盖度
不要从文档出发，要从问题出发。找出用户最近真实问过的一批问题（几十条就够，从客服记录或聊天记录里挑），逐条问自己：这个问题的答案写在哪份文件的哪一段？
能指出来的，说明覆盖到了。指不出来的，分两种情况：一种是答案只在某位同事脑子里，那就得先写下来，这是必须补的资料；另一种是这个问题本来就不该由知识库回答（比如涉及报价谈判、个案处理），那它属于转人工的范围，不用补文档。
走完这一轮，您会得到一份很具体的补充清单，比笼统地问「要多少份」有用得多。
比份数更要紧的是口径
您提到「有重复也有对不上的地方」——这才是这类项目最常见的卡点。
同一条规则在三份文件里有三种写法，全部入库之后，系统检索到哪份就按哪份答，于是它今天这么说、明天那么说。用户会认为它在乱编，其实它很忠实地引用了您自己的文件。
所以入库之前要做的是列一张冲突清单，请业务方逐条裁定哪份算数，裁定后的版本才是知识库的唯一来源。这一步技术替代不了，而且经验上它是整个项目里最容易被低估的工作项——我们做过的项目里，预估两天、实际用掉将近两周的情况是常态，时间主要花在等内部拍板上。
几件顺手要做的事
第一，过期文件要下架而不是留着。留在库里的旧版本迟早会被检索到。
第二，扫描件和图片要单独挑出来。它们看起来和其他文档一样，但不做文字识别是一个字都检索不到的，识别质量差的还要人工校对。
第三，表格类内容要提前打招呼。表格入库需要单独处理，直接切开会让行和表头分家，检索出来的片段不可读。
第四，想清楚哪些文档是分级的。如果库里既有公开资料也有内部制度，权限要在检索这一层就隔离，这会涉及和您现有账号体系的对接，属于要在评估阶段确认的事。