相关文章
2004 篇高质量内容
Milvus 3.0 开源解读｜词法+语义高亮，如何解决Agent的搜索噪音？
Milvus 3.0 引入词法与语义高亮能力，针对RAG和Agent场景中检索结果冗长、噪声多、上下文成本高的问题，通过片段化提取匹配内容，降低LLM token消耗并提升人类可读性。词法高亮基于BM25/TextMatch的token匹配，语义高亮则依赖自研开源模型实现跨表述语义关联识别。
Milvus 3.0 开源解读｜如何借助原生 TEXT 类型和 LOB 高效管理原始文本
Milvus 3.0 引入 DataType.TEXT 和 LOB 存储路径，使长文本成为数据库一等公民。TEXT 支持全文检索、BM25 和混合搜索；LOB 实现短文本内联、大文本外置，避免内存压力、写放大与 I/O 冗余。存储策略对上层透明，用户仍以普通字段方式操作。
降低RAG推理成本6倍的关键：让LLM只处理真正模糊的案例
在高风险、受监管场景中，全量调用LLM处理RAG分类任务会导致审计失效、成本飙升与模型漂移。级联架构通过确定性前置过滤、精准检索增强和非对称风险提示词，将仅10%–15%模糊案例交由LLM，显著提升可解释性、一致性与合规性。
RAG 在企业知识库中的实战：我们踩过的坑和填平的路
文章直击企业 RAG 落地四大核心问题：文档原始质量差、分块方式粗放、检索策略单一、知识库缺乏持续运营。针对每个问题，提出结构化解析、语义分块、混合检索+重排、建立更新管道与评测集等可落地方案，并强调元数据登记、引用溯源、基线评测等生产级标准。
你花几十万建的 AI 知识库 · 为什么没人敢用
文章指出企业AI化首个陷阱在于将知识库等同于向量数据库，导致组织最值钱的判断力结构被切碎丢失。RAG技术通过切块和向量化破坏了规则中的前提、条件、顺序与例外，使答案虽流畅却不可追溯、无法验证，最终沦为不敢依赖的负债而非资产。
从胡言乱语到精准改代码：我是如何让 AI 读懂老项目的
本文作者分享在重构教育小程序平台过程中，通过构建 AI 上下文工程（如 AGENTS.md）、清理无效代码、简化过度设计架构、制定规范与自动化测试，使 AI 从频繁出错转变为可高效定位问题、参与方案设计与落地的协作伙伴。核心在于将项目隐性知识显性化、结构化，让 AI 获得与资深开发者等效的上下文。
14 种文档格式转 Markdown，一个 Rust 库全搞定
Firecrawl 开源 Rust 库 anydoc，14种文档格式一键转 Markdown，无需多库拼接，实测速度碾压同类工具。 核心内容： 1. 文档格式转换痛点与现有方案局限 2. anydoc 库的功能覆盖与技术特性 3. 实测性能表现及速度优势
火山引擎 RDS MySQL 向量索引：把高性能向量检索带到 MySQL 上
火山引擎 RDS MySQL 推出原生高性能向量索引，支持在 MySQL 8.0/8.4 中直接执行向量检索，无需额外部署向量数据库。其在索引构建速度（提升 4~6 倍）、索引存储大小（减少 2~4 倍）和高召回下查询吞吐（领先 pgvector 2~3 倍）三方面显著优于 MariaDB 和 pgvector，并已适配 LangChain、LlamaIndex 等主流 RAG 框架。
RAG越来越“没存在感”，问题出在哪？
文章指出RAG术语在开发者社区中声量减弱，并非技术失效，而是因平台封装、长上下文能力提升及Skill/Tool范式兴起，使其从显性工程模块转为隐性基础设施。个人项目倾向直接读文件或按需检索，而企业级10万份文档场景仍依赖深度RAG工程。核心矛盾已从‘能否检索’转向‘检索结果是否真正可用’。
知识工程化：用 LLM-wiki + 谷歌 OKF，把"资料黑洞"变成活的智库
文章指出企业常见知识库实为“资料黑洞”，提出以LLM-wiki将散乱资料编译为可交叉引用、持续保鲜的结构化Wiki，并结合谷歌开源的OKF（开放知识格式）实现知识标准化与主权可控。该方法强调知识是“长”出来的而非“堆”出来的，适用于码头、生物医药等对数据主权与知识时效性要求高的场景。
停止盲目图化一切：GraphRAG 真正胜出的场景与代价
本文基于微软原论文及四项独立基准测试，实证分析GraphRAG相较向量RAG的适用边界：它在多跳推理、全局摘要和意义建构类任务中显著提升质量（+10–13分），但在单事实检索中无优势；其收益伴随高昂建图成本与LLM评估偏差风险。
别再迷信 LLM WIKI：大模型根本撑不起知识库的持续进化
文章指出当前主流LLM WIKI方案无法支撑知识库持续进化，因其无记忆、无状态特性难以处理上千份文件的跨版本查重与内容演化。实测显示，传统算法（Hash、文本指纹、特征识别）在本地完成全量扫描，10分钟识别1454个文件中的81组重复，准确区分完全相同、高度相似及疑似新旧版本，并将判断权交还用户。
RAG 真被 Google OKF 终结了吗？别急，它更像是企业级 AI 的关键拼图
Google 发布的 Open Knowledge Format（OKF）并非取代 RAG，而是一种静态知识打包规范，用于解决结构化文档碎片化问题。本文指出 OKF 与向量 RAG 各有适用边界：前者保障精确匹配与结构完整性，后者擅长语义理解；二者应通过双引擎 AI Router 协同工作，形成企业级上下文系统。
做完一次总体设计后，我重新理解了企业级知识库
本文基于一个企业级智能知识库项目的总体设计实践，系统阐述企业知识库的本质不是文档上传系统，而是涵盖构建、治理、使用、优化四阶段的知识工程闭环。文章提出知识库与知识空间双层结构、完整知识生命周期管理、可信溯源问答、知识健康闭环、权限嵌入检索链路等核心机制，并指出知识库最终服务对象是企业级Agent所需的企业上下文。
Agent Wiki 现状：AI 智能体的知识编译革命
Agent Wiki 提出“在摄入时编译知识”范式，以持久化 Markdown Wiki 替代传统 RAG 的实时检索。其三层架构（源文档、Wiki 页面、Schema 文件）与三大操作（Ingest/Query/Lint）已被 Cognition、Factory、LangChain 和 GBrain 四团队独立验证。该方法适用于中等规模知识集（约100源），但需区分“文档集知识”与“用户记忆”两类不同数据结构。
RAG vs MCP：驱动现代 AI 系统的隐秘之战
本文厘清 RAG（检索增强生成）与 MCP（模型上下文协议）的本质差异：RAG 解决 AI 获取私有知识的问题，是只读、低成本、低延迟的知识接入方式；MCP 解决 AI 执行操作的问题，是读写、高成本、高延迟的系统集成范式。二者非互斥，混合架构正成为企业落地主流，核心在于按任务类型选择知识获取或动作执行路径。
企业知识库最可怕的，不是“创建”，而是“持续治理”
文章指出企业知识库失效的根源并非建设困难，而在于缺乏持续治理能力：重复上传、版本混乱、旧文件滞留导致搜索不可信、AI引用失准。Knowly V3.11.0 新增上传时实时查重与主动知识库体检功能，通过识别文件名、版本信息及正文相似度，将存疑文件转入待确认状态，由业务人员结合上下文判断处置方式，而非自动删除。
Karpathy扔了一篇gist，想干掉RAG？
Andrej Karpathy提出的LLM Wiki构想，主张将知识库从运行时检索（RAG）转向由LLM持续维护的编译式Markdown Wiki；Google随后发布Open Knowledge Format（OKF）将其标准化，强调可追溯、可验证、可演化的知识资产。该模式不替代RAG，而是分层共存：RAG用于一次性查询，Wiki用于长期知识沉淀。
知识库不是文档仓库，而是 Agent 的上下文底座
本文指出AI应用的瓶颈常在于上下文质量而非模型能力，强调知识库应作为可读、可更新、可消费的AI-ready基础设施。提出三层结构（领域目录/路由文件/知识文件）、显式生命周期状态、主题级拆分粒度、Skill化建设流程及四维评测体系，并阐明AI-friendly设计需在结构化与人类判断间取得平衡。
RAG 找到内容以后，谁来证明它可信？
RAG 解决的是检索相关性，而非内容可信度。OKF v0.2 通过结构化元数据（provenance、trust、freshness、lifecycle、attestation）将知识治理结果显性化，使 Agent 能在读取正文前完成来源、状态、时效与计算合规性判断，从而在语义检索与生成之间增加轻量信任闸门。