用LLM+RAG构建UHMWPE绳索知识库：高性能材料文档智能问答实战

这次我们来看一个组合，而不是一个单一开源仓库：标题里的“Elven Rope + UHMWPE + LLM”看起来像是三类无关词，实际上指向的是 2025 年材料行业非常典型的一个技术需求——用大语言模型处理高性能材料的技术资料、产品参数和工程文档。Elven Rope 可以理解成以超高分子量聚乙烯（UHMWPE）纤维为核心的高强度绳索类产品的代称，你在消防、深海吊装、救援、登山装备里见到的那些又轻又强的绳子，大多属于这个范畴。这类产品有个很实际的问题：材料参数多、标准文件多、应用场景多，但技术文档分散在不同部门、不同格式里，想快速查准一个数据往往要翻半天。本文就用 LLM + RAG 的方式，以 UHMWPE 绳索（Elven Rope 类产品）为案例，演示如何把这类工业文档变成可检索、可问答、可批量处理的智能知识库。

先给结论：这个方案的核心价值不是让模型“更聪明”，而是让企业现有文档变成能被自然语言调用的结构化资产。适合谁？适合材料研发、产品选型、技术支持、质量溯源相关的人员，也适合想在企业内部搭建本地问答服务的开发者和运维。适合什么硬件？2025 年开源小模型已经相当能打，7B 到 14B 量级的本地模型配合 RAG 就能完成大部分产品文档问答任务；如果只是跑检索和接口服务，CPU 也可以应付，但生成环节对显存有要求。本文会带你走完环境准备、模型部署、知识库构建、功能测试、API 调用和批量任务的全流程，并把最容易踩的坑列出来。

阅读之前先统一本文的表述口径：我把“Elven Rope”当作一类 UHMWPE 高性能绳索产品的示例标识，不绑定具体品牌。文章给出的命令、代码和配置以通用实践为主，你拿到自己项目里需要替换路径、端口和模型名。凡是没有明确给定数值的参数，比如显存占用、推理速度、检索准确率，都需要按你的实际环境测试确认，我不会替编辑器里的虚拟硬件预设成绩。

1. 核心能力速览

能力项	说明
项目形态	技术方案组合：LLM + RAG + 文档解析 + API 服务，用于工业材料知识管理
典型物料	UHMWPE（超高分子量聚乙烯）产品技术文档、规格书、检测报告、应用案例
主要功能	自然语言问答、产品参数检索、引用溯源、批量文档解析、批量问答、API 集成
推理方式	本地模型推理为主，可 CPU 推理（慢），建议 GPU 加速（快）；以实际环境为准
模型量级参考	7B / 14B / 32B 量级开源模型均可试跑，显存占用以实际测试为准
启动方式	命令行启动 / Docker 启动 / API 服务启动，视所选框架而定
是否支持 API	支持，通过 FastAPI 或同类框架暴露 HTTP 接口
是否支持批量任务	支持，通过脚本或任务队列处理批量文件与批量提问
适合场景	产品技术问答、材料选型、文档检索、内部知识库、团队协作查询
不适合场景	替代真实力学实验、实时传感器数据采集、精密数值计算、未经授权的内容生成

从材料看，这是一个“基础设施型”方案，而不是“开箱即食的模型应用”。你选择了什么样的底座，决定了最终输出的质量和维护成本。下面从场景拆起。

2. UHMWPE 绳索知识库：这个组合到底解决了什么问题

先理解业务侧为什么需要 LLM。

一根高性能绳子的生命周期里会产生大量文本：纤维原料的牌号与物性、绳芯与绳皮结构、破断力测试报告、蠕变和疲劳特性、耐海水耐紫外数据、吊装与救援场景的操作规范。这些信息通常散落在 PDF、Word、Excel、扫描件、内部系统截图里。传统做法是“人找文档”：新员工翻共享盘，老员工拍脑袋给结论，或者问厂家的技术支持再等邮件回复。结果是检索效率低，信息口径不统一，同一个参数不同版本文档里可能互相矛盾。

LLM + RAG 解决的是“从文档到答案的路径”：

• 先把非结构化文档解析、切片、向量化；
• 用户提问时先做相似度检索，把相关片段捞回来；
• 再把“问题 + 检索片段”一起交给大模型生成回答，并且让回答附带来源；
• 模型没有乱编的空间，因为答案被限制在检索到的资料范围内。

