文章目录零项目位置一文档处理1.1原始文档1.2文档转换二格式2.1章节2.2标识与转义符号2.3目录2.4表格三目标四数据测试4.1性能实测1偏BM254.2性能实测2偏BM254.3性能实测3偏语义4.4召回质量4.5本地vs在线零项目位置我的项目Repo https://github.com/ShionWakanae/llamaIndexSample。一文档处理要进向量数据库以及让LLM理解文档内容目前只能用文本。而纯文本类型人和LLM都较好处理的可能唯有Markdown.md格式了。1.1原始文档刚开始就很难……没有统一的处理方式……理论部分提到的情况更多实际我使用了几种文档格式太难的比如扫描件这里没有PDF ——.pdf参数释义类无图。Word ——.docx技术培训字典参考文档有图有表格有代码块等。PPT ——.pptx方案演示多图杀猫。EXCEL ——pptx数据模型评测对比有柱状图。比格式更加恐怖的是文档质量。企业内部文档不像对外的公开文档那么清晰有逻辑还用词准确。举个例子内部文档可能会乱用系统项目软件程序这些词。本身这些词就是相似的如果随意乱用就更加难以找到真正用户想问的内容了。再比如说企业内部文档很可能省略一些大家都知道的信息导致LLM无法理解区别在哪里。还有错别字词段落乱分。最后是作者的表达能力可能会产生很多人都容易误解的表述。这部分基本无解……1.2文档转换我们需要把各种文档转成Markdown的.md格式。有开源工具不需要自己做比如markitdownpymupdf4llmdoclingmarker……目前没有将这些源码嵌入项目中因为格式问题实在太多了最好先全部人工确认。最理想的结果是保留原文档的目录结构保留正确的表格结构代码块等等。将文档内图片进行理解并描述不是OCR输出文字对于不同类型的图片进行不同类型的描述。提取原始图片并保留原始位置上的占位符指向真实图片。这样LLM才能正确的理解章节表格图片位置究竟是什么意思并可以最终打开原始图片。有时候千言万语不如直接看看结构图这一步目前还没有实现。二格式2.1章节如果转换后的文件章节信息错误丢失那么文档也就没法用了。比如转换某个pdf我用了三款开源软件转换没有一次完美的问题有一个没有章节只有第一页第二页……一个缺失部分章节标题算效果最好的了……一个把章节全部平铺没有层级关系。2.2标识与转义符号麻烦的是毕竟Markdown虽然很文本但也有自己的格式。LLM完全可以理解Oracle\_Home就是Oracle_Home。但内容还没到LLM那里时会先经过向量数据的距离BM25的相似度。这些情况下明显是不同的字符串会影响结果。如果先进行预处理那么最后看到的Markdown格式就可能不正确。以上的例子可能从某个地方开始全是划线文字。从目前权衡来看\_最好提前替换回_。同时大部分标识也不用处理包括公式什么的留在里面LLM能理解。2.3目录文档目录是给人看的如果embedding进去反而会稀释语义。这个简单直接删[toc]甚至可以自动完成。难的是有些目录可能并不是正常的目录转换程序会把它们当成普通文字加一堆小点点。2.4表格特别是多层标题的表格转换容易错位表格一旦错位就全完了。不同的转换器对表格支持度不一样很难有完美的。比如把表头放表格内容里的。比如格式正确但是内部填充了非常多的横线这对LLM和向量数据库都是个负担。三目标这个阶段的目标就是让所有文档正确地转换为.md。并且文档标题结构层次正文列表表格代码块公式等等都正确而且去掉了目录。这个阶段是人工智能里面更偏向人工的那一部分。必须要人工审核部分文档需要真正的人工修改无法完全让程序完成。如果这部分做得好那么后续的所有环节都会轻松些。准确描述是后续所有环节都不会有任何感觉直到最后的召回总是不满意的时候要从各个环节来找原因就困难了。拿最终的提问举例这到底是不是用户想问的 回答全面没有其实很难评估。文档不方便放内容就放结果吧比如下面的情况我感觉是LLM的锅了。但是我感觉仅仅是我感觉没有任何依据。最多只能看看召回的分数具体原因也排查不了。四数据测试这部分不应该在这篇里面暂时放一下……目前的感受是性能太瓶颈了数据没什么规律。硬件环境12900f4060Ti16G64GB软件环境llama.cpp gemma-4-26B-A4B-it-UD-IQ2_M.gguf无视觉备注在显卡硬件条件下加上其它开销用gemma-4-26B-A4B-it-UD-IQ2_M模型已经占15.xGB显存了。为什么不用gemma-4-E4B-it-UD-Q8_K_XL理解力稍弱容易陷入自我否定死循环。为什么不用Qwen3.6-35B-A3B-UD-IQ2_M稍大稍慢视觉部分其它地方要用稍弱。总之在此硬件条件下LLM模型可以说还未达到RAG的要求。测试带额外文档525KB时长仅内部文档280KB时长1准确21准确无答案232准确无意义30准确263准确不够完整24准确不够完整314.1性能实测1偏BM25带额外文档python .\src\rag_cli.pySUB_DYN_EPS_ID[2026-05-03 07:58:28][RAG]Initializing...[2026-05-03 07:58:29][RAG]Loading storage...[2026-05-03 07:58:31][RAG]Loaded nodes:373[2026-05-03 07:58:32][RAG]Ready[2026-05-03 07:58:32]Question: SUB_DYN_EPS_ID[2026-05-03 07:58:32]Thinking...[2026-05-03 07:58:53]Answer: * **Format:**SUB_DYN_EPS_ID* **Description:** EPS dynamic subscription identifier,whichconsists of a single value of3digits. Reference:(1)华为移动交换机HWHSS9860 V900R008 HLR SUBSCRIBER DATAinHB.md(2)华为HSS_HB用户数据模型.md(3)中兴HSS数据模型.md(4)爱立信HSS用户数据模型.md[2026-05-03 07:58:54]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:00:00]Alldone✅仅内部文档python .\src\rag_cli.pySUB_DYN_EPS_ID[2026-05-03 08:03:10][RAG]Initializing...[2026-05-03 08:03:11][RAG]Loading storage...[2026-05-03 08:03:12][RAG]Loaded nodes:203[2026-05-03 08:03:13][RAG]Ready[2026-05-03 08:03:13]Question: SUB_DYN_EPS_ID[2026-05-03 08:03:13]Thinking...[2026-05-03 08:03:36]Answer: 不知道 Reference:(1)中兴HSS数据模型.md(2)华为HSS_HB用户数据模型.md(3)工程实施产品业务与技术.md(4)爱立信HSS用户数据模型.md(5)数据质量保障系统-任务调度平台培训提纲.md[2026-05-03 08:03:36]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:03:46]Alldone✅4.2性能实测2偏BM25带额外文档python .\src\rag_cli.pyHLR_INDEX[2026-05-03 08:00:17][RAG]Initializing...[2026-05-03 08:00:19][RAG]Loading storage...[2026-05-03 08:00:20][RAG]Loaded nodes:373[2026-05-03 08:00:21][RAG]Ready[2026-05-03 08:00:21]Question: HLR_INDEX[2026-05-03 08:00:21]Thinking...[2026-05-03 08:00:51]Answer: HLR_INDEX has the following characteristics: * **Format/Type:** It is described as a string with a single value, and is listedinthe data dictionary astypeNUMBER(3).* **Value Range:**0–255. * **Usageinspecific sections:** * **1.1 HLR_INDEX:** A string with a single value. * **16.1 PSSER(PS_PDP Service Subscription Data):** Column4, a single value. * **17.1 EPSSER(EPS_PDN Service Subscription Data):** Column4, a single value. Reference:(1)华为移动交换机HWHSS9860 V900R008 HLR SUBSCRIBER DATAinHB.md(2)华为HSS_HB用户数据模型.md[2026-05-03 08:00:53]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:01:14]Alldone✅仅内部文档python .\src\rag_cli.pyHLR_INDEX[2026-05-03 08:04:00][RAG]Initializing...[2026-05-03 08:04:01][RAG]Loading storage...[2026-05-03 08:04:02][RAG]Loaded nodes:203[2026-05-03 08:04:03][RAG]Ready[2026-05-03 08:04:03]Question: HLR_INDEX[2026-05-03 08:04:03]Thinking...[2026-05-03 08:04:29]Answer: HLR_INDEX 的相关信息如下 * 类型NUMBER(3)* KeyNaN * NULLNOT * 描述NaN * 全称NaN * 含义NaN Reference:(1)华为HSS_HB用户数据模型.md(2)爱立信HLR用户数据解析系统方案.md(3)数据质量产品线系统架构_V1.6.md(4)数据稽核管理平台系统方案.md(5)HSS等网元设备原始数据格式.md[2026-05-03 08:04:30]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:04:50]Alldone✅4.3性能实测3偏语义带额外文档python .\src\rag_cli.py华为中兴爱立信的HSS数据分哪些类型什么格式如何解析[2026-05-03 08:43:09][RAG]Initializing...[2026-05-03 08:43:11][RAG]Loading storage...[2026-05-03 08:43:12][RAG]Loaded nodes:371[2026-05-03 08:43:13][RAG]Ready[2026-05-03 08:43:13]Question: 华为中兴爱立信的HSS数据分哪些类型什么格式如何解析[2026-05-03 08:43:13]Thinking...[2026-05-03 08:43:37]Answer: 根据提供的文档内容华为、中兴和爱立信的HSS数据情况如下### 1. 华为HSS华标用户数据* **类型**分为传统融合HSS数据即2/3/4G数据以及IMS域数据两部分。 * **格式**格式化的文本文件。 * **解析方式**需要分别采集这两部分数据然后进行解压、解析并入库。### 2. 中兴HSS用户数据* **类型** * HSS3GEPC数据 * IMS数据包括TAS透明数据 * 5GNGS数据 * **格式**类似csv的文本文件。 * **解析方式**经过解压、解析、入库的固定步骤。具体如下 * **3GEPC数据**可使用压缩包解析或解压为文本文件解析。 * **IMS数据**必须解压成为文本文件解析。 * **5G数据**可使用压缩包解析或解压为文本文件解析。### 3. 爱立信HSS用户数据* **类型**包含了HSS和IMS数据两者没有分开。 * **格式**基于分布式MySQL的NDB备份数据。 * **解析方式**由于数据是分组的不能使用通用的文件解压缩节点而是由爱立信解析规则程序内部将同一组数据解压到相同的目录。 Reference:(1)数据质量产品线系统架构_V1.6.md(2)HSS等网元设备原始数据格式.md(3)华为HSS_HB用户数据模型.md[2026-05-03 08:43:42]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:44:00]Alldone✅仅内部文档python .\src\rag_cli.py华为中兴爱立信的HSS数据分哪些类型什么格式如何解析[2026-05-03 08:36:14][RAG]Initializing...[2026-05-03 08:36:16][RAG]Loading storage...[2026-05-03 08:36:17][RAG]Loaded nodes:203[2026-05-03 08:36:17][RAG]Ready[2026-05-03 08:36:17]Question: 华为中兴爱立信的HSS数据分哪些类型什么格式如何解析[2026-05-03 08:36:17]Thinking...[2026-05-03 08:36:48]Answer:### 华为HSS数据* **类型**分为传统融合HSS数据2/3/4G数据以及IMS域数据。 * **格式**格式化的文本文件。 * **解析**需要分别采集这两部分数据并经过解压、解析、入库的过程。### 中兴HSS数据* **类型**分为以下三部分 * 3GEPC数据文件名特征为QUERY_3GEPC_。 * IMS数据文件名特征为PUIINFO、PVIINFO、SIDINFO包含TAS透明数据。 * 5G(NGS)数据文件名特征为5G_。 * **格式**类似csv的文本文件。 * **解析**经过解压、解析、入库的固定步骤 * 3GEPC数据和5G数据可使用压缩包解析或解压为文本文件解析。 * IMS数据必须解压成为文本文件解析。### 爱立信HSS数据* **类型**包含HSS和IMS数据未分开。 * **格式**基于分布式MySQL的NDB备份数据。 * **解析**由于数据是分组的不能使用通用的文件解压缩节点需通过爱立信解析规则程序内部将同一组数据解压到相同的目录。 Reference:(1)数据质量产品线系统架构_V1.6.md(2)HSS等网元设备原始数据格式.md(3)华为HSS_HB用户数据模型.md[2026-05-03 08:36:53]End of answer 你要查看具体的命中信息吗[y/N]:[2026-05-03 08:37:55]Alldone✅4.4召回质量这就离谱啊不仅会从多个文档命中中找。而且还重新组织了语言编排了顺序过分的是似乎更合理了。纪念纪念 问题Q:详细按步骤说明任务出错了应该如何排查错误呢日志[2026-05-04 02:57:42]Question: 详细按步骤说明任务出错了应该如何排查错误呢[2026-05-04 02:57:53][QueryRewrite]意图是: 任务错误排查方法(step-by-step)[2026-05-04 02:57:53][QueryRewrite]关键词: 任务出错排查步骤[2026-05-04 02:57:54][Retrieve]nodes:29[2026-05-04 02:57:56][Rerank]nodes:5[2026-05-04 02:57:56]Answer starting[2026-05-04 02:58:34]Answer completed回答A:根据提供的企业资料排查任务错误可以按照以下步骤进行 第一步初步观察界面与直观日志 首先检查图形界面上的日志这是最直观的排查方式。*检查界面日志 如果能在界面上看到日志和报错通常不需要再检查操作系统日志或手动执行输出。*注意 在RHEL平台上由于WEB界面与后台任务调度引擎分离节点执行日志的内容也会存在于任务调度引擎的执行日志中位置类似于/home/用户名/actp/execution/0155/000012.log。 第二步系统与引擎层级排查若任务启动无反应 如果启动任务后没有任何反应说明可能存在环境问题导致任务调度引擎无法执行。1.检查操作系统日志*Windows平台 在“事件查看器”中检查Windows的系统日志或应用程序日志。*RHEL平台 手动执行命令./actp_tme1xxxx观察输出的报错内容。2.检查任务调度引擎日志*Windows平台 检查平台目录/1201/下的 SDAMPRule.log 或 SDAMPService.log。*RHEL平台 检查任务调度引擎运行日志位置类似于/home/用户名/actp/execution/0155/tme.log。 第三步节点与数据流排查 如果引擎运行正常但任务执行出错需深入节点内部1.检查节点输出与内部日志 检查节点输出的数据以及RHEL平台下节点内部的日志文件。2.检查上级节点 确认上级节点的输出内容是否正确因为上级节点的数据可能导致后续节点处理出错例如解压缩节点输出问题、采集不到文件、解析数据导致入库出错等。3.检查配置文件 检查出问题的节点是否存在配置错误或者是否存在编码方式导致的乱码问题。 第四步针对特定入库/解析错误的深度分析 如果错误发生在解析或入库阶段如使用 sqlldr 时1.利用错误文件分析 结合.log、.bad 和.dis 文件进行检查。*.log 文件 记录详细的报错信息例如IMSI超长、数值过大导致记录被拒绝等。*.bad 文件 记录错误的数据内容其格式通常与解析节点输出一致。2.手动测试 对于调用 sqlldr 无法成功的情况可以参考目录下的.ctl 控制文件尝试手动执行 sqlldr 命令进行测试。*注意 如果错误数据少于50条任务可能不会停止只会产生告警。 第五步对比分析法逻辑定位 如果上述步骤仍无法确定原因建议采用对比法1.对比同类任务 通过对比同类型、正常运行的任务找出可能的问题点。2.对比新旧环境/版本*如果是新环境寻找参考任务找出可能的问题。*如果是软件升级后出现问题尝试替换新旧版本观察是否与版本有关。3.检查环境变化 确认操作系统、依赖库如Windows运行库、VC库、数据库或FTP等环境是否存在变化。 提示由于企业资料可能存在不完整情况请在实际操作中参考原始文档及相关技术手册。4.5本地vs在线仅内部文档共280KB的22个markdown纯文本没有内嵌base64编码图片文件。在线的官方deepseek-v4-flash响应时间很短主要耗在输出的内容比较多按字符每秒其实更快。回答组织得挺好但感觉有点自己加戏。直观感受是几乎不需要等待就开始回答了。本地的gemma-4-26B-A4B-it-UD-IQ2_M回答没问题信息密度低些但为啥召回慢了那么多这也有影响整体感受是单次不太稳定用户需要等好一阵才能开始回答。盯着日志看还好如果是WEBUI则让人感觉等待时间太久了。本来这里准备在线千问QWEN的数据位置。但实测下来在线千问似乎无法关闭推理导致速度比本地模型还慢。我试过阿里提供的Deepseek在同一个提供商的情况下deepseek也是下面的性能。所以不是提供商的问题是模型的去向。可能千问擅长推理而不是这种文字分析归纳总结。指标Deepseek v4 flash在线gemma4 26B IQ2本地QueryRewrite意图/关键字~2s~14sRetrieve Rerank召回~3s~7sTTFT首字1s日志精度不足~25sStreaming流式输出~14s~8s输出内容长度2041 字符843 字符LLM总耗时~14.3s~33.2s全部总耗时~18.7s~53.4s