1. 从一根高性能绳索到一套智能知识系统

1.1 三个看似无关的词，为什么会出现在同一个标题里

如果把 “Elven Rope” “Ultra-High Molecular Weight Polyethylene” 和 “LLMs” 放在一起，很多人第一反应是这三者毫无关系。Elven Rope 是一种高性能绳索的产品系列名称，Ultra-High Molecular Weight Polyethylene（超高分子量聚乙烯，简称 UHMWPE）是制造这类绳索的核心材料，LLMs 则是 2025 年已经广泛落地的大语言模型应用技术。三者的连接点在业务场景里其实非常自然：

• Elven Rope 代表具体业务实体：绳索产品系列、规格书、测试报告、使用说明。
• UHMWPE 代表技术本质：材料强度、编织工艺、耐磨性、强力等级、参照标准。
• LLMs 代表新的生产力工具：用于解析技术文档、构建知识问答、辅助选型和排查故障。

换句话说，这篇文章要解决的并不是“绳子怎么造”的问题，而是“当一家生产高性能绳索的公司积累了大量产品资料后，如何用大语言模型把文档变成可查询的智能知识系统”。这也是 2025 年企业知识管理最常见的落地场景之一。

1.2 先了解一下 UHMWPE 绳索产品的基本背景

超高分子量聚乙烯是指分子量通常在一百万以上的聚乙烯材料，它有一个非常突出的特点：比强度极高、密度低、耐磨、耐候，所以被广泛用来制造缆绳、吊索、渔网、防切割手套等产品。在绳索领域，UHMWPE 纤维制成的成品常用商品名包括 Dyneema、Spectra，也包括本文示例中的 Elven Rope 系列。

以 Elven Rope 为例，一份典型的技术手册可能包含：

• 产品规格：直径、线密度、断裂强力、延伸率。
• 材料说明：UD 布或编织工艺、纤维规格、涂层方式。
• 使用建议：适用场景、存储方式、报废判定标准。
• 测试记录：破断拉力、蠕变测试、UV 老化结果。
• 安全提示：载荷安全系数、切勿接触尖锐摩擦表面等等。

这类文档往往既有大量专业术语，又有很强的结构层次，客户和一线销售经常需要反复查阅。因此，把它交给 LLM 处理，并配合检索增强生成技术，就能在一个内部系统里完成“文档检索-信息抽取-答案生成”的闭环，降低知识获取成本。

1.3 为什么选择 RAG 而不是直接微调模型

在 2025 年，微调大模型的门槛已经大幅降低，但对 UHMWPE 绳索这类垂直领域，RAG（Retrieval-Augmented Generation，检索增强生成）仍然是性价比更高、风险更小的方案：

因此本文的实战部分将围绕“文档解析 → 分块 → 向量化 → 检索 → 生成答案”这条完整链路展开。

2. 环境准备与整体架构设计

2.1 需要准备哪些运行环境

本文示例以最小依赖实现，重点演示思路，生产环境可以根据需要替换组件。示例环境如下：

这里选择 Ollama 是考虑到本地部署方式最容易复现，不依赖外部云环境。如果你公司已经接入了合规的云 API，也可以直接把代码中的 base_url 和 model 改成对应平台的兼容接口。版本方面，Ollama 和模型更新较快，本文示例命令按当时常用版本编写，实际使用请以你安装的版本为准。

2.2 模型选择思路

在 RAG 系统中，模型分两类：

• Embedding 模型：把文本变成向量，用于计算相似度。选择标准是“中文效果较好、维度稳定、部署简单”。本地环境使用 nomic-embed-text 可以满足演示；企业生产可以考虑 bge-m3 或 m3e 系列，但需要自行安装依赖。
• 对话生成模型：根据检索到的上下文生成最终答案。本地 7B 级别模型（例如 qwen2.5:7b）已经具备较强的中文理解和指令跟随能力；如果服务器内存较小，可以先选择 3B 或 4B 模型验证链路。

要注意的是，同一个系统中两个模型的 embedding 维度必须一致，否则向量相似度计算会报错。下面代码中也会加入维度校验。

2.3 系统架构和请求链路

整个系统的数据流向可以拆成两个阶段。

离线索引阶段：

1. 读取 PDF/Word/Markdown 等原始文档。
2. 按层级抽取正文内容，去除页眉页脚。
3. 将长文档切成多个分块。
4. 调用 Embedding 接口生成向量。
5. 将分块文本和向量写入索引库。

在线问答阶段：