这类组合在 2025 年已经不是实验室概念。工业界的落地形态往往是一个内部知识库服务：员工打开网页或者接入企业微信/钉钉机器人，输入“直径 12mm 的 UHMWPE 绳，最小破断力是多少”，几秒钟内得到带文档出处的回答。Elven Rope 这类产品天然适合这个场景，因为绳索技术文档有三个特点：

第一，专业术语密集。“UHMWPE”“蠕变”“编织结构”“断裂伸长率”“安全系数”这些词，通用模型如果不喂资料，回答全是教科书式的泛泛而谈；RAG 可以把厂家的真实试验数据喂给模型。

第二，产品参数强相关。用户关心的是某个型号能不能用在某个场景，强相关检索比模型“自由发挥”可靠得多。

第三，更新节奏快。2025 年的材料标准和产品迭代比十年前快，训练语料永远滞后，RAG 则可以把最新文档当天挂进去。

所以本文的整体方案就是：一套本地或内网部署的 LLM 服务 + 一个文档入库清洗流程 + 一个 Web 知识库页面/API 接口。它能直接复用到其他材料品类，原理是共通的。

3. 适用场景与使用边界

3.1 适合什么人用

企业内部视角，这个方案最贴合三类角色：

• 研发工程师：快速查历史试验数据、找同类材料对比表、确认某一规格的工艺参数；
• 技术销售与选型：客户问“这绳能不能做 200 米吊装”，一线人员不需要等专家，直接查知识库得到带依据的答复；
• 质量与文档管理人员：把积压的 PDF 和扫描件统一导入知识库，降低文档沉睡率。

对个人开发者来说，这也是一个很好的 LLM 应用练习样本：数据不敏感、可公开的绳索技术资料很多，适合练手 RAG 的 chunk 切分、embedding 模型选型、检索日志分析。

3.2 不适合什么场景

这个方案有几个明显边界，别硬套：

• 不替代实际测试。RAG 回答的只是“文档里写了什么”，不是“现实中会怎样”。断裂强力、耐磨性这类参数必须以出厂检测报告和第三方实测为准。
• 不适合实时数据。生产线上每秒变化的张力数据应该走时序数据库 + 实时监控，而不是塞进 RAG。
• 不适合高频精准计算。如果用户需要的是“已知破断力、安全系数，反推许用载荷”这种固定公式，直接用代码算更好，LLM 的算术稳定性未必满足要求。
• 不适合未经授权的内部资料公开。企业机密、涉密图纸、未公开专利不要随意进入任意第三方的云端大模型接口。

3.3 合规与安全提示

凡是涉及人脸、声音、版权素材、企业机密的 AI 应用，都要先过合规关。这里对应到材料行业，重点是：

• 文档授权：放入知识库的 PDF、报告、标准文件必须是公司有权使用、有权传播的版本；
• 权限隔离：不同部门只能查询自己有权限的文档，避免一个 RAG 服务把所有数据暴露给所有人；
• 隐私与数据脱敏：文档如果包含客户名单、报价、个人联系方式，入库前先脱敏处理；
• 商用边界：如果要在对外产品中嵌入 LLM 能力，需确认所选开源模型的许可证允许商用，并保留文档来源记录以备追溯。

4. 环境准备与前置条件

这部分不依赖某一个具体仓库，按通用方案列清楚。要跑通一套“LLM + RAG 文档问答”知识库，大体需要以下环境项。

4.1 操作系统与运行环境

• 操作系统：Windows 10/11、Ubuntu 20.04/22.04、Debian 等主流系统均可；生产环境更推荐 Linux，方便长时间跑服务和容器管理。
• Python：推荐 3.10 或 3.11。很多 LLM 生态库对新版本的支持滞后，用 3.10/3.11 最稳。
• Node.js / Java：不强制。如果后续要接企业微信机器人、ERP 系统，可能会用到，但不是 LLM 服务的必选项。
• Docker / Docker Compose：强烈建议。RAG 服务、向量库、模型网关用容器编排，能减少“在我机器上是好的”这类问题。

4.2 GPU 与显存

GPU 不是必须，但有 GPU 体验会好很多。按通用经验估算：

