文章目录
- （零）项目位置
- （一）文档处理
- （1.1）原始文档
- （1.2）文档转换
- （二）格式
- （2.1）章节
- （2.2）标识与转义符号
- （2.3）目录
- （2.4）表格
- （三）目标
- （四）数据测试
- （4.1）性能实测1：偏BM25
- （4.2）性能实测2：偏BM25
- （4.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格式。
有开源工具不需要自己做，比如：
- markitdown
- pymupdf4llm
- docling
- marker
- ……
目前没有将这些源码嵌入项目中，因为格式问题实在太多了，最好先全部人工确认。
最理想的结果是：
- 保留原文档的目录结构，保留正确的表格结构，代码块等等。
- 将文档内图片进行理解并描述（不是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的锅了。
但是我感觉仅仅是我感觉没有任何依据。
最多只能看看召回的分数，具体原因也排查不了。
（四）数据测试
这部分不应该在这篇里面，暂时放一下……
目前的感受是性能太瓶颈了，数据没什么规律。
硬件环境：12900f+4060Ti16G+64GB
软件环境：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 | 准确（无答案） | 23 |
| 2 | 准确（无意义） | 30 | 准确 | 26 |
| 3 | 准确不够完整 | 24 | 准确不够完整 | 31 |
（4.1）性能实测1：偏BM25
带额外文档：
>python .\src\rag_cli.py'SUB_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)华为移动交换机（HW）HSS9860 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.py'SUB_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.py'HLR_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 astype`NUMBER(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)华为移动交换机（HW）HSS9860 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.py'HLR_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)* Key：NaN * NULL：NOT * 描述：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用户数据* **类型**： * HSS（3GEPC）数据 * IMS数据（包括TAS透明数据） * 5G（NGS）数据 * **格式**：类似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 | ~14s |
| Retrieve + Rerank（召回） | ~3s | ~7s |
| TTFT（首字） | <1s（日志精度不足） | ~25s |
| Streaming（流式输出） | ~14s | ~8s |
| 输出内容长度 | 2041 字符 | 843 字符 |
| LLM总耗时 | ~14.3s | ~33.2s |
| 全部总耗时 | ~18.7s | ~53.4s |
