RAG 是什么RAG全称 Retrieval-Augmented Generation检索增强生成。先查询最新的知识如果有合适就基于这些知识回答如果没有再用历史的知识回答RAG 的思路是用户提问的时候先去知识库里捞几条相关文档把这些文档和问题一起拼进 prompt再让 LLM 基于这些事实来回答。相当于给LLM配置了一个内部资料包先看代码结构代码blog/code/├── main.py # 主流程分词检索 prompt 拼装 LLM 调用└── knowledge_base.py # 知识库存放运维文档knowledge_base.py这个文件很简单就是一个 Python 列表每个元素是一条运维文档包含 title 和 content 两个字段docs [{“title”: “Nginx 504 排查手册”,“content”: “Nginx 504 通常表示网关等待上游服务响应超时需要检查 upstream 服务耗时、业务服务日志、数据库慢查询和连接池。”},{“title”: “订单服务历史故障”,“content”: “订单服务曾经因为数据库连接池耗尽导致 /api/orders 接口大量超时最终在 Nginx 中表现为 504。”},# …]在真实生产里这里可以换成从 Confluence、内部 Wiki、Elasticsearch 里拉取的文档甚至是历史故障复盘记录。这个 Demo 用硬编码列表是为了让整个流程零依赖、能直接跑。main.py_tokenize 函数负责把文本拆成 tokendef _tokenize(text: str):text text.lower()tokens re.findall(r[a-z0-9]“, text) # 英文/数字按词切分chinese_parts re.findall(r”[\u4e00-\u9fff], text)for part in chinese_parts:if len(part) 1:tokens.append(part)else:tokens.extend(part[i:i 2] for i in range(len(part) - 1)) # 中文按 2 字片段切return set(tokens)retrieve 函数用关键词命中次数给文档打分取 top_k用集合求交集来算相关度简单粗暴但在小型知识库里够用def retrieve(query: str, top_k: int 2):query_tokens _tokenize(query)results []for doc in docs:text doc[“title”] doc[“content”]doc_tokens _tokenize(text)score len(query_tokens doc_tokens) # 交集大小 相关度if score 0:results.append({…})results.sort(keylambda x: x[“score”], reverseTrue)return results[:top_k]整条 RAG 链路在 main 里串起来用户问题↓retrieve() ← 关键词检索拿 top_k 文档↓build_prompt() ← 把文档 问题拼成 prompt↓call_llm() ← 发给 LLM拿回答↓打印结果以 “订单服务出现大量 504应该怎么排查” 为例跑一遍控制台输出大致如下 检索到的文档 Nginx 504 排查手册score4订单服务历史故障score3 构造出来的 Prompt 你是一个 Kubernetes 运维分析 Agent。…文档标题Nginx 504 排查手册文档内容Nginx 504 通常表示…文档标题订单服务历史故障文档内容订单服务曾经因为数据库连接池耗尽…… LLM 最终回答 根据知识库建议优先排查以下几点检查订单服务数据库连接池是否耗尽历史上曾出现此问题查看 Nginx upstream 日志确认超时节点确认 Pod 实例数和 CPU/内存状态…LLM 的回答里会引用到历史上连接池耗尽这条这就是 RAG 发挥作用的地方——纯靠通用知识是不会提这条的如果匹配的文档有5000字那全部都要塞给llm吗假设有 100 个故障案例文档每个文档 5000 字那就是50w字的全部发给llm不但提高了回答成本回答速度也会大大降低造成了大量浪费如果内容太长放进大模型上下文会浪费 token。并且里面主题太杂内容检索可能不知道这篇文档到底主要讲什么所以文档选取的时候一般选取最相关的top5并且文档需要拆分成更小的chunk类似这种标题订单服务大量 504现象Nginx 出现大量 504upstream_response_time 超过 60sPod CPU/内存正常Redis、MySQL、Kafka 连接正常排查过程查询 Nginx 日志确认是 upstream timeout查询业务日志发现调用三方接口耗时异常查询 PrometheusPod 资源无明显瓶颈查询链路追踪确认耗时集中在 external-api span根因三方接口响应慢导致业务线程阻塞Nginx 等待超时。处理临时调大线程池降级三方接口增加超时控制增加熔断策略关键词504, upstream timeout, external api, thread blocked, nginx这已经是一个完整知识单元现象 → 排查过程 → 根因 → 处理方案chunk和文档有什么关系简单来说完整的文档就相当于一本书一个chunk就是某页或者某一小节查资料时只摘抄相关小节而不是读完整本书和 RAG 用 chunk 逻辑完全一致chunk向量化原始文档切割后的成为不同的chunk通过embedding 模型转换成一段向量而提出的问题也会被转换成一段向量用户问题向量和所有 chunk 向量看哪个最相似最终返回最相似的几个 chunk提交给llm例如chunk订单服务大量 504Pod 正常Redis MySQL 正常最终是三方接口慢导致线程阻塞转换成向量[0.012, -0.233, 0.891, 0.056, …]用户问题订单接口大量 504但是 Pod 和数据库都正常怎么排查也转换成向量[ 0.021564, -0.156489, 0.089451, …]然后向量库会比较两者的向量看哪个最相似返回相似的chunk提交给llm总结一个最简 RAG 只需要三件事知识库、检索函数、拼 prompt 的逻辑RAG 的本质不是让 LLM 变聪明而是内部资料及时喂给它让它回答的更切近内部服务的内容而不是通用的内容RAG需要在海量的文档中搜索出最佳匹配的chunk来给llm提供依据回答问题联系我