• 纯 CPU 推理：能跑，适合文本量少、并发低、不赶时间的场景；模型和框架不同，速度差异非常大。
• 7B 量级量化模型：配合 6GB 到 12GB 显存的显卡可以试一下，实际占用取决于量化精度、上下文长度和并发数。
• 14B 量级：建议 16GB 及以上显存，或者用多卡/CPU 内存替代尝试。
• 32B 量级：环境要求显著提高，一般消费级显卡比较吃力。

上面只是粗略分层。真正运行前，先用一个小批量测试集记录显存峰值，再决定要不要升级配置。

4.3 软件依赖与关键组件

组件	作用	选择建议
LLM 推理引擎	加载模型并响应生成请求	Ollama、vLLM、llama.cpp 等
大语言模型	生成回答	Qwen、Llama、Mistral 等开源系列，按许可证和中文能力选择
Embedding 模型	将文档片段转成向量	BGE、M3E 等中文友好的 embedding 模型
向量数据库	存储向量并做相似度检索	Chroma、Milvus、Qdrant、pgvector 等
RAG 编排框架	串联文档解析、检索、提示词组装、溯源	LangChain、LlamaIndex、RAGFlow 或自研脚本
文档解析	提取 PDF/Word/Excel 文本	OCR 工具 + PDF 解析库，按实际文件类型选择

4.4 磁盘与端口

• 磁盘：模型文件通常几个 GB 到几十 GB，向量库和原始 PDF 目录建议独立挂载，预留 50GB 起步的可用空间比较稳妥。
• 端口：推理服务默认端口可能是 11434（Ollama 常用）、8000（vLLM 常用）、7860（Gradio/部分 WebUI 常用）、8080（很多 API 服务常用）。启动前用netstat -ano（Windows）或ss -lntp（Linux）看一下端口占用，避免冲突。

5. 本地部署与启动流程

下面给一套通用启动模板。我这里不绑定某一个具体一体化项目，因为 LLM 生态变化快，直接给可复制的两步式思路。

5.1 第一步：拉起推理引擎

假设你用 Ollama 做模型加载（常见、命令简单，适合个人和中小团队测试）。

# 安装 Ollama 后，拉取一个中英文效果均衡的模型，替换为你实际使用的模型名 ollama pull qwen2.5:7b # 启动并保持服务运行 ollama serve

启动后可以另开一个终端验证模型是否可以正常生成：

ollama run qwen2.5:7b "简述超高分子量聚乙烯纤维做绳索时的三个优点"

这一步能通过，说明底层推理通路没问题。如果环境里没有 Ollama，换成 vLLM 或 llama.cpp 同理，关键是把“模型加载”和“HTTP 生成接口”打通。

5.2 第二步：启动向量库与 RAG 服务

选择你熟悉的向量库。以 Chroma 为例，Python 里拉起来非常轻量：

# requirements.txt 核心依赖示例，按实际项目安装 # chromadb==0.5.x # langchain==0.2.x # fastapi # uvicorn # sentence-transformers from chromadb import PersistentClient client = PersistentClient(path="./vectordata") print("向量库已启动，存储目录：./vectordata")

这个阶段的目标是把向量库独立起来，确认路径可写、依赖可导入。

5.3 第三步：文档入库与知识库构建

把 PDF、Word、Markdown 等资料放到./docs目录后，执行入库脚本。下面是伪代码结构，需要按你实际选定的组件替换导入方式：

import os from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter def load_documents(docs_dir: str): docs = [] for fname in os.listdir(docs_dir): if fname.endswith(".pdf"): loader = PyPDFLoader(os.path.join(docs_dir, fname)) docs.extend(loader.load()) return docs def split_documents(docs, chunk_size=500, chunk_overlap=50): splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=chunk_overlap, ) return splitter.split_documents(docs) def embed_and_store(docs): # 这里调用你选用的 embedding 模型，将向量写入向量库 # 注意：embedding 模型产生的向量维度必须与向量库配置一致 pass if __name__ == "__main__": data = load_documents("./docs") chunks = split_documents(data) embed_and_store(chunks) print(f"入库完成，共 {len(chunks)} 个文本片段")

5.4 第四步：启动 API 服务