1. 用户提出问题。
2. 对问题生成同等维度的向量。
3. 在索引库中做余弦相似度检索，取 Top-K 分块。
4. 将 Top-K 分块拼入 Prompt。
5. 调用对话模型生成答案。
6. 返回答案并附上参考片段。

理解了这条链路后，再用代码实现就会非常清晰。

2.4 项目目录结构

建议按下面的结构组织代码：

elven-rope-llm/ ├── data/ │ └── elven_rope_manual.pdf ├── src/ │ ├── loader.py │ ├── splitter.py │ ├── embeddings.py │ ├── retriever.py │ ├── chat.py │ └── main.py ├── requirements.txt └── README.md

后续每个文件对应一个独立功能模块，便于单独测试和替换。

3. 核心技术拆解

3.1 文档解析需要注意什么

PDF 解析是整个流程最容易踩坑的一步。市面上常用的解析工具有 pypdf、pdfplumber、PyMuPDF、MinerU 等。它们的区别主要体现在：

• pypdf：轻量，适合普通文本型 PDF。
• pdfplumber：对表格有更精细的控制，解析速度较慢。
• PyMuPDF：速度快，内置较多图像与文本处理能力。
• MinerU：适合复杂版面、OCR 场景，但安装依赖较重。

对于产品手册这类以文本为主的 PDF，pypdf 在大多数场景下够用。如果遇到扫描版 PDF，则必须接入 OCR，本文第一部分暂不展开，常见问题章节会专门说明。

3.2 分块策略：太小和太大都会出问题

分块大小对检索效果影响很大。分块太小，上下文信息不完整；分块太大，向量会被“稀释”，同时占用的 Prompt 空间也会变大。常见的经验值：

• 普通文本分块：500~1000 字符。
• 产品规格类文档：可以按规格表为单位整体保留。
• 分块重叠：100~200 字符，用于缓解边界截断问题。

下面是一个简单的按字符长度切分并保留重叠窗口的实现。

def split_text(text, chunk_size=800, overlap=120): """按字符长度切分文本，chunk_size 为目标长度，overlap 为重叠长度。""" chunks = [] start = 0 text_len = len(text) while start < text_len: end = min(start + chunk_size, text_len) chunks.append(text[start:end]) if end == text_len: break start = end - overlap return chunks

这只是兜底方案。实际产品手册往往有清晰的一级标题、二级标题，更推荐先按标题结构拆分，再把过长的段落二次切分。后面在最佳实践章节会提到。

3.3 Embedding 模型与向量相似度

文本向量化的核心目的，是把自然语言转换为高维空间中的坐标。语义相近的文本在向量空间中距离更近。常用的相似度度量方式是余弦相似度，公式如下：

similarity = (A · B) / (||A|| * ||B||)

值越接近 1，表示两个文本的语义越接近。

在 Python 里可以用 numpy 一次计算出问题向量与所有文档向量的相似度，然后取 Top-K：

import numpy as np def cosine_similarity(query_emb, doc_embs, top_k=3): q = np.array(query_emb, dtype=np.float32).reshape(1, -1) docs = np.array(doc_embs, dtype=np.float32) q_norm = q / (np.linalg.norm(q, axis=1, keepdims=True) + 1e-9) docs_norm = docs / (np.linalg.norm(docs, axis=1, keepdims=True) + 1e-9) scores = docs_norm @ q_norm.T scores = scores.flatten() top_indices = np.argsort(scores)[::-1][:top_k] return top_indices, scores[top_indices]

一个小提示：做相似度之前一定要进行向量归一化，否则不同文档的向量长度不同，会影响排序结果。上面代码里通过 L2 归一化消除了向量长度的影响。

3.4 Prompt 设计：让模型“只回答知道的”

检索到材料后，如何把它交给 LLM 是决定回答质量的关键。一个比较稳妥的 Prompt 模板如下：

你是一个材料领域的知识助手。请根据下面提供的资料回答问题。 要求： 1. 只依据资料内容回答，资料中没有的信息必须明确说明“资料中未找到相关内容”。 2. 涉及规格、参数时，尽量引用资料原文。 3. 不要编造测试数据和技术参数。 资料： {context} 问题：{question}

把“避免幻觉”写进系统提示词，比单纯说“你要准确”更有效，因为它给了模型一个明确的兜底动作，即回答不上来时可以直接说明。

4. 完整实战：跑通一个 UHMWPE 绳索知识问答 Demo

4.1 准备示例文档

本文假设你手头有一份《Elven Rope 产品技术手册》，内容包含产品规格和安全说明。示例文档片段如下：

