企业官网建设流程全解析

佛山网站快速排名提升,盘锦市建设局网站地址,尚海整装和沪佳哪个好,南通网站建设制作公司过去两年做企业大模型应用#xff0c;知识库类型的项目咨询占比算是最高的#xff0c;有公众号、知乎这些平台上来的#xff0c;也有线下转介绍的。大家上来普遍会先问报价#xff1a;有大概几千份文档#xff0c;做一套知识库多少钱#xff1f;早期我会根据文档数量大概…过去两年做企业大模型应用知识库类型的项目咨询占比算是最高的有公众号、知乎这些平台上来的也有线下转介绍的。大家上来普遍会先问报价有大概几千份文档做一套知识库多少钱早期我会根据文档数量大概估一个工时结果后来很多项目做起来发现完全不是那么回事。同样是两千份有的企业文档结构清晰、格式统一清洗入库一周搞定而有的企业文档里夹杂着扫描件、合并单元格、论坛爬虫数据光清洗就得折腾半个月。数据治理这部分往往会占到整个工程量的大头但之前都是 case by case 地处理繁琐且重复。报价报低了干起来又累又亏报价报高了尤其是远程来的咨询没有信任基础很多事儿就不了了之了。后来我改成让客户先发一些脱敏后的样例文档过来跑一遍预检再报价。但这个做法也有些问题。大部分客户挑选的样例往往不能代表全貌要么挑的太简单要么挑的太复杂总之讲不清楚实际情况。基于样例做报价和 POC还是会有偏差。再后来和一些信任关系比较好的线下客户合作签完保密协议之后能直接接触到全量文档。拿到全量数据之后我会先做一遍整体的文档分布分析和入库前的质量检查看看格式分布、扫描件占比、敏感信息、文档长度分布这些。这样才能给出靠谱的工作量评估把握一期需求边界、哪些二期处理、和老板对齐预期。做了十几个项目之后这套流程跑熟了我开始想着能不能把这些逻辑产品化。先把数据治理这部分尽快抽象出来整理成一个可复用的工具包。后续还会陆续把分块策略、检索策略、检索效果评测这些也做一些抽象整理一些经验给大家参考。这个工具包我规划了三种使用场景内部治理、产品交付、售前咨询这篇主要讲的是第一步数据质量评估模块也就是入库预处理。这篇试图说清楚这个工具包的三种使用场景技术选型和第一版功能在实际使用过程中发现了哪些属于过度开发、哪些应该砍掉功能收敛之后的设计原则几个值得展开的技术细节以及产品体验上的一些打磨。以下enjoy:1、三种使用场景关于这个工具包的使用场景一方面是开头提到的售前场景客户不愿意给原始数据那就让他在本地跑一遍生成一份脱敏报告发过来我拿着报告就能给出靠谱的报价。另一方面是日常做项目交付的时候拿到客户的文档包得先跑一遍摸清楚数据情况然后才能决定怎么清洗、怎么分块、哪些需要特殊处理。这套流程以前每个项目都要重新搭一遍现在抽象成工具包之后新项目直接跑就行。当然这两个场景都是解决我自己做项目的问题。但我意识到其他在做知识库项目的朋友可能也有类似的需求。比如企业内部的 IT 团队想盘点一下历史文档资产看看哪些能直接入库、哪些需要 OCR、哪些可能有敏感信息。这类需求其实挺普遍的只是大家以前都在各自写脚本没有一个现成的工具可以直接用。所以这个工具包封装的不只是几个脚本更有价值的地方是背后的一套工作流文档该怎么分类、扫描件该怎么识别、敏感信息该怎么检测、统计报告该展示哪些指标。这些都是过去十几个项目踩坑之后沉淀下来的经验。把这些经验封装成工具一方面自己用着省事另一方面或许也能给有类似需求的盆友提供一些参考。2、快速原型与踩坑2.1、技术选型与第一版功能技术选型上没什么特别的后端用 FastAPI Python主要是文档处理的库生态丰富前端用原生 HTML/CSS/JS轻量不需要 Node 构建工具进度推送用 SSE比 WebSocket 简单单向推送足够了图表用 ECharts开箱即用深色主题支持也好。第一版做了挺多功能。递归扫描文件夹、识别各种格式、统计格式分布这些是基础。PDF 会自动判断是文字型还是扫描型。敏感信息检测支持手机号、邮箱、身份证、银行卡。重复文件用 MD5 去重。还做了一个风险评分0-100 分红黄绿三档分级。前端是仪表盘风格的可视化报告看起来挺像那么回事。当时的心态就是功能越多越好尽量全面。但跑起来之后发现了很多问题。2.2、暴露的几个问题首当其冲的是是评分逻辑不对。很多正常的 Word 文档被标记成中风险扣了 30 分。查下来发现是.doc格式老版 Word用 python-docx 解析会失败我把解析失败等同于文件有问题这个逻辑是错的。后来加了.doc格式的单独处理逻辑在 macOS 上用 textutil 提取文本(Windows 可用 LibreOffice headless / antiword / Tika 作为后备)同时区分解析失败和文件损坏前者只轻微扣分。其次是敏感信息检测误报率太高。有次测试显示银行卡检测出 53 个但实际文档里根本没有银行卡号。原因是正则匹配 16 位数字财务表格里的合同编号、发票号全部中招。这个问题当时没想到好的解法先搁置了。还有统计颗粒度不够的问题。既然叫做入库预处理那肯定得知道文档长度的分布P50 是多少、P90 是多少这样才能决定分块策略。于是我又加了长度分布统计、长度区间直方图、预计 chunk 数和 token 数、还有分块策略建议。但这时候的心态变成了想到什么就加什么。功能越堆越多但隐约感觉哪里不对。直到后来找了两个真实项目里分别测试了下又发现一堆问题。2.3、几个过度开发的功能先说敏感信息检测。前端展示的是手机号: 524邮箱: 58银行卡: 53这样的统计数字。看完之后只知道这些敏感信息在哪些文件里不知道是真的敏感信息还是误报更不知道下一步该怎么处理。说白了就是把初筛结果当成最终结论呈现了但初筛结果本身是不可操作的。再说分块建议。我做了一个功能根据文档长度分布推荐一个 chunk size比如推荐 300 字。但仔细想想这个功能完全是画蛇添足。分块策略本身取决于很多因素像业务场景、embedding 模型的上下文窗口、检索时的精度要求。这些业务背景信息在使用这个工具包的时候实际上我作为用户实际上可能还没有了解的很全面这种做法是在试图用脚本代替业务判断肯定不对。还有风险评分。最开始设计了一套评分逻辑0-100 分红黄绿三档。但测试的时候发现两个文件显示文件损坏实际上用 Office 打开完全正常。查下来发现一个是 ~$ 前缀的临时文件确实打不开另一个是老格式文件Python 库解析失败但 Office 能打开。原始脚本里把解析失败等同于损坏这个逻辑本身就是错的。更尴尬的是扫描型 PDF 因为解析成功、无敏感信息反而得了 100 分根本不在风险清单里但扫描件明明需要 OCR 处理。想到这里我意识到问题的本质是在堆功能还没有理清核心逻辑。2.4、功能分类与取舍于是我把所有功能拆开来做了些分类哪些是准确的哪些是不准确的哪些是主观的准确的功能应该保留。格式分布统计、PDF 文字型/扫描型分流、文档长度分布、MD5 重复检测——这些都是客观的、可验证的输出就是输出没有歧义。不准确的功能需要改进。敏感信息检测的问题不是不能做而是不能只给一个统计数字得展示具体在哪个文件、哪个位置、前后文是什么让人能判断是不是误报。风险评分的问题是用评分来划分风险逻辑不如规则分类清晰不如直接按扫描件、解析失败、含敏感信息这些规则来分类。主观的功能应该删除。健康评分没有业界标准不同业务场景标准完全不同给一个分数反而误导。推荐 chunk size 更是开玩笑这本身也不是脚本能决定的事。预计 chunk 数和 token 数依赖的假设太多参考价值很低。这轮优化下来功能列表砍掉了一小半但剩下的每一个都变得更具象了。3、功能收敛与设计原则经过前面的试错我重新梳理了产品定位。整体的处理流程大概是这样的核心逻辑其实很简单这个工具的最终目的是服务于下游的分块策略和检索策略。所以输出的不应该是一份静态的文档质检报告而应该是一份可操作的配置清单告诉下游系统每份文档应该走什么处理管线。3.1、最终保留的功能想清楚定位之后功能列表就变得很聚焦格式分布统计。扫描文件夹后统计每种格式有多少份占比多少。这是最基础的数据100% 准确没有歧义。PDF 页面类型识别。判断 PDF 是文字型、扫描型还是混合型。文字型可以直接提取文本扫描型需要先做 OCR。核心逻辑是按页判断——每页字符数低于阈值就算扫描页扫描页占比超过 70% 就标记整个文件为扫描型。这是一条启发式用于分流与估算不保证严格正确因此所有阈值可配置且输出‘待确认’列表。# PDF类型判定核心逻辑 scan_ratio scan_pages / page_count if scan_ratio 0.7: pdf_type SCAN # 扫描型 elif scan_ratio 0.2: pdf_type MIXED # 混合型 else: pdf_type TEXT # 文字型文档长度分布。统计所有文档的字符数输出分位数P25/P50/P75/P90/P99和长度区间分布。这个数据直接决定分块策略这里用字符数作为粗粒度 proxy真正落地仍需结合目标 embedding 模型的 tokenizer 与上下文窗口。——如果大部分文档都在 2000 字以内那分块粒度就不用太细。# 长度分位数计算 sorted_counts sorted(char_counts) p50 percentile(sorted_counts, 50) # 中位数 p90 percentile(sorted_counts, 90) # P90 p99 percentile(sorted_counts, 99) # P99重复检测。两层机制MD5 用于识别完全相同的文件SimHash 用于识别高相似度的文档比如不同版本的同一份文件。MD5 是精确匹配SimHash 需要人工确认所以输出是待确认的版本冲突列表。敏感信息检测。支持手机号、邮箱、身份证检测银行卡检测默认关闭误报率太高。关键改进是从只展示统计数字变成展示待审核列表每条匹配记录都附带上下文。3.2、文档分类标签体系不是简单地把文件分成好和坏而是给每个文档打上一个质量标签说明它应该走什么处理管线标签判断依据推荐处理方式Clean_Markdown结构清晰可直接解析直接分块入库Scan_PDF扫描型 PDF先 OCR /vlm再分块Table_Heavy表格多 / 合并单元格多表格专用转换Image_Heavy图片密集多模态模型处理Parse_Failed解析失败需人工检查这个分类的好处是直接对接后续流程。拿到一份文档看标签就知道该怎么处理不需要再做二次判断。3.3、敏感信息的改进原来只展示一个数字手机号: 524现在改成展示具体的匹配列表每条记录包含匹配类型手机号/邮箱/身份证、脱敏后的内容如 1381234、上下文前后各 50 字符、文件路径和位置# 敏感信息检测提取上下文 context_start max(0, match.start() - 50) context_end min(len(text), match.end() 50) context text[context_start:context_end]这样实际使用的时候看到的是一份待审核清单可以逐条判断是不是误报然后决定是删除、脱敏还是保留。银行卡检测默认关闭因为 16 位数字的误报率实在太高。3.4、可配置的阈值所有涉及判断的参数都做成了可配置项默认值只是基于项目经验的推荐值# settings.py 配置示例 pdf_detection: min_text_chars_per_page: 50 # 每页最少字符数 scan_page_ratio_threshold: 0.7 # 扫描页占比阈值 sensitive: context_chars: 50 # 上下文字符数 enable_bank_card: false # 银行卡检测默认关闭 similarity: simhash_distance_threshold: 5 # SimHash汉明距离阈值这个设计的核心原则是输出客观数据不做主观评分。阈值是什么就在配置里写清楚实际使用的时候可以根据业务场景调整。需要人工判断的地方明确标记为待确认把决策权留给人工操作。4、几个值得展开的技术点前面讲了整体的设计思路这里再展开说几个实现过程中踩过的坑。4.1、PDF 扫描型判定没那么简单最初我以为逻辑很简单能解析出文字的就是文字版解析不出的就是扫描版。但实际情况比这复杂。纯文字 PDF比如 Word 导出的能正常解析没问题。纯扫描 PDF扫描仪生成的解析不出文字也好判断。问题出在中间地带——双层 PDF。很多公司会用 Adobe Acrobat 给扫描件加上 OCR 文字层这种 PDF 技术上能解析出文字但质量可能很差错字乱码一堆。还有图文混排的 PDF比如 PPT 导出的部分页面有文字部分全是图。最终的判断逻辑是按页来看# 页面类型判定 if page_chars 50: page_type scan # 扫描页 elif page_chars 200: page_type text # 文字页 else: page_type low_density # 低密度页封面、目录或OCR质量差然后统计扫描页的占比超过 70% 就标记整个文件为扫描型。当然这个阈值也是可配置的。4.2、SimHash 相似度检测MD5 只能检测完全相同的文件。但实际场景里更常见的是差不多但不完全一样的情况比如同一份文档的不同版本或者只改了几个字。这时候用 SimHash。SimHash 的原理是把文档转成一个 64 位的哈希值然后比较两个哈希值之间的汉明距离有多少位不同。距离越小文档越相似。# 汉明距离计算 def hamming_distance(hash1: int, hash2: int) - int: x hash1 ^ hash2 # 异或找出不同的位 count 0 while x: count 1 x x - 1 # 清除最低位的1 return count汉明距离建议处理0-3高概率重复建议人工确认4-6可能相似可选确认6不算相似忽略默认阈值设的是汉明距离 ≤5约等于 90% 相似。但这里有个重要的认知需要和各位对齐相似不等于冲突。两篇介绍同一产品的文档可能高度相似但都有价值系统只能识别出这两份很像不能判断哪个是旧版该删这还是需要人来确认。4.3、大型 Excel 的处理这个问题本来没在计划里是跑真实数据的时候发现的。有些 Excel 有几万行直接转文本后 token 数爆炸入库成本很高检索效果还差。原因是表格数据本质上是结构化查询场景。比如找销售额大于 100 万的客户这种需求用 SQL 查很快向量检索不擅长做数值比较和过滤但可以用结构化索引/SQL/倒排/元数据过滤做数值比较。所以大表更适合走 Text-to-SQL 而不是 RAG。最终加了一个 Excel 行数阈值的判断超过 5000 行的会单独标记出来建议走其他方案处理。5、产品体验打磨功能逻辑跑通之后最后的 10% 工作量关于产品体验打磨的部分也是往往决定了一个工具是否能真的用起来的关键。5.1、从看报告到做处理的闭环前面花了很多时间纠结怎么展示数据。但有一个问题被忽略了看完报告之后下一步是什么比如看到需 OCR4 份第一反应肯定是哪 4 份我看看。如果这时候工具只能展示一个数字或者一个静态列表就得去文件管理器里一层层找文件。这不仅麻烦而且降低了效率。改进的做法是加了一键打开功能。点击卡片展开列表点击列表项调用系统 API 直接打开本地文件。实现很简单后端就一行代码subprocess.run([open, file_path]) # macOS这看似只是一个小功能但它把工具从一个只读的仪表盘变成了一个可操作的控制台。5.2、离线报告导出这个离线报告功能上线大概有半个多月了期间经过了三四个真实客户的打磨逐步确定了现在这版报告模板。之前让客户发样例文档过来样例往往不能代表全貌。有些客户可能挑了几份干净的发过来结果真正做项目的时候发现大量扫描件和乱七八糟的格式。现在流程变成了直接把工具发给潜在客户让他在本地跑一遍全量数据然后把生成的脱敏报告发回来。报告的整体设计遵循纯净数据原则彻底脱敏文件名替换成FILE_A023路径移除敏感信息只保留聚合计数客观中立移除所有建议优化、风险极高这类主观评价只展示客观事实单文件 HTML图表和样式都内联直接双击就能打开拿到报告之后我一般会先做个总体评估扫描型 PDF 占多少、表格密集的文档有多少、P90 的文档长度大概在什么水平。这些数据心里有数之后就能大致判断项目的复杂度。如果复杂度不高简单沟通一下范围和周期就能报价。如果通过报告发现文档数量大、复杂度高的占比也不低我一般会建议先做付费 POC。一方面是为了筛选认真的客户另一方面也是因为 POC 本身有成本比如扫描件多的话 OCR 要调外部 API这些都需要提前讲清楚。POC 阶段一般会和客户充分沟通落地方案。知识库项目不是一期就要覆盖全部几千上万份文档而是先根据业务场景有针对性标题一地选一批把简单的、中等复杂度的先落地跑起来复杂的文档后面慢慢处理。技术上可以一次性全量处理但不建议这么做。知识库项目的核心逻辑还是小步快跑、快速迭代先上线一版能用的然后根据实际使用中的反馈持续优化。6、被砍掉的功能开发过程中其实还有两个功能被列在计划里但最后决定先不做了。6.1、文档截图预览原来的设想是在列表上悬浮显示文档首页截图在不打开文件就能快速判断内容。但做起来发现投入产出比不高。PDF 截图很简单用 PyMuPDF 几行代码就能搞定但 Word 和 Excel 的自动化截图很麻烦通常需要依赖 LibreOffice 或 Headless Browser。这会让项目的部署难度上升一个量级Docker 镜像可能从几百 MB 变成几个 GB。后来想想既然是本地运行的工具看截图可能是隔靴搔痒直接一键打开原文件更直接。所以用一键打开替代了截图预览保持架构的轻量化。6.2、智能聚类原来的设想是自动对文档进行向量化用 K-Means 聚类自动发现文档的潜在分类比如这堆是合同、那堆是技术文档。如果要做这个功能核心问题是 K 值怎么确定。K 就是想分几类但通常事先并不知道该分几类。这时候常用的做法是肘部法尝试不同的 K 值比如 2、3、4...20计算每个 K 对应的组内距离和SSE越小说明分得越紧凑。组内距离和 ↑ | * | * | * ← 这里开始变平缓肘部 | * * * * * ------------------------→ K值 2 4 6 8 10曲线像一只手臂拐点肘部对应的 K 值通常就是最佳选择。实际应用的话还可以让系统自动选出 K 值之后取每个聚类的 1-2 个代表文档让人来命名这一类或者用 LLM 自动生成类别名称。这部分技术思考是有的但最终没做主要是两个原因一是定位越界。这个工具的核心定位是入库前的结构质检关注的是格式、质量、复杂度这些客观指标。聚类属于内容理解范畴一旦引入就变成了语义分析工具性质完全不一样了。其次是考虑到环境负担。即使是轻量级的 Embedding 模型也会显著增加依赖比如 Torch和运行内存。对于一个定位为快速盘点的工具下载几百 MB 的模型显得太重了。最终决定坚持结构化质检的定位把语义分析留给下游的 RAG 系统去处理。如果后续有需求可能会作为独立插件来做。感兴趣盆友可以按照上面的思路自己尝试一下。7、写在最后最后简单总结一下这个工具包的工程量。后端大概 28 个 Python 脚本2500 多行代码前端原生 HTML/CSS/JS接近 3000 行。整体架构是 FastAPI 做后端、SSE 做进度推送、ECharts 做可视化。开发的难点不在于代码量而在于业务逻辑的边界处理。比如 PDF 扫描型判定表面上看就是有没有文字实际上要处理双层 PDF、图文混排、OCR 质量差这些灰色地带。再比如敏感信息检测正则匹配很简单但怎么降低误报率、怎么展示上下文让人能判断真伪这些都是一个个项目踩出来的。还有各种文档格式的解析——docx、doc、xlsx、pptx、pdf每种格式的坑都不一样老格式文件解析失败、表格有合并单元格、PDF 有加密保护这些边界情况都得处理。核心的业务逻辑其实就几个点输出客观数据不做主观评分所有阈值可配置需要人工判断的明确标记为待确认。这些原则听起来简单但都是吃过亏之后总结出来的。如果你在企业一线做知识库相关的项目不管是企业内部的数据治理还是做乙方的项目交付这个工具都能帮你省掉拿到数据先摸底这个环节的工作量。直接跑一遍格式分布、扫描件占比、敏感信息、文档长度心里就有数了。这个工具包请到同名公众号原文“阅读原文”自取。