API 层建议用 FastAPI 或同类轻量框架。核心逻辑是：收到用户问题 -> 向量检索 -> 组装 prompt -> 调用 LLM -> 返回答案和来源。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Question(BaseModel): query: str top_k: int = 4 class Answer(BaseModel): reply: str sources: list @app.post("/chat", response_model=Answer) async def chat(question: Question): # 真实实现里，这里做检索、构造 prompt、调用本地 LLM reply = "根据文档检索结果，该型号绳索的最小破断力数据见来源 1。" sources = ["docs/UHMWPE-rope-spec-2025.pdf#page=3"] return Answer(reply=reply, sources=sources) @app.get("/health") async def health(): return {"status": "ok"}

启动命令：

uvicorn main:app --host 127.0.0.1 --port 8000

到这里，你的本地知识库服务已经形成最小闭环。第一次搭建不要追求功能丰富，先把“文档灌进去 -> 能检索 -> 能回答 -> 能返回来源”跑通。

6. 功能测试与效果验证

部署完成后，建议按下面的测试维度逐项验证。不要只看一两个问题回答得好就说项目成功，RAG 系统的准确率和稳定性需要系统性测试。

6.1 基础问答测试

测试目的：确认 LLM 能结合检索到的资料回答问题，而不是脱离文档胡编。

输入示例：

查询：直径 10mm 的 UHMWPE 绳索，安全使用载荷一般怎么计算？

操作步骤：

1. 调用/chat接口，传入上述问题；
2. 观察回答是否包含具体数字、公式或文档描述；
3. 检查sources字段是否指向真实存在的文档片段。

判断标准：回答有据可查，且来源字段与问题内容相关。如果回答看起来很通顺但没有任何来源，说明提示词或检索链路出了问题。

常见失败原因：chunk 切分太碎导致关键信息被切断；检索到的 top_k 片段本身不包含答案；模型温度设置过高导致输出发散。

6.2 文档溯源测试

测试目的：这是 RAG 区别于普通聊天的关键能力。

输入示例：

查询：该绳的断裂伸长率标准值是多少？

预期结果：回答里不只给数值，还能指出“来自哪份文档、哪一页”。如果文档本身没有该字段，模型应当明确说“资料中未找到相关数据”，而不是硬编一个近似值。

6.3 批量问答与压力测试

测试目的：确认方案能否承担实际工作负载。

准备一批真实业务问题，写入questions.txt，逐行保存，然后用脚本批量调用：