Elven Rope 采用超高分子量聚乙烯（UHMWPE）纤维编织，断裂强力高于同等直径的钢丝绳，但重量仅为钢丝绳的 1/7 左右。常用规格包括 6mm、8mm、10mm、12mm、16mm。8mm 规格额定破断力为 50kN，实际使用安全系数建议不低于 5:1……

注意：这是用于演示的示例文字，不代表任何真实产品的官方参数。你在实际项目中必须使用企业内部的真实技术文档。

为了方便演示，你也可以把这段文字保存为纯文本文件，跳过 PDF 解析步骤，直接进入分块与向量化。建议两种方式都试一遍，便于对比 PDF 解析前后的效果。

4.2 安装依赖

先创建虚拟环境并安装依赖：

python -m venv venv source venv/bin/activate pip install -r requirements.txt

requirements.txt 内容如下：

requests==2.31.0 numpy==1.24.3 pypdf==4.2.0

如果安装 pypdf 失败，可以暂时用 read_text 模块读 TXT，不影响后续链路。

4.3 启动本地模型服务

本地使用 Ollama 部署两个模型：

ollama pull nomic-embed-text ollama pull qwen2.5:7b ollama serve

第一条命令下载文本向量模型，第二条下载对话模型。ollama serve会在本地默认端口 11434 启动服务。Ollama 默认提供 OpenAI 兼容接口，因此我们的代码可以直接请求/v1/embeddings和/v1/chat/completions。

如果你是在远程服务器上部署，需要把代码里的 base_url 改成服务器地址，并注意网络和鉴权配置。如果是 2025 年常见的云 API 平台，同样也是兼容 OpenAI 接口，字段基本一致，少数平台需要额外传model标识。

4.4 编写文档解析与分块模块

文件路径：src/loader.py

from pypdf import PdfReader def load_pdf(path): """读取 PDF 并拼接所有页面的文本。""" reader = PdfReader(path) pages_text = [] for page in reader.pages: text = page.extract_text() if text: pages_text.append(text) return "\n".join(pages_text) def load_text(path): """读取普通文本文件。""" with open(path, "r", encoding="utf-8") as f: return f.read()

文件路径：src/splitter.py

def split_text(text, chunk_size=800, overlap=120): chunks = [] start = 0 text_len = len(text) while start < text_len: end = min(start + chunk_size, text_len) chunks.append(text[start:end]) if end >= text_len: break start = end - overlap return chunks

4.5 编写 Embedding 客户端

文件路径：src/embeddings.py

import requests class EmbeddingClient: def __init__(self, base_url="http://localhost:11434/v1", api_key="ollama", model="nomic-embed-text"): self.base_url = base_url.rstrip("/") self.api_key = api_key self.model = model def embed_texts(self, texts): """输入一段或多段文本，返回向量列表。""" if isinstance(texts, str): texts = [texts] payload = { "model": self.model, "input": texts, } headers = {"Authorization": f"Bearer {self.api_key}"} resp = requests.post( f"{self.base_url}/embeddings", json=payload, headers=headers, timeout=60, ) resp.raise_for_status() data = resp.json() if "data" not in data: raise ValueError(f"Embedding 接口返回格式异常: {data}") embeddings = [item["embedding"] for item in data["data"]] return embeddings

这里关于 requests 和 None 值的处理可以再补充。实际运行中如果 API 返回非 JSON，resp.json() 会抛异常，建议在生产代码中增加错误重试。

4.6 编写检索层

文件路径：src/retriever.py

import numpy as np class VectorStore: def __init__(self): self.chunks = [] self.embeddings = None def add(self, chunks, embeddings): self.chunks = chunks self.embeddings = np.array(embeddings, dtype=np.float32) def query(self, query_emb, top_k=3): q = np.array(query_emb, dtype=np.float32).reshape(1, -1) if self.embeddings is None or len(self.chunks) == 0: return [], [] q_norm = q / (np.linalg.norm(q, axis=1, keepdims=True) + 1e-9) docs_norm = self.embeddings / (np.linalg.norm(self.embeddings, axis=1, keepdims=True) + 1e-9) scores = docs_norm @ q_norm.T scores = scores.flatten() top_indices = np.argsort(scores)[::-1][:top_k] top_chunks = [self.chunks[i] for i in top_indices] top_scores = [float(scores[i]) for i in top_indices] return top_chunks, top_scores

4.7 编写对话客户端

文件路径：src/chat.py

