zed_23

前面三篇分别解决了：是什么、怎么切、怎么找。 今天把它们焊成一个接口：POST /rag/query——问一句设备运维问题，返回有依据的答案。 一、今天要做出什么 返回里至少有： answer：回答正

切片有了，下一步是让计算机「觉得两段话像不像」。 Embedding（嵌入）把文本变成定长浮点向量；向量库负责存和近邻搜索。 一、Embedding 一句话 例子（设备运维场景）： 「单体过压告警怎么

RAG 的第一公里不是向量，是干净的文本。 PDF 抽出来乱码、表格碎成渣、手册切成互不相关的半句话——后面 Embedding 再强也是「垃圾进、垃圾出」。 今天两件事：解析（ingest）和分块（

chat-api 阶段解决的是：会说话的后端。 但一问到「我们手册第几页怎么写的」「这个故障码怎么处置」，通用大模型就容易开始编——它训练语料里未必有你的私有文档。 RAG（Retrieval-Aug

上一篇用 Docker Compose 把整栈拉起来了。你会发现：几乎每条 curl 都带着这一行—— 却很少有人单独讲清楚：这把锁是怎么挂上的？漏带会发生什么？如何用脚本证明「鉴权真的生效」？ ch

到上一篇，你的对话服务已经有了：接口、分层、统一错误、PostgreSQL 历史、Redis 缓存。 但「在我电脑上能跑」和「别人（或未来的你）十分钟能跑」之间，还差一口气。本机装数据库、改端口、环境

大模型按 token 计费。同一个问题被问十次，你就付十次——如果每次都老老实实打到模型。 更现实的场景：演示时反复点同一句、前端重试、用户复制粘贴只多打了两个空格……这些都该命中缓存。 今天目标：用

到现在为止，每次对话都是「问完就忘」。刷新一下、换个客户端，什么都没有。 聊天产品要有历史；排障也要有历史；以后做多轮上下文，更要有历史。 今天目标：用 PostgreSQL 把每次问答落库，并提供

分层之后，下一个痛点很快出现： 成功时你返回： 失败时 FastAPI 默认给你： 参数校验失败又是另一套： 前端要写三套解析；你自己用 curl 排查也难受。更糟的是：有的错误把堆栈、SQL、厂商原