机器学习

引言 自 GPT3.5 引爆大模型概念以来，大家都期盼着 AGI1 的到来。但与此同时，当下各类大模型虽然依据 Scaling Law2，不断提升各方面的性能，但是关于模型的推理能力，总显得不足。 甚至科研界针对大模型究竟是否可能具有推理能力，也争论不休。例如下列近期比较热烈的讨论： ...

导言 伴随着大模型研究的推进和在应用中的实践，我们发现了一个现象——对于现有的 LLM 模型而言，一个好的编码可能会对其模型能力带来极大的助力。 关于这方面的思考其实由来已久，早前在听闻“压缩即智能”的论断，以及相关的数学阐述时，就产生过一种奇妙的念头： ...

问题的定义 探讨 RAG 之前，我们需要对我们要解决的问题做一个重新的理解。传统的 LLM 是一个语言的概率预测模型，它描述的是语言的自然分布概率，所以对于这样的模型，没有回答的答案哪个更好的说法，只有回答的答案哪个概率更高的描述。 ...

摘要 AI alignment，广义的 SFT 技术，因为其多种多样的实现方式，包括 continue learning、fine turing、LoRA、RLHF 等等，往往让大家对这个过程充满了好奇和憧憬，觉得似乎任何 NLP 的问题，只要拥有了神乎奇迹的 SFT 能力，就能从 pre-train model 进行进一步的提升，从而解决问题。 ...

Agent 使用指南 如何在真实世界中使用大模型？ 我说想开灯，大模型能帮我开灯吗？ 我们希望大模型能够直接的解决问题 这样的使用方法现在被人们称为： Agent 简单应用：如何修复一个 json 串？ 错误做法： 问大模型这个字符串哪里错了？ 写代码修复字符串 正确做法： “Do not change the specific content, fix the json, directly return the repaired JSON, without any explanation and dialogue.” 什么情况下我们需要 Agent ？ 不需要的情况： 操作简单，人可以快速解决； 规则清晰，程序可以按规则解决； 需要的情况： 解决步骤繁琐，对于人来说是重复劳动； 情况复杂，不容易梳理清楚对应的解决规则； 场景举例 Github 的 Copilot MacOS 的 Copilot 软件自动运维 Yi 6B 的自动安装助手 上网助手 $\dots$ 高级场景举例 自动软件开发（GPT Engineer） 自动会议纪要 自动任务记录 自动会议预定 自动消息通知 高级个人助理 一切自动化流程中需要人工参与的部分 解决复杂问题有哪些难点？ 解决复杂问题往往需要很多步骤； 而且正确的步骤往往也也需要探索； Agent 需要能够正确的了解自己当前解决问题的进度； 具体的步骤中，Agent 需要可以使用具体的工具； 传统 Agent 的定义 Agent = LLM + planning + memory + tools 如何打造一个联网的 LLM ？ [Thought] 针对用户输入，让 LLM 判断应该从哪个搜索引擎用什么关键词 获取结果； [Act] 获取搜索引擎在对应关键词下的搜索结果； [Obs] 具体返回的搜索结果； [Thought] 判断是否回答了用户的输入，如果没有，类似第一步，继续判断如何搜索； 如何打造 Yi 6B 的自动安装助手 如何打造 MacOS 的 Copilot 如何打造一个可以自动软件开发的 Agent 这件事需要产品做什么？ 找到适合的场景 设计场景下的合理交互 总结场景下的最佳实践(作为数据喂给模型就可以了) 扩展场景 大模型还没有出现 Killer APP 是因为还没有懂 Agent 的产品经理 ...

RAG 技术 检索增强的生成系统（Retrieve Augment Generation）简称 RAG。 原理是在大语言模型的基础上，辅助检索技术，让大语言模型能够获得与用户问题相关的更多上下文信息，使得的大语言模型可以： 降低幻觉出现概率 适应垂直场景应用 弥补数据实时性不足 一个典型 RAG 系统的架构 RAG 系统的核心技术要素 文档导入 文档切分 文档向量化 向量数据库选型 检索算法 文档排序 Prompt 生成 $\dots$ 市面上大部分的关于 RAG 的介绍都是类似上面的逻辑进行的，然后就顺利的将 某一种 RAG 的方法 变成了 通用 RAG 的框架，从而让我们迷失了 RAG 的真正价值。 ...