import requests class ChatClient: def __init__(self, base_url="http://localhost:11434/v1", api_key="ollama", model="qwen2.5:7b"): self.base_url = base_url.rstrip("/") self.api_key = api_key self.model = model def chat(self, messages, temperature=0.2): payload = { "model": self.model, "messages": messages, "temperature": temperature, } headers = {"Authorization": f"Bearer {self.api_key}"} resp = requests.post( f"{self.base_url}/chat/completions", json=payload, headers=headers, timeout=120, ) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"]

4.8 组装主流程

文件路径：src/main.py

from loader import load_pdf, load_text from splitter import split_text from embeddings import EmbeddingClient from retriever import VectorStore from chat import ChatClient DOC_PATH = "../data/elven_rope_manual.pdf" EMBED_BASE_URL = "http://localhost:11434/v1" EMBED_MODEL = "nomic-embed-text" CHAT_BASE_URL = "http://localhost:11434/v1" CHAT_MODEL = "qwen2.5:7b" def build_index(): embed_client = EmbeddingClient(base_url=EMBED_BASE_URL, model=EMBED_MODEL) # 如果无法解析 PDF，可以改用 load_text("../data/elven_rope_manual.txt") raw_text = load_pdf(DOC_PATH) chunks = split_text(raw_text) print(f"文档分块数量: {len(chunks)}") embeddings = embed_client.embed_texts(chunks) store = VectorStore() store.add(chunks, embeddings) print("索引构建完成") return store, embed_client def ask(store, embed_client, chat_client, question): query_emb = embed_client.embed_texts([question])[0] top_chunks, top_scores = store.query(query_emb, top_k=3) print("召回片段得分：", [round(s, 4) for s in top_scores]) context = "\n\n".join(top_chunks) system_prompt = ( "你是一个材料领域的知识助手。请根据下面提供的资料回答问题。\n" "要求：\n" "1. 只依据资料内容回答，资料中没有的信息必须明确说明“资料中未找到相关内容”。\n" "2. 涉及规格、参数时，尽量引用资料原文。\n" "3. 不要编造测试数据和技术参数。" ) user_prompt = f"资料：\n{context}\n\n问题：{question}" messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ] return chat_client.chat(messages, temperature=0.2) if __name__ == "__main__": store, embed_client = build_index() chat_client = ChatClient(base_url=CHAT_BASE_URL, model=CHAT_MODEL) while True: q = input("\n请输入问题（输入 exit 退出）：") if q.strip().lower() == "exit": break try: answer = ask(store, embed_client, chat_client, q) print("\n==== 回答 ====") print(answer) except Exception as e: print("发生错误：", e)

代码逻辑并不复杂，核心就是：

1. 加载 PDF，分块，生成向量。
2. 启动一个交互式问答循环。
3. 对每个问题先向量化，再检索 Top-3 片段。
4. 将片段拼入 Prompt，交给 LLM 生成答案。

这种实现虽然只是一个 Demo，但已经具备 RAG 系统的完整骨架。后面替换成更完整的向量数据库组件时，只需要改动 VectorStore 内部实现即可。

4.9 运行与验证

在项目根目录执行：

cd src python main.py

预期输出大致如下：

文档分块数量: 23 索引构建完成 请输入问题（输入 exit 退出）：Elven Rope 8mm 的破断力是多少？ 召回片段得分： [0.7211, 0.6823, 0.6134] ==== 回答 ==== 根据资料，Elven Rope 8mm 规格的额定破断力为 50kN。实际使用中建议安全系数不低于 5:1。

对于未收录的问题，例如“Elven Rope 是否通过海洋认证”，模型应该回答“资料中未找到相关内容”，而不是强行编造。这也是验证 RAG 是否生效的重要指标。

4.10 升级为真实向量数据库

内存版 VectorStore 只适合原型验证数据量较小的情况。如果你有几百篇甚至上千篇产品文档，就需要引入专业向量数据库。2025 年常见的选型包括：

切换到 Chroma 的成本很低，因为 Chroma 提供了与上述 VectorStore 类似的 add/query 接口。需要注意 Embedding 维度必须与 collection 创建时一致，否则查询会报错。

5. 常见问题与排查思路

5.1 常见问题对照表

5.2 排查步骤建议

当检索结果不理想时，建议按下面的顺序逐层排错：

1. 先确认文档解析结果：把raw_text输出到文本文件，人工查看是否存在乱码、缺字、重复页眉。
2. 再确认分块质量：打印前 3 个 chunks，检查是否出现半句话、表格断裂、标题丢失。
3. 然后检查检索结果：打印 Top-K 片段和相似度分数，看看召回的片段和问题是否语义相关。
4. 最后检查生成结果：如果检索是对的但回答仍然错误，重点调 Prompt 和参数 temperature。

