RAG 向量索引算法和向量数据库
向量库解决「百万级语义近邻搜索」，不是简单的 key-value。 Embedding 与检索文本→稠密向量；Query 同空间近邻即语义相似。需同一模型、同一维度。相似度常用 cosine/IP，距离用 L2。 为何专用库高维 ANN（HNSW、IVF）在延迟与 recall 间权衡；需过滤（metadata）、副本、持久化。小数据 Faiss/pgvector 够用；大规模 Milvus/ES 向量场。 索引选择精确 NN 小数据；HNSW 低延迟；IVF 大规模。参数影响 recall 与 build 时间。 误区只向量不做关键词；维度过高未归一化；不设 ef/search 参数调优。 延伸思考pgvector 适合已有 Postgres 团队；Milvus/Qdrant 适合大规模；ES 适合同时要 BM25 的场景。HNSW 参数 M、efConstruction 影响 build 时间与 recall。过滤查询（tenant_id、acl）应在 ANN 前或与支持 metadata filter 的引擎结合。冷热分...
RAG 知识库文档如何更新：增量更新、版本控制、去重与全量重建
知识库不是一次索引就结束，更新策略决定答案是否过时。 核心问题新增/修改/删除如何同步；embedding 模型变更需全量重嵌；版本与 doc_id 一致性；去重防重复 chunk。 元数据设计doc_id、version、hash、updated_at、source、acl。修改：删旧 vector + 写新。删除：软删标记 + 过滤。 增量 vs 全量增量适合日常；全量适合模型切换、索引 corruption、大规模重构。定时对账校验 count/hash。 误区只 append 不删改；换 embedding 模型不重建；无版本导致旧新片段同时召回矛盾。 延伸思考增量 pipeline 可监听对象存储事件或 CMS webhook，消息体带 doc version。embedding 模型升级时，计划维护窗口跑全量 re-embed，双写索引后切换 alias。去重用 content hash，同 hash 跳过。删除要传播到向量库与 BM25 索引。对账任务每日比较源系统文档数与索引条目数。灾难恢复保留快照与重建脚本，避免单点索引损坏无退...
RAG 文档处理与切分策略：从解析、清洗、Chunking 到多模态内容处理
上传前半段决定 RAG 上限——Garbage In, Garbage Out。 处理链路格式解析（PDF/HTML/Office）→ 去噪 → 结构识别（标题/table）→ Chunk → 元数据（来源、页码、ACL）→ Embedding。 Chunk 策略固定长度简单但断语义；递归字符保段落；语义切分贵；按标题/结构切边界清晰；Parent-Child 小 chunk 召回、大 parent 生成。重叠缓解边界截断。 多模态图/表需 OCR 或专用模型；表格转 Markdown 保结构。代码库按函数/类切分。 误区不清洗 HTML 噪声；统一 chunk size；无元数据无法过滤与溯源。 延伸思考PDF 解析优先保结构：标题层级、列表、表格单元格边界。代码文档按函数切分并保留 import 上下文。FAQ 可整段为 chunk。重叠 size 通常 10%-20% chunk length。Metadata 至少含 source_id、page、section、acl、lang、updated_at，供过滤...
RAG 基础概念：检索、生成与工程取舍
RAG 在检索与生成之间架桥，解决时效、私有数据与幻觉三难题（非零幻觉）。 工作原理离线索引六步：摄入、清洗、元数据、Chunk、Embedding、入库。在线：Query 向量化 → 相似检索 → 上下文增强 → 生成 + 引用。 为何需要预训练知识过期；企业数据不可外泄；生成需证据降低胡编。但仍可能检索错、引用错、模型不跟指令。 与搜索对比找文档用搜索；读文档答问题用 RAG。很多企业双入口并存。RAG 延迟与成本更高，需评测与 ACL。 误区RAG 消灭幻觉；Chunk 越大越好；不做混合检索与重排。 延伸思考Embedding 模型选择看语种、领域、维度与推理成本；查询与文档应同一模型。相似度 metric 要与索引实现一致（cosine/L2/IP）。与微调对比：RAG 适合知识频繁变、需 citation；微调适合风格/格式固定、知识相对稳定。长上下文可补 RAG 但无法替代权限与溯源。生产 RAG 必做：低分拒答、引用片段展示、用户反馈回流索引。 实践小结练习：手工走一遍索引+查询，打印 top5 chunk 与最终答案，检查 gr...
RAG 专题：文档处理、向量数据库、GraphRAG、检索优化与知识库更新
RAG 专题解决「让模型基于可更新、可溯源的企业知识回答」的问题。 链路总览解析 → 清洗 → Chunk → Embedding → 索引 → 查询改写 → 召回 → 重排 → 生成 → 引用。任一环节弱则整体「答非所问」。 子专题文档处理定上限；向量库定规模与延迟；优化定召回率；GraphRAG 补关系；更新保时效。与 LLM 评测、权限设计联动。 实践顺序rag-basis → document-processing → vector-store → optimization → knowledge-update → graphrag。 误区只买向量库不做 Chunk 评测；无权限过滤；忽视 embedding 模型版本锁定。 延伸思考企业 RAG 项目常见里程碑：M1 单库 FAQ、M2 混合检索+重排、M3 权限与更新、M4 评测闭环、M5 Graph/Agent 扩展。每阶段定义可量化指标，如 Recall@5、人工评分>=4 的比例。文档处理与向量库选型往往被低估工期——扫描件 PDF、表格、多语言混合是常态。专题学习后应能独立设计索引...
大模型结构化输出：从 JSON 契约到 Function Calling 落地
「请返回 JSON」不是工程方案，契约必须在生成与解析两侧 enforce。 三层约束JSON Mode 保语法；JSON Schema 定字段；Structured Outputs 在生成期约束。仍建议服务端 parse + 校验 + 重试。 Function Calling模型输出 tool name + arguments；业务侧执行并回传。与 MCP 配合：FC 是意图，MCP 是通道。工具描述要准，减少错选。 安全分层只读查询 / 写操作 / 高危操作分级；参数白名单；人工确认；沙箱执行。记录每次 tool call 审计。 误区解析失败直接 500；工具权限过大；Schema 过复杂模型填不对。 延伸思考JSON 漂移表现：多余 markdown 围栏、中文标点、缺字段、类型错（字符串数字）。工程契约应在服务端定义 Pydantic/Zod 模型，失败时带错误信息重试一次，仍失败则降级模板或人工。Function Calling 工具描述要含「何时不要用」。并行 tool call 需考虑依赖关系与事务性。安全上，读库与写库工具分离；...
AI 应用评测体系：从 Golden Set 构建到线上灰度闭环
没有评测的 AI 功能只能叫实验，不能叫产品。 为何自建 Golden Set公开 benchmark 与业务分布脱节；需要覆盖权限、拒答、工具、多轮、边界输入。每条 case：输入、期望行为、评分 rubric、标签分层。 构建方法从日志采样 + 人工标注 Badcase；合成数据补长尾；分层（核心/扩展/对抗）。100–300 条核心集可启动迭代；持续增补。 闭环离线回归 → 预发 shadow → 灰度指标（准确率、引用率、人工接管）→ 全量。版本绑定 Prompt、检索索引、模型 id。 误区只看 BLEU/ROUGE；无对抗用例；Golden Set 不维护导致腐化。 延伸思考Golden case 字段可含：input、expected_tools、expected_citations、forbidden_content、difficulty tag。扩展覆盖可用 mutation：改写法、加噪声、换语言、注入恶意片段。分层时核心集挡回归，扩展集测泛化，对抗集测安全。线上灰度看：answer grounded rate、用户 thum...
大模型 API 调用工程实践：流式输出、重试、限流与结构化返回
生产级 LLM 调用是分布式系统工程，不是单次 HTTP POST。 调用阶段鉴权 → 路由 → 组装 Prompt → 请求模型 → 流式/同步消费 → 校验 → 持久化 → 计费埋点。每阶段需超时与可观测。 流式选型SSE 简单、单向，适合 Chat；WebSocket 双向，适合语音/协作；chunked HTTP 兼容性好。注意 Nginx 缓冲关闭、代理超时、客户端断连取消。 可靠性幂等 Key 防重复扣费；指数退避重试；熔断与 fallback 模型。流式异常：断连、TTFT 超时、中途错误帧。 误区默认缓冲导致「假流式」；无 cancel 泄漏资源；结构化输出不校验就入库。 延伸思考Spring AI 等框架封装了 ChatClient，但生产仍需自管：连接池、超时、断路器、bulkhead。流式场景在模型输出 Markdown 代码块时，注意 SSE 事件边界解析，避免半行 JSON 被截断。重试仅对 idempotent 读操作或带幂等键的写操作；对「已扣费但客户端超时」要有对账任务。限流按 tenant+model 维度，防止单客户拖垮...
LLM 运行机制：Token、上下文窗口与采样参数怎么影响输出
Token 与窗口不是抽象概念，它们直接决定账单与回答质量。 Token 与窗口文本切分为 Token；上下文窗口是单次可见上限。多模态输入（图/音）也占 Token。溢出时尾部或中间截断，系统指令可能被挤掉。 采样参数temperature 越高越发散；top_p 核采样；max_tokens 限制输出。确定性任务低温；创意任务略升温。同一 Prompt 不同参数可 A/B。 成本预算输入通常比输出便宜；长上下文模型单价更高。Prompt Cache 对重复前缀省钱。预算公式：系统+检索+历史+输出 reserve。 误区窗口拉满；忽视截断策略；无 max_tokens 导致账单失控。 延伸思考多模态计费常让人低估：一张高分辨率图可能等价数千 text token。窗口管理上，系统指令应模板化且可缓存；历史对话可 rolling summary；RAG 片段按相关性截断。Prompt Cache 适合固定前缀（系统+工具 schema），变动部分放后缀。预算公式实践：reserve 20% 给 output，检索不超过 40%，历史不超过 30%，其余给...
大模型基础专题：运行机制、API 调用、结构化输出与评测
大模型基础是 AI 应用的「操作系统层」——不懂机制就容易在成本与安全上踩坑。 专题范围运行机制（Token、窗口、采样）；API 工程（流式、重试、限流）；结构化输出与 Function Calling；评测体系（Golden Set、灰度）。 学习顺序先机制后 API；先同步后流式；先 JSON 契约后工具调用；先离线评测后线上监控。与 Agent/RAG 专题交叉阅读。 实践建议用同一套小任务对比不同 temperature 与 max_tokens；压测流式 TTFT；建立 50 条 Golden Case。 误区跳过机制直接调 SDK；不做结构化校验；无成本监控。 延伸思考动手实验建议：同一问题扫 temperature 0~1 观察稳定性；对比 stream vs 非 stream 的 TTFT；用 invalid schema 测试重试逻辑。Structured output 与 FC 应在小项目里串起来：模型输出 JSON→校验→调 HTTP 工具→结果回写。评测从 30 条核心 case 起步，覆盖拒答、工具、格式、安全。专题读完应能画出「一次生产...