RAG(检索增强生成)是一种结合了检索(通常是知识库或数据库)和生成模型(大语言模型)的技术,目的是在生成文本的时候能够参考相关的外部知识。这样,即使生成模型在训练时没有看到某些信息,它也能在生成时通过检索到的知识来生成更加准确和丰富的回答,这篇文章实现一种基于动态上下文窗口的方案,能够处理大规模文档,保留重要的上下文信息,提升检索效率,同时保持灵活性和可配置性。
RAG(检索增强生成)是一种结合了检索(通常是知识库或数据库)和生成模型(大语言模型)的技术,目的是在生成文本的时候能够参考相关的外部知识。这样,即使生成模型在训练时没有看到某些信息,它也能在生成时通过检索到的知识来生成更加准确和丰富的回答,这篇文章实现一种基于动态上下文窗口的方案,能够处理大规模文档,保留重要的上下文信息,提升检索效率,同时保持灵活性和可配置性。
最近看到的一个开源的提示词编排平台bisheng,音同「毕昇」,项目介绍说 「“毕昇”是活字印刷术的发明人,活字印刷术为人类知识的传递起到了巨大的推动作用。我们希望“毕昇”同样能够为智能应用的广泛落地提供有力的支撑」。看了下团队团队前身为国内人工智能独角兽企业第四范式的智能文档产品事业部,后根据发展需要进行业务独立拆分与运营,专注于非结构化数据的价值挖掘、信息处理自动化与数据即服务,第四范式在 AI 行业深耕多年,我比较期待能在这个项目里看到一些企业落地实践,所以阅读了毕昇平台的源码,写篇文章分享下。
如何利用 instructor 提高 RAG 的准确性和召回率
RAG(Retrieval Augmented Generation)是一种检索增强生成技术,它利用大型语言模型来处理用户查询,RAG 技术的主要组成包括数据提取—embedding—创建索引—检索—排序(Rerank)—LLM 归纳生成,不过实际落地过程来看,将用户查询转换为嵌入向量直接检索,很多时候的结果在相关度方面没有那么理想,本篇分享一种对用户查询进行重写再去进行检索从而提高准确性和召回率的方案。
在之前的文章中提到构建适合生产环境的 LLM(大型语言模型)应用挑战非常多,比如提示词的迭代、回归测试、评估等,agenta 就是一款很好的解决上述问题的工具。能够进行提示词版本控制、实验和评估,可以一键通过 API 的方式发布给开发人员接入使用,并且兼容常用的各种框架、库和模型,达到快速进行提示工程的目的,同时满足开发人员和领域专家的需求,虽然还处于 alpha 阶段,但已经成为我重度使用的提示词管理工具,本篇文章对其进行详细介绍。
Helicone 是一个开源的 LLM 应用可观测性平台,用于记录所有请求到 OpenAI 的日志,并提供用户友好的 UI 界面、缓存、自定义速率限制和重试等功能。它可以通过用户和自定义属性跟踪成本和延迟,并为每个请求提供一个调试环境(playground),以在 UI 中迭代提示和聊天对话内容。此外,Helicone 还提供了 Python 和 Node.JS 支持,以及开发者文档和社区支持。该项目已入选 YC W23(Y Combinator 2023冬季批次加速器计划)。本篇我将对 Helicone 具备的一些关键能力进行说明。
当大模型成本逐渐降低,可靠性提升后,越来越多的业务应用将与LLM结合。为此,需要开发结合内部基础设施的SDK,更友好的prompt管理工具,能够快速构建RAG相关概念证明的平台。总之,需要一些封装好的框架快速调试应用,以支撑LLM应用开发的快速开发。
国内各大厂商的大模型服务纷纷上线,应用密集落地应该是接下来的主旋律,将之前看过的 LLM Bootcamp 系列视频(由 The Full Stack 出品,内容由 11 节 talk 组成,质量很能打,感兴趣可以去看原视频)分享下。本篇主要是 LLMOps 这节讲座的笔记,包括如何选择基础模型、如何评估模型性能、模型的部署、如何管理Prompt的迭代过程、监控和持续改进,以及最后提出的测试驱动 LLM 应用开发的理念,比我的之前这篇更详尽,可以作为每个 LLM 应用开发者的一个 checklist,在应用国内基础语言模型服务时提供参考。
如何提高 LLM 可靠性和稳定性?开源项目 guidance 分享
在复杂的 LLM 应用开发中,特别涉及流程编排和多次 LLM 调用时,每次的 Prompt 设计都取决于前一个步骤的大模型输出。如何避免大语言模型的”胡说八道”,以提高大语言模型输出的可靠性和稳定性,成为一个具有挑战性的问题。在开发应用的过程中,我发现了微软推出的开源项目 guidance,能够很好地解决这一繁琐问题,本篇文章对此进行详细说明。
这篇文章是关于智能阅读助手 ReaderGPT 开发过程的记录,尽管本地玩了很多项目 demo,AutoGPT、JARVIS (HuggingGPT) 、知识库之类的,但一直未正式开发一个端到端服务。直到上个月申请到 Azure OpenAI,我想是时候开发一个完整的应用了,可以给朋友直接上手使用,并且确实可以大幅节省时间的工具,所以才有了这个和信息处理相关的智能阅读助手,我将从需求思考,应用架构,功能特性及后续迭代计划四部分来进行说明。
我的从零开始学 LangChain系列还没更完,感觉就要快被策反了 🤣,最近炒的很火的 我为什么放弃了 LangChain?,算是代表社区和广大开发者进行了一次大吐槽。LangChain 确实和 OpenAI 耦合的太紧导致扩展性较差,也存在过度封装以及调试困难的问题,但我的观点是在更成熟的框架出来之前,刚开始接触 LLM 应用开发的同学还是应该看看 Langchain,它运用 Prompt Engineering 的思想很值得借鉴,不过 LLM 应用开发的老司机确实该换工具了 🤡,这篇就给大家介绍下这款号称要替代 LangChain 的 AutoChain。