import requests import json url = "http://127.0.0.1:8000/chat" questions = [line.strip() for line in open("questions.txt", encoding="utf-8") if line.strip()] results = [] for q in questions: resp = requests.post(url, json={"query": q}, timeout=120) data = resp.json() results.append({"question": q, "answer": data.get("reply"), "sources": data.get("sources")}) print(f"问题: {q}\n回答: {data.get('reply')}\n来源: {data.get('sources')}\n---") with open("batch_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

判断标准：所有问题都能返回结果，没有超时和空回复；批量跑完后目标进程没有内存暴涨或崩溃。

6.4 负面测试

测试目的：看模型知不知道“不知道”。

输入示例：

查询：U HMWPE 纤维在零下 80 度的低温蠕变数据？

如果知识库里没有这份数据，理想回答是“当前知识库未收录该数据”。如果模型一本正经地编出一个温度区间，说明提示词里必须加入“不知道答案时如实说明”的约束，并考虑降低 temperature 参数。

6.5 准确率评估

简单做法：从知识库里人工挖 30 到 50 个“问题-答案-文档位置”三元组作为测试集，跑完后人工给分，分成“完全正确、部分正确、错误、未找到”四类。之后每次调整 chunk 大小、embedding 模型、top_k 参数，都用同一套测试集复测，这样才知道改动是变好还是变差。

7. 接口 API 与批量任务

7.1 API 设计建议

批量任务和安全集成的前提是接口清晰。推荐设计以下核心接口：

接口	方法	用途
/health	GET	健康检查
/chat	POST	单轮知识库问答
/upload_doc	POST	上传单篇文档入库
/batch/chat	POST	批量问答任务提交
/batch/status	GET	查询批量任务状态

7.2 curl 调用示例

curl -X POST http://127.0.0.1:8000/chat \ -H "Content-Type: application/json" \ -d '{"query": "UHMWPE 绳索适合海洋环境使用吗？", "top_k": 5}'

返回结构示例（以你自己的接口字段为准）：

{ "reply": "UHMWPE 纤维具有较好的耐海水和耐紫外特性，适合大多数海洋吊装与系泊场景，但长期暴晒仍需要防护措施。", "sources": [ "docs/marine-rope-guideline.pdf#page=4", "docs/uhmwpe-fiber-properties.md#section-2" ] }

7.3 批量任务队列

批量文档解析和批量问答建议分开处理：

• 上传的 PDF/Word 先进入“解析队列”，解析完成后再“切片 + 向量化 + 入库”；
• 批量问答先往任务表插一条记录，业务侧通过任务 ID 轮询结果，避免同步等待导致 HTTP 超时；
• 失败任务要有重试机制，尤其是文档解析阶段：扫描件 OCR 失败、PDF 加密、Excel 内嵌图片都可能导致单条记录失败。

{ "task_id": "c2f8a01e-4b6d-4d3c-9f3a-6f0b1a2c99aa", "status": "pending", "total_jobs": 128, "completed": 42, "failed": 3, "failed_reasons": ["pdf_encrypted", "ocr_timeout", "empty_file"] }

批量任务的关键是“可观测性”：每一条记录都要记录输入文件的哈希、处理状态、耗时、错误原因和输出结果路径。

8. 资源占用与性能观察

真实部署时，不能只看“能不能跑”，还要看资源占用是否稳定。

8.1 显存与内存怎么看

Linux 下用nvidia-smi观察显存，Windows 任务管理器同样能看到显存占用。注意区分：

• 模型加载时的初始显存；
• 对话过程中上下文变长后的显存增量；
• 多个并发请求同时打到推理服务时的显存峰值。

建议先在低并发场景记录一组基线数据，再逐步增加并发。没有统一数字标准，重点观察是否存在持续增长不回落的情况——如果内存只涨不降，多半是会话上下文没有清理，需要检查推理框架的上下文管理配置。

8.2 影响资源占用的核心参数

• 模型参数量与量化精度：7B 量化模型通常比 14B 全精度模型占用低；
• 上下文长度：上下文越长，显存和内存开销越大；
• chunk_size：切片太长会放大检索噪声，太小会丢失上下文，同时也直接影响向量数据库的条目数；
• top_k：检索召回数量越大，prompt 越长，生成开销越高；
• 并发数：推理引擎的并发限制需要显式设置，否则容易 OOM。

8.3 CPU 推理与 GPU 推理的差异

CPU 推理的优势是兼容性广，老办公电脑也能跑，适合内部低频查询。缺点也明显：生成速度慢，批量任务耗时长。GPU 推理适合交互式问答和多人同时使用，响应速度明显更快。建议测试时先用 CPU 跑通逻辑，再上 GPU 做性能优化。

8.4 降低资源占用的通用做法

• 使用 4bit 量化模型；
• 限制max_tokens，答案不需要超长；
• 限制context长度，只让模型看到检索出的片段，而不是全量文档；
• 批量任务设置在业务低谷执行；
• 为推理服务单独设置端口和容器资源上限，防止干扰同机其他服务。

9. 常见问题与排查方法

下面这组问题是我整理通用部署时最常遇到的，覆盖安装、模型加载、检索、API、批量任务几个环节。

问题现象	可能原因	排查方式	解决方案
依赖安装失败	Python 版本过高、依赖冲突	单独建虚拟环境并锁定 Python 版本	用 venv/conda 隔离，逐项安装依赖
模型文件缺失	未下载模型或下载不完整	查看推理引擎日志，确认模型路径	重新拉取模型，校验文件大小和哈希
显存不足导致进程崩溃	模型量级过大，或并发过高	nvidia-smi 观察显存占用	降低参数版本、使用量化模型、限制并发
回答内容有头无尾	服务端生成中断	查看推理服务日志中是否出现 OOM	降低 max_tokens，增加内存/显存限制
检索结果总是答非所问	chunk 切分不合理或 embedding 模型不匹配	打印检索出的 top_k 片段，人工检查	调整 chunk_size、chunk_overlap、换 embedding 模型
API 调用报 timeout	同步请求耗时太长	检查单次推理耗时和批量任务排队情况	改为异步任务，或提高超时时间
“provider rejected the request schema or tool payload”	模型/网关配置了模型不支持的工具调用 schema	查看网关日志，确认请求中的 tools 参数格式	关闭工具调用或改用兼容该模型的 schema
批量任务卡住不动	某个文件解析失败且未跳过	查看任务队列日志，定位失败文件	增加失败跳过与重试机制
端口冲突	端口被其他服务占用	Windows:netstat -ano；Linux:ss -lntp	换端口或杀掉占用进程
输出质量不稳定	检索片段包含冲突信息，或模型温度过高	对比同问题多次回答，检查检索来源	增加引用约束，降低 temperature

特别说下“provider rejected the request schema or tool payload”这一类问题：当你的 RAG 或 Agent 框架在调用本地模型时带上了 function calling 工具描述，而底层模型并不支持这种 schema，网关就会直接拒请求。排查方向不是死磕模型，而是检查提示词或框架里是否默认启用了工具调用，可以在配置里关掉工具调用，或者切换到支持 function calling 的模型版本。

10. 最佳实践与工程化建议

如果要在生产环境稳定跑这个 UHMWPE 绳索知识库，下面这些原则能帮你少走弯路。

10.1 先把最小闭环跑通，再谈优化

第一次做，不要一次性对接 ERP、企业微信、APP。先用最简单的脚本加 API 跑通“文档入库 -> 提问 -> 溯源”。最小闭环能跑，再逐步增加认证、权限、监控、批量任务。

10.2 文档处理追求可复现

• 原始文档、解析后的中间文本、向量库分别存储；
• 入库时记录文档版本和入库时间；
• 文档更新后要能标记旧片段失效，不能只加新数据导致答案新旧冲突。

10.3 设计提示词时明确“不知道”

在系统提示词中加入类似“只能基于提供资料回答；资料未覆盖时，请直接说明未找到”的约束。这对材料行业尤其重要，因为查错一个破断力数据可能导致严重工程问题。

10.4 检索日志是最好的调优依据

记录每次提问的 query、检索 top_k 片段、最终回答、用户是否点击来源、反馈评分。积累几百条日志后，用错误数据分析是 embedding 没选对、切分长度不合适，还是文档本身缺数据。

10.5 权限与合规前置

• 知识库服务部署在内网或私有云，不要默认绑 0.0.0.0 暴露到公网；
• API 层增加访问令牌或账号体系；
• 不同部门文档隔离可通过向量库分区或元数据过滤实现；
• 如果涉及客户数据，入库前先脱敏。

10.6 从 RAG 走向更多能力

2025 年的 LLM 应用已经不是简单问答。RAG 可以继续演进成 GraphRAG，适合处理产品体系、材料关系、零件构成这类多跳关系；也可以接一个 LLM 网关做多模型路由，把不同语义难度的问题分发给不同模型；再往后可以接自动化报告生成，把检索结果直接格式化输出为选型建议书或检测摘要。但每一步扩展的前提都是基础数据质量和检索链路要稳定。

11. 总结与下一步

回到最初的问题：Elven Rope、UHMWPE 和 LLM 能组合出什么？答案是：一套面向高性能材料的智能知识库底座。UHMWPE 的产品文档又专业又分散，RAG 正好能把这些文档变成可查询、可溯源的业务能力。这篇文章里你看到的是本地部署的 LLM 服务、文档切片入库、FastAPI 接口、批量任务日志和无边界合规检查——这套结构不止适用于绳索，任何工业品、材料品类的文档型知识管理都可以照搬。

最先值得验证的功能是“文档溯源问答”。先灌入 20 到 50 篇真实技术文档，挑 30 个高频业务问题跑一遍，重点看回答是否带正确来源，以及模型是否能说“不知道”。最容易踩的坑则是跳过数据清洗直接拉模型搞对话，最后得到一套“看起来流畅但没有依据”的花架子系统。2025 年做 LLM 应用，数据工程和评测闭环比花哨的框架更重要。按本文的顺序：小步跑通、加日志、做评估、再上权限和批量任务，这个知识库就有机会真正变成团队日常依赖的工具。

建议收藏备用，下次拿到一批乱糟糟的技术文档时，可以照这个思路搭一套属于自己的 LLM 知识库。