5.3 一个典型的“回答错误”案例

用户提问：“Elven Rope 可以用在哪些海事场景？”

假设检索到的 Top-3 片段分别是产品规格表、材料介绍、仓储说明，那么模型很可能只回答产品规格，而不会主动提及海事场景。这不是模型“笨”，而是相关性排序没找到关键词“海事”。

解决方案有两种：

• 在检索层加入关键词召回，与向量召回做加权融合。
• 将文档中“应用场景”单独设置成一个字段，检索时优先返回该字段内容。

关键词召回实现起来并不复杂，甚至可以对每个 chunk 保存一个关键词集合，查询时先用 BM25 或简单的词频统计召回一批，再与向量召回结果做融合。对于材料类文档，专业术语如“海水腐蚀”“UV 老化”“安全系数”往往比语义向量更可靠。

6. 工程化最佳实践建议

6.1 数据治理是 RAG 系统的生命线

很多人构建 RAG 时只关注模型效果，忽略了源数据质量。实际产品手册里常常混有目录、修订记录、免责声明、重复章节。建议在入库前做以下处理：

• 移除页眉页脚、页码、水印。
• 把标题层级（章、节、条）映射到文档结构。
• 表格数据尽量转为 Markdown 表格或 JSON，避免向量模型无法理解二维关系。
• 为每个 chunk 添加元数据，例如“产品型号”“材料”“测试标准”“章节名称”，方便检索时用元数据过滤。

元数据过滤的例子是：如果用户问“10mm 规格的最大工作载荷”，系统可以先通过规格=10mm过滤出相关文档，再在剩余文档中做向量检索，这样可以显著提升准确率。

6.2 评估效果不能只看“答得顺不顺”

RAG 系统的效果评估建议从两个维度入手：

• 检索质量：计算 Top-K 范围内是否包含正确答案，可以用 Recall@K 指标。
• 生成质量：检查答案是否忠于上下文、是否解决用户问题、是否存在幻觉。

实操中可以先准备一份包含 50 条问题的 Golden Set，每条问题对应正确答案对应的文档片段。每次改完 Prompt 或分块策略后，用这份 Golden Set 做回归测试，避免“改了一个问题，带崩一片问题”的情况。

6.3 权限与安全边界

企业知识库往往涉及敏感数据，务必重视权限控制。在生产系统中不要把所有文档放进同一个索引，也不要让所有用户看到全部答案。建议：

• 文档入库时按部门或访问级别打标签。
• 检索时根据用户身份动态拼接过滤条件。
• 记录每次问答日志，包括用户 ID、问题、召回片段、模型答案，便于审计和排错。
• 对模型接口做限流和超时控制，避免内部系统被打满。

6.4 从 Demo 到生产要注意的差异

本地演示代码用内存向量库、requests 直连 Ollama，生产环境则需要考虑：

• 索引服务：使用 Milvus、Elasticsearch 或云向量库。
• 模型部署：使用 vLLM、SGLang 等推理框架提升吞吐量。
• API 网关：统一鉴权、限流、监控。
• 增量更新：新文档发布后自动触发解析和入库，而不是手动跑脚本。
• 反馈闭环：收集用户对回答的点赞/点踩，定期评估模型和检索效果。

6.5 成本控制思路

本地部署的显存和 GPU 开销是主要成本。如果只是内部工具，7B 模型通常已经够用；但如果日请求量很大，可以考虑：

• 使用 3B~4B 小模型处理简单检索式问答。
• 对高频问题做答案缓存，命中缓存直接返回。
• 对长文档先做摘要，减少 Prompt 长度和向量化成本。

7. 进一步深挖的方向

到这里，你已经掌握了一个基于 UHMWPE 绳索文档的 RAG 问答系统从零到一的建设过程。文章开头的三个关键词——“Elven Rope、UHMWPE、LLMs”——现在形成了一个清晰的技术闭环：

• Elven Rope 代表业务对象和产品手册。
• UHMWPE 决定了文档内容和专业术语的复杂度。
• LLMs 负责将分散的文档转化为可直接查询、可解释答案的知识服务。

接下来可以继续学习的方向包括：知识图谱与 RAG 的结合、长期记忆与多轮对话、Agent 自动调用外部 API 完成选型计算、以及自动化评估与回归测试。建议不要一开始追求大而全，而是先把一份真实产品手册跑通，针对高频问题不断打磨检索和 Prompt。当你发现 80% 的问题可以被稳定回答时，这个系统的价值就已经体现出来了。