工程实践 TiDB 社区博客 - 实践案例 2026/09/18
文章整理山东腾安信息的 TiDB 实践：政务协同、烟草数据中台、企业知识库、异构迁移和数据库安全五类场景共用一套数据库底座。做法包括将 12 套政务系统收敛为两个隔离集群，用 RU 配额与优先级做多租户调度；烟草中台以 TiKV 行存和 TiFlash 列存同时支撑交易与分析；知识库把 SQL 权限过滤与 HNSW 向量检索结合在同一份数据上。迁移侧用 TiDTS 编排全量与增量同步，安全侧用 DBNginx 将连接入口变为访问治理入口，结论是共性数据能力应下沉为可调度、可分析、可迁移和可治理的基础设施。不足是文章为厂商实践分享，缺少性能、成本、故障和量化收益对比，方案有效性需结合自身规模验证。
推荐收录。文章给出了多系统收敛为两个集群、HTAP 行存列存协同、SQL 权限过滤与 HNSW 向量检索结合、TiDTS 迁移编排和 DBNginx 访问治理等具体证据，适合数据库平台、数据中台和安全治理工程师参考。其可迁移价值在于把重复建设问题拆成资源调度、分析、检索、迁移与安全等可治理能力；风险是厂商视角明显，缺少量化收益与失败边界，选型时仍需独立验证。
技术文章 TiDB 社区博客 - 技术解读 2026/09/18
文章系统介绍 TiDB 的向量搜索能力与 AI 集成实践：先说明向量搜索与 Embedding 的基本原理，再讲解 TiDB 原生 VECTOR 数据类型、向量写入方式、VEC_COSINE_DISTANCE/VEC_L2_DISTANCE 等距离函数，以及 HNSW 向量索引的参数含义。随后给出构建 RAG 知识库问答的完整架构与 Python 代码，演示与 OpenAI Embedding、LangChain、LlamaIndex 的集成思路，并讨论索引构建时机、HNSW_EF_SEARCH 调参和向量维度取舍等性能优化要点。核心结论是 TiDB 可在同一条 SQL 中结合向量检索与结构化过滤，避免维护两套系统。不足在于部分代码为占位或有误（如框架集成示例将查询向量写成空数组），且向量索引依赖 TiFlash，社区版暂不支持 SQL 建索引，整体偏入门教程。
收录理由是文章把 TiDB 原生 VECTOR 类型、HNSW 索引与“向量+结构化条件”混合搜索放在同一 SQL 中讲解，并配有 RAG 知识库与 LangChain/LlamaIndex 集成示例，对希望在现有关系库上落地向量检索的开发者有可迁移价值。需注意部分示例代码为占位或含错误、索引依赖 TiFlash，读者应结合官方文档验证后再用于生产环境。
技术文章 知乎 - 腾讯技术工程 2026/09/15
文章系统梳理了 Prompt Engineering → ReAct → Context Engineering 的演进，指出前两者分别优化单次调用和工具行动逻辑，但未解决长任务中的上下文膨胀与信息管理问题。其核心论点是：上下文窗口是稀缺资源，应遵循“最小 Token 数 × 最高信噪比”原则主动策展信息，并援引 Lost in the Middle、Context Rot、Attention Budget 三项实证约束论证信息堆砌有害。作者将上下文拆为七类要素，给出 Context Compaction、Structured Note-Taking、Sub-Agent 三大长任务技术，并覆盖 JIT 检索、工具设计、反模式和代码示例。文章还映射到 Harness Engineering，并讨论大窗口不会淘汰 Context Engineering 的边界；示例代码为简化实现，部分数据为估算，但整体框架清晰，具有工程参考价值。
推荐收录：文章以 Anthropic 官方文档和 Lost in the Middle 等实证研究为依据，系统阐述了 Context Engineering 的演进、七类要素和长任务技术，并配有可运行的代码示例与反模式清单。对构建生产级 Agent、AI Coding 工具或长任务系统的工程师，文中关于上下文压缩、外部笔记、子 Agent 隔离和 JIT 检索的工程原则可直接迁移；局限是数据多为估算、代码为简化实现，需结合真实系统验证。
技术文章 ClickHouse Engineering 2026/09/11
本文介绍 ClickHouse 内置的 AI Functions 家族，让 SQL 引擎可直接调用 LLM 或 embedding 提供方，把模型调用变成类似 sum() 的普通函数，核心思路是"把模型搬到数据旁"而非把数据搬到模型。文本函数涵盖 aiClassify、aiExtract、aiGenerate、aiTranslate、aiFilter、aiRedact，向量函数涵盖 aiEmbed 与 aiSimilarity，通过 named collection 配置 OpenAI 兼容端点即可使用。作者用 Hacker News 数据集演示分类、过滤、摘要、翻译以及完整 RAG 循环（写入时嵌入、向量索引、cosineDistance 检索、生成答案）。文中还详述会话级配额设置（输入/输出 token、API 调用数、超限报错或软停），并说明 token 计数依赖 provider 上报 usage、重试计入调用配额、分布式查询在各分片独立计数。最后提醒 prompt injection、非确定性、成本随行数放大及 remote_url_allow_hosts 等上线注意事项。
推荐收录。文章并非纯功能公告，而是给出了 SQL 原生调用 LLM 的完整用法与边界：named collection 配置、库内 RAG 循环步骤、配额设置的精确语义（token 依赖 provider 上报、重试计入配额、软停产生默认值行），以及 prompt injection、非确定性和成本随行数放大的生产风险。适合在数仓内构建 AI 应用或做推理成本治理的工程师参考。
工程实践 Salesforce Engineering 2026/09/09
文章复盘Salesforce企业级RAG应用：标准文本基准准确率超90%，但在复杂企业文档上仅约46%。作者主张从错误答案反向排查解析、分块、富化、嵌入、检索与生成链路，并一次只改一个阶段来定位失败。改进包括按页复杂度路由的智能解析、保留语义边界的结构化分块、元数据与问题表示富化、SFR Embedding v3扩展上下文、动态元数据预过滤及GraphRAG多跳检索。分阶段基准从65.1%升至84.4%和86.8%，整体企业文档准确率超过90%；JIT索引把30分钟以上等待降至7-10分钟。局限是内容来自厂商博客，GraphRAG尚未正式可用，基准与产品能力难以独立复现。
推荐收录：文章给出了可操作的RAG准确率诊断路径，并用分阶段基准展示65.1%→84.4%→86.8%及46%→90%+的归因式改进，而非泛泛讨论提示词或换模型。它适合正在构建企业知识库、文档问答和检索系统的工程团队，智能解析、语义分块、元数据预过滤与单变量评估方法可直接迁移。需注意其来源为厂商工程博客且GraphRAG尚未正式可用，部分产品指标需结合自有语料验证。
工程实践 知乎 - 携程技术 2026/09/04
携程机票团队针对开发中信息分散、文档滞后和代码改动影响难追踪的问题，提出“代码即文档”理念并落地 Lumos 平台。系统通过 CI/CD 流水线在合并请求时触发 Dify 工作流，自动提取需求描述、梳理开发逻辑、生成代码分析文档，并以 Markdown 形式存入向量知识库；同时接入智能问答机器人和代码改动影响追踪，结合性能指标与代码质量静态分析生成多维度评估报告。平台已接入 74 个业务仓库，覆盖 7 个事业群，累计生成超千篇文档，人力维护时间下降 80% 以上。文章用真实案例展示了从知识获取到自动化的完整链路，但内容偏重前端场景，且对生成的业务文档准确率、评测反馈闭环等仍处于探索阶段，尚未给出系统性的效果验证。
文章提供了完整的工程背景、问题定义、系统架构、关键实现路径和量化效果（74 个仓库、文档维护时间下降 80%），是 AI 辅助研发效能建设的一线实践而非概念宣传。适合负责研发效能、工程效率或知识管理的团队借鉴，其‘CI/CD 触发文档自动生成 + 向量知识库 + 智能问答’的管线具有较强的可迁移性，但需要结合自身代码库规模与文档质量要求评估效果。
工程实践 Meta Engineering 2026/09/02
本文由 Meta 工程团队分享，介绍他们为组织级专家知识构建的一个 AI 代理系统，使其成为可长期积累的“组织第二大脑”。系统核心由两层组成：一是结构化的、可审计的知识架构，将专家知识预先蒸馏为带依赖图的文本文件（如立场文件、路由索引、网关门），并区分高密度、高频知识放于精编知识库，稀疏、低频知识通过 RAG 检索补充；二是可组合的“食谱”（recipes）程序化推理层，将分析流程拆解为多阶段步骤，实现“知道什么”与“如何推理”的分离。此外，系统还包含一个自我改进飞轮：专家反馈经历诊断、编译、验证、落地四阶段，自动生成最小化且经回归测试的文件编辑，无需重训模型。文中报告六周后专家评估输出几乎总是有用，单次评估时间从数天降至分钟，且零回归。该架构适用于合规、安全审查、金融风险等需要机构性专业知识的领域，但前提是具备可编辑的知识文件、程序化流程、自动化评测和人工监督。
推荐收录。文章给出了一个可落地的企业级 AI 代理设计范式，重点展示了知识架构与推理层分离、基于依赖图的文本知识库、以及专家反馈自动转化为经过验证的文件编辑等完整的工程循环。直接证据包括 Meta 实际部署后的量化结果（数天到分钟、零回归）和领域无关的适用条件。适合从事 LLM 应用、AI Agent、知识工程或企业级 AI 平台的工程师参考，其“以文本文件为持久化知识并用自动化编译维护”的思想具有很高可迁移价值，但需注意其依赖严格的人工审核与评估基础设施，复制成本不低。
工程实践 Salesforce Engineering 2026/08/31
文章剖析了RAG系统“事实正确但答案错误”的根因：关键事实分散在目录、wiki和CRM等不同来源，向量检索命中相关片段却漏掉跨文档的中间关系，即“扁平文本块”问题。作者介绍Agentforce的GraphRAG实践：把实体关系抽成知识图谱，用多跳检索沿关系获取分类、规则、会员等级等必要条件；通过TBox/ABox分离图谱蓝图与实例，由业务人员校验蓝图，并用显式指针连接结构化记录。文末给出诊断清单：分别核查检索上下文、图谱是否遗漏业务规则、记录连接是否存在。作者强调这些是诊断示例而非基准测试结果，图谱本身遗漏条件时检索无法弥补。
本文以具体业务场景为线索，把抽象的多跳检索问题拆解为可检查的故障点，并提供TBox/ABox和显式指针等可操作做法，对构建RAG、Agent或知识图谱系统的工程师有直接参考价值。适合在检索效果不佳时作为定位思路，也可用于设计新的企业级问答或决策系统。
工程实践 SelectDB 技术分享
文章针对大模型应用中专用向量库成本高、混合查询难的问题，深入剖析 Apache Doris 4.1 原生向量检索的工程设计。作者先比较专用向量数据库、关系型数据库扩展和分析型数据库原生支持三条路径，论证原生集成路线的优势。随后详细阐述 IVF 索引降低内存、IVF_ON_DISK 冷热分层、SQ/PQ 量化压缩以及 ANN Index Only Scan 优化查询性能的具体实现和 DDL 示例。文章还演示了结构化过滤联合查询与基于 RRF 的多路召回融合在 SQL 中的落地方式，并给出 VectorDBBench 基准数据。测试表明该方案在 100 万 768 维向量上取得 900 QPS、97% 召回率，构建速度最快，形成成本与性能的均衡。不过文中基准硬件规格不一，实际部署需根据工作负载进行验证。
推荐收录，因为文章不是简单的功能罗列，而是系统拆解了 Doris 4.1 向量检索的工程实现，包括 IVF 降本、磁盘索引、量化压缩、Index Only Scan 等关键设计，并提供了混合检索的 SQL 实现和基准数据。适合数据库内核、AI 基础设施和 RAG 系统开发者参考，其存储分层、覆盖索引和融合排序思路可迁移到其他 OLAP 或向量检索场景。需注意部分内容来自厂商，基准配置存在差异，应结合自身负载验证。
工程实践 知乎 - SmartCode 得物技术 2026/08/13
文章系统介绍得物知识问答产品的复合检索 Agent 设计实践。作者基于 AgentScope 2.0 HarnessAgent，利用 ReAct 循环、Middleware 和并行工具调用，构建多源并行检索流程，融合企业知识库与个人飞书文档、消息、妙记数据，并通过权限注入实现数据隔离。检索质量上，采用查询扩展生成自然语言变体，并设计 FastPass、Reranker、LLM Grading 三阶段过滤 Pipeline，解决向量相似不等于语义相关的问题。系统还支持图片多模态输入、自动模型切换，以及多实例 SSE 断点续传和模型容灾，提升生产可靠性。文章最后总结六个创新点，并展望精细化检索策略和个人知识助手方向；当前方案依赖企业内部知识管理平台和飞书生态，长期记忆能力尚未启用。
推荐收录，因为文章并非泛泛介绍 RAG 套壳，而是给出了基于 AgentScope 的自主决策检索系统完整工程方案，包含多源并行检索、三阶段质量过滤、多模态输入和生产级 SSE 断点续传等关键设计，并附有代码片段和评测结果。对正在构建企业知识问答、Agent 检索或 RAG 工程化系统的读者，文中关于关注点分离、权限隔离和断点续传架构取舍的做法可迁移，但需注意其对 AgentScope 和飞书生态的依赖。
技术文章 TiDB 社区博客 - 技术解读 2026/08/12
文章系统讨论 AI Agent 的记忆体系，借鉴认知科学将记忆分为短期、语义和情景三层，并补充全文检索记忆需求。作者批评用 Redis、MySQL、向量库和 Elasticsearch 拼接的方案存在数据一致性、混合查询困难和运维复杂等痛点，提出应在同一数据库内核中原生融合关系、向量和全文检索能力。文章以 TiDB 8.5 为例，展示通过 VECTOR 列、向量索引和全文索引在单条 SQL 中组合结构化过滤、语义检索和关键词匹配的实现方式，并说明平凯云服务的 Serverless 弹性、HTAP 能力和全球部署优势。文章适合关注 Agent 记忆系统、RAG 或数据库选型的开发者，但需注意其官方博客的产品宣传色彩和方案边界。
推荐收录。文章不仅解释了 Agent 记忆的分类和需求，还具体分析了多系统拼接架构的工程痛点，并给出使用 TiDB 原生融合关系、向量和全文检索的 SQL 示例，证据具体、有可操作价值。适合构建有状态 AI Agent、RAG 应用或需要混合检索能力的开发者参考，可迁移架构思路，但需注意其中隐含的厂商推广和 TiDB 特定实现约束。
技术文章 知乎 - SmartCode 得物技术 2026/07/23
文章系统梳理了RAG（检索增强生成）的核心检索技术链路，从LLM的局限性引出RAG的必要性，依次阐述了文档切分策略（Chunking）、文本向量化（Embedding）的原理与对比学习训练方式、向量相似度度量（以余弦相似度为主）、以及近似最近邻搜索算法HNSW的分层图设计与贪心搜索机制。在此基础上，完整介绍了查询改写、元数据过滤、多路召回（ANN+BM25）、RRF排名融合与Cross-Encoder重排序（Rerank）的协同工作流程，并强调了混合检索与各环节工程取舍的重要性。全文提供了具体的参数选择、算法复杂度和实践建议，适合构建高质量RAG系统的开发者参考。边界：未涉及具体模型微调与超大规模部署，但覆盖了核心概念与实用策略。
本文深入浅出地讲解了RAG检索系统的核心原理与工程考量，从Embedding到HNSW再到混合检索，每一环节均有理论解释和实际示例，避免空泛介绍。适合AI工程师、后端开发者以及希望优化检索效果的技术人员。文中关于Chunking策略、HNSW参数调优、多路召回融合等可迁移经验具有较高的实践指导价值，因此推荐收录。
科研议题 Microsoft Research Blog 2026/06/29
文章介绍了微软研究院提出的 Memora，一种面向长程 AI agent 的记忆框架，核心目标是同时保留细节与可检索性。作者指出，现有方案要么把对话切成碎片化事实，要么压缩成过度粗糙的摘要，都会在“抽象性”和“具体性”之间丢失一端。Memora 通过将“存什么”和“怎么取”解耦：用 primary abstraction 作为检索锚点、用 memory value 保存丰富内容，再借助 cue anchors 提供多路径召回，并配合 policy-guided retriever 做迭代式检索与多跳推理。在 LoCoMo 和 LongMemEval 上，它分别取得 86.3% 和 87.4% 的 LLM-judge 准确率，并相对全上下文推理最多减少 98% token 消耗。文章适合作为理解长时记忆、agent 记忆架构和检索策略设计的研究案例，但结论主要来自长对话基准，真实业务中的稳定性、更新策略和跨域泛化仍需进一步验证。
推荐收录，因为文章明确给出了可复用的记忆架构：将内容存储与检索机制解耦、用 primary abstraction 与 cue anchors 组织记忆，并用迭代式策略检索支持多跳召回。它对长上下文 agent、记忆系统和检索式 AI 工程都有直接参考价值，但读者也应注意其效果主要建立在长对话基准上。
工程实践 知乎 - 阿里巴巴大淘宝技术 2026/06/24
这篇文章系统梳理了 RAG 在 Agent 场景中的全链路工程实践，覆盖文档加载、智能切分、向量索引、检索优化、生成调优、Graph RAG 和自动化评测等关键环节。文章不仅解释了各环节的核心原理，还结合 Query 改写、HyDE、Doc2Query、重排序、Ragas 指标与测试集生成等方法，强调通过“可测、可调、可信赖”的闭环提升 RAG 的业务确定性与降低幻觉。适用边界也较清晰：它更偏向工程落地与系统方法论，而非单点算法创新。
推荐收录，因为它不是泛泛介绍 RAG 概念，而是把知识库构建、召回、生成和评测串成了完整的方法链，具有很强的工程参考价值。对于正在做 Agent、企业知识问答或检索增强系统的团队，这篇文章能直接迁移到方案设计、问题定位和效果评估中。
工程实践 知乎 - 千问云 2026/06/24
文章围绕工程知识库在检索、组织和同步上的结构性瓶颈展开，系统比较了 Naive RAG、LLM Wiki、Graphify 和 GraphRAG 四种范式，并指出单纯向量检索容易出现“每次从零推导”“无法连点成线”“粒度混乱”等问题。作者进一步提出“金字塔”式知识库方案：按原则、架构、规范、实现、经验五层组织知识，用图谱关系和角色感知路由来提升上下文选择质量，并给出增量同步、审计机制和一组小规模评测结果。
推荐收录，因为这篇文章不是泛泛谈 RAG，而是围绕工程知识库的结构化组织、检索路由、同步更新和评测方法给出了一套可落地的设计框架。它对正在构建 AI 知识库、内部文档问答或 Agent-native context layer 的读者具有较强的迁移价值。
工程实践 Elastic Security Labs 2026/06/23
文章介绍了 Elastic 安全团队如何用 Elastic Agent Builder 搭建一个生成式 AI 代理，把原始漏洞报告自动整理成可审阅的 CVE 安全公告草稿。系统通过 RAG 将 MITRE 的 CWE 与 CAPEC 目录抓取并索引到 Elasticsearch 中，再结合产品文档、代码检索和一套严格的提示词约束，完成弱点分类、攻击方法选择、CVSS 草案评分和缓解建议生成，同时避免 LLM 幻觉和过度披露实现细节。文中还详细说明了爬虫配置、工具调用顺序、内存安全语言的分类禁忌、CAPEC 只能表示方法而非影响、以及人类审阅如何把关最终发布，体现出适合落地到安全公告、合规文档和其他结构化写作任务的通用模式。
推荐收录，因为它不是泛泛而谈“用 AI 提效”，而是给出了从权威数据抓取、检索增强、提示词护栏到人工审核的完整工程链路，具有很强的可迁移价值。对做安全运营、知识库自动化、结构化文档生成或企业内 LLM 落地的读者，这篇文章提供了可直接借鉴的系统设计与风险控制方法。
工程实践 知乎 - SmartCode 得物技术 2026/06/11
文章介绍了一个为 Claude Code 增加“长期记忆”和“自我进化”能力的工程系统，核心由行为观测、模式提炼和记忆注入三层组成。作者通过 Hook 机制稳定采集工具调用日志，再用统计规则与模型语义分析提炼 Instinct，并结合本地 Embedding 和向量检索把项目记忆在新会话中自动注入，从而让助手跨会话保持上下文、逐步修正行为。文章还给出了数据分片、置信度衰减、去重聚合、隐私边界和效果量化等设计，说明这套方案适合需要频繁与 AI 编程助手协作的个人或团队，但更适合作为定制化工程实践而非通用产品方案。
推荐收录，因为它不是泛泛讨论“AI 记忆”的概念，而是给出了可落地的 Claude Code 工程实现：从 Hook 采集、规则提炼、向量召回到上下文注入，链路完整且有真实运行数据。对想要改造 AI 编程助手、构建个性化工作流或理解 agent 记忆系统边界的读者，都有较强的迁移价值。
工程实践 Spotify Engineering 2026/06/10
文章介绍 Spotify 内部 AI 数据助手 Vedder 背后的上下文层设计。面对 7 万多个数据集和海量数据，作者指出仅把 schema 塞进 LLM 并不可行：上下文窗口有限，且 schema 无法传达业务语义。为此他们提出“集群”模型，由领域专家维护三类上下文——带抽样与分区信息的数据集、经审核的问题-SQL 样例对、补充业务文档，并以 ReAct 循环生成可追溯的查询与来源。实验证明了人工审核的必要性：从查询历史自动生成的样例对仅 12.5% 被专家接受，其余多为探索、调试或错误模式。系统还通过集群健康分与反馈闭环持续维护上下文。该架构不依赖 Spotify 特有设施，但前提是已有成熟的数据目录与治理。
推荐收录。文章提供了完整的工程分析与可量化证据：自动生成样例对仅 12.5% 被专家采纳、集群健康分指标体系和反馈闭环，清楚说明在超大规模数据仓库上为何必须由领域专家审核上下文，而非依赖原始查询历史。适合构建 LLM 数据分析助手、上下文/RAG 层或数据平台工程化的读者参考。
工程实践 知乎 - 腾讯技术工程 2026/06/02
这篇文章系统拆解了 Chromium 在 AI Coding 上的整体工程体系，重点分析了 AI Policy、分层 Prompts、按需激活的 Skills、Agentic RAG 知识库、Eval 评估套件以及面向大规模改造的 Projects 六个部分。作者不仅展示了目录结构与关键文件，还解释了这些机制如何共同约束 AI 生成代码、减少幻觉、保证可测试性，并通过“实现页面分屏”等案例说明各层能力如何协同工作。文章的结论是：大型代码库落地 AI 编码，关键不在于单点模型能力，而在于把责任边界、上下文管理、专业技能和回归评估工程化。
推荐收录，因为它不是泛泛谈“AI 写代码”，而是以 Chromium 这一超大开源项目为例，给出了可复用的 AI 工程化架构：如何管控责任、组织上下文、沉淀技能、做知识检索和建立评估回归。对正在建设代码助手、IDE Agent、企业级 AI 编码规范或大仓库自动化流程的读者，都有直接参考价值。
工程实践 Instacart Tech Blog 2026/02/26
本文讲述 Instacart 将 LLM 引入 Shopping Hub 推荐页的早期实践，目标是突破传统“静态内容库+统一排序”在个性化、页面一致性和快速迭代上的限制。作者先比较了自底向上与自顶向下两种生成范式，最终选择分阶段的自顶向下流水线：先生成页面主题与用户意图，再将主题映射为可检索关键词，随后做质量、多样性与业务约束过滤，最后接入既有排序系统。实现上使用了教师-学生微调、RAG、结构化约束解码以及 LLM-as-a-judge 和轻量分类器等多层评估与过滤手段，以控制成本并保证线上安全。文章还总结了将任务拆小、把评估前置、用结构化输入输出提升稳定性的经验。其边界在于当前仍处于早期阶段，效果主要来自离线评估和初步 A/B，尚未完全替代原有推荐体系。
收录价值明确：文章给出了 LLM 介入推荐系统的完整工程链路，包括分层生成、RAG、教师-学生训练和多级评估，且说明了为何放弃单模型端到端方案。适合做 AI 推荐、生成式内容和线上评估体系设计的参考，但需注意它仍是早期实验，结论以初步离线/A/B 结果为主。
工程实践 Dropbox Tech 2026/01/28
这篇文章是 Dropbox Dash 工程副总裁对其检索与智能问答架构的一次系统性拆解，重点讲了如何把多源工作内容接入“context engine”。作者先说明连接器、内容标准化、OCR/多模态理解、嵌入与知识关系建模，再进入 BM25 词法索引与向量库的混合检索，并通过多轮排序实现个性化和权限控制。文章还比较了 federated retrieval 与 index-based retrieval 的取舍，解释了为什么在 Dropbox 规模下更偏向预索引、离线富化和跨应用知识图谱，而不是纯实时拉取。随后作者讨论了 MCP 在上下文窗口、工具定义和延迟上的问题，以及通过“super tool”、子代理和本地存储工具结果来控成本。最后用 LLM as a judge、RAG as a judge 和 DSPy 展示了如何通过评测和提示优化持续提升检索相关性，但也明确指出这些方案高度依赖工程投入、数据新鲜度治理和复杂的离线/在线评估体系。
推荐收录，因为文中给出了 Dropbox Dash 的真实架构取舍：索引式检索、知识图谱 bundle、MCP 工具收敛、LLM 评测和 DSPy 优化都不是概念性描述，而是带有明确约束与结论的工程实践。适合正在做 RAG、企业搜索或 agent 平台的读者参考，但需要注意其方案建立在大规模数据接入和长期基础设施投入之上，不能直接照搬。
工程实践 Instacart Tech Blog 2025/11/13
文章复盘了 Instacart 用 LLM 重构 Query Understanding 的全过程，目标是提升购物搜索中长尾、口语化和歧义查询的意图识别能力。作者先指出传统方案依赖噪声标签、多个独立模型和碎片化流水线，难以同时兼顾召回、精度与维护成本。新方案以 LLM 为核心，分三层推进：用 RAG 和提示工程注入类目、转化等业务上下文，用后处理 guardrails 约束幻觉和类目偏差，再对关键场景做 LoRA 微调，把领域知识固化到小模型里。文章分别展示了类目分类、query rewrite 和 SRL 三个任务的改造方式，尤其强调“teacher 生成离线高质量数据 + student 承担实时长尾推理”的混合架构。最终他们在 8B 模型上达到接近大模型的 F1，并通过缓存、H100、adapter merge、量化取舍和 autoscaling 把延迟压到约 300ms，证明该路线既能提升搜索质量，也能控制成本，但前提是业务上下文足够丰富且可被持续治理。
收录依据很明确：文章不仅讲了 LLM 替代传统 QU 的思路，还给出了 RAG、guardrails、微调、缓存与延迟优化的完整落地链路，以及精度/召回/成本的结果。适合做搜索、推荐或垂直场景 LLM 工程的参考，尤其对需要处理长尾查询和实时推理约束的团队有直接迁移价值。
技术文章 Anthropic Engineering 2025/09/28
这篇文章把“context engineering”定义为比 prompt engineering 更完整的 LLM/Agent 设计问题：不只是写好提示词，而是持续管理系统指令、工具、示例、历史消息和外部检索信息，尽量把有限上下文窗口里的 token 用在最有信号的地方。作者用上下文退化、注意力预算和 Transformer 的 n² 关系解释了为什么长上下文并不等于高质量上下文，模型在信息检索和长程推理上仍会随长度增长而变差。文章进一步给出一套实操框架：系统提示要保持清晰、简洁且处于合适抽象层级，工具要少而明确，示例要选典型而非穷举边界。对于长周期任务，作者重点介绍了 compaction、结构化笔记、just-in-time 检索和子代理架构，说明它们分别适合持续对话、迭代开发和复杂研究。整体结论是，构建可靠 Agent 的核心不是堆上下文，而是不断筛选、压缩和动态加载最必要的信息，但这些策略仍受任务类型、工具设计和模型能力边界约束。
文章直接给出了上下文管理、工具设计、compaction 和子代理等可落地方法，是构建长程 Agent 的系统性经验总结。适合做 AI 应用、Agent 编排和检索增强设计的参考；其价值在于方法可迁移，但前提是读者理解上下文窗口与任务自治之间的权衡。
科研思考 Stanford Hazy Research 2023/04/18
这篇文章围绕“基础模型能否支撑私有化、个性化系统”展开，讨论了隐私、质量、成本三者之间的张力。作者指出，传统方案主要依赖联邦学习或在少量私有数据上微调公有模型，但前者往往需要牺牲部分隐私，后者在小数据场景里又很脆弱。文章进一步提出，基础模型的上下文学习能力可以把个性化任务转移到推理阶段，从而在不暴露私有数据的情况下完成本地适配。作者用 AMA、Evaporate 和基于检索的公开/私有混合数据系统等工作说明，开放模型的提示策略、推理成本压缩和多数据分布检索，都是推动私有个性化落地的关键方向。文章也明确了边界：现阶段强能力模型多为大规模闭源模型，某些任务仍依赖海量事实记忆，而训练数据的隐私与合法性问题仍未彻底解决。
文章直接给出了把基础模型用于私有个性化系统的研究框架，并用 AMA、Evaporate 和多隐私域检索的实证结果支撑观点，不是泛泛而谈。适合研究者、隐私计算/LLM 系统方向读者，以及需要判断“本地推理、检索与隐私边界”可迁移性的工程团队参考。