大模型
| 方向 | 开源项目 | 相关热点 | 主观解读 |
|---|---|---|---|
| 模型训练 | Bloom、ChatGLM、LLaMA、Dolly2 | 0门槛克隆ChatGPT！30分钟训完，60亿参数性能堪比GPT-3.5、Llama-X开源！唿吁每一位NLPer参与推动LLaMA成为最先进的LLM、Vicuna: An Open-Source Chatbot Impressing GPT-4 with 90%* ChatGPT Quality、ChatGPT平替「小羊驼」Mac可跑！2行代码单GPU，UC伯克利再发70亿参数开源模型、类ChatGPT开源模型，允许商业化！Dolly 2.0震撼发布！ | |
| 模型Serving | 大型语言模型的推理演算、如何在自己的笔记本上安装一个大语言模型？ | ||
| 模型层API | OpenAI：HTTP、JavaSDK | ||
| Hub层（API） | https://github.com/microsoft/JARVIS、HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face | ||
| 聚合层/应用层 API | https://github.com/hwchase17/langchain | LangChain：Model as a Service粘合剂，被ChatGPT插件干掉了吗、ChatGPT有了plugin，对于Langchain会有哪些影响？ | LangChain：是一个基于语言模型开发应用程序的框架。其相信最强大、最具差异化的应用程序不仅可以通过API调用语言模型，还应该具备以下特点：1.数据感知：将语言模型连接到其他数据源；2.主动性：允许语言模型与其环境进行交互。LangChain框架是按照以上原则设计的。目前原生的语言支持Python、JavaScript。 |
| AutoGPT | Star量近8万，大火AutoGPT星标超PyTorch，网友：看清它的局限性、本周最火 AutoGPT！GitHub3.6万+标星，解决复杂任务全程无需人类插手 | ||
| SK | 微软开源SK框架：支持将GPT-4等AI模型快速集成到产品，开发ChatGPT如此简单 | ||
| Prompt工程 | 用chatgpt生成midjourney的Prompt。（专业领域指令不会写)、Prompt Engineering全面自动化：LeCun看了沉默，ChatGPT看了直呼内行、吴军：ChatGPT不算新技术革命，带不来什么新机会 | 1. Prompt工程这一层，如果不能工具化、规模化就不能称之为工程。不能总结规律的工程师只能说是会写Promp，但不能称之为prompt工程师。2. 老板（帮写个新年全员通告） -> 秘书（理解老板的意图、需求、标准） -> 文员（chatgpt执行）在这个场景下，文员的理解能力足够好以后，秘书的是否可替代？认识：· 在聚合API这一层，提供解决一类或多类的问题的Prompt能力才叫工程；· 仅仅会写Prompt的价值在哪？LLM的目标应该是人人都可以写Prompt，人人写的Prompt都能被理解。 | |
| 工具类应用 | 6 个令人惊艳的 ChatGPT 项目，开源了！ | ||
| 对话类应用 | 对话中的问答：本质是如何使用大模型回答私域问题、更本质是知识挂载的问题，那基于知识的retrival方式，相应的有FAQB、DocQA、KBQA。 | https://github.com/openai/openai-cookbook/blob/main/examples/Question_answering_using_embeddings.ipynb | 这个过程中，使用LLM的核心能力是什么？· In-Context当前对话上下文中嵌入知识的理解能力。· NLG能力，拟人化的回复生成能力。· 如果垂类模型做得足够好，哪有大模型的用武之地？ |
| TaskBot和LLM的结合 | ChatGPT API: 一个早期应用开发者的视角 | 配置台整合意义不大，做好后端对话建模的整合、兼容、迁移。 | |
| 机器人Testing | |||
| 数据分析应用 | 对话分析（basedon: 对话结构化 + OLAP 数据引擎），如质检、培训 | 如何帮助一个人管理一群智能体？ | |
| 其他 | 独家首发！YC爆发AIGC潮，100+项目完整盘点、The Age of AI：拾象大模型及OpenAI投资思考、中文大模型安全评测平台、Compression for AGI、推动数字经济要办实事，少吹牛多交付 |
对话系统在LLM趋势下的机会
| 事前：对话发生前，上游依赖如何满足 | 知识管理，如DocQA、KBQA，数据是否符合范式、接口是否符合范式，这往往由业务决定；2C的机会少、2B才有整合数据的需要。 |
|---|---|
| DocQA中，Doc的上传是一种最为理想的数据供给方式。 | |
| 美团各个业务有各自的数据管理方式和接口，对话依赖的业务数据，有限的做功点是接口接入层的抽象。假如不做抽象，那么Prompt工程中对业务数据的结合部分就有定制化。 | |
| 机器人Testing，规则式的机器人每一轮都可以有精确的assert，那么大模型下的机器人如何测试：Goal是否达成 + 不出现不应该有的表现 | |
| 机器人去测试机器人？ | |
| 事中：对话进行时，对话流程是否自然顺畅 | RPA自动化与LLM的融合，Task任务、API、与大模型对话的自然互通 |
| 对话流程的可控性，既要泛化能力、又要垂类的控制能力 ；试想，如果控制到话术粒度级，与基于意图的问答机器人何异？ | |
| 对话理解能力的接入，这是一个可以快速落地的Prompt工程，特别是结合知识引擎。 | |
| 事后：对话结束后，如果洞察机器人的表现 | 如何灵活地的分析机器的表现，是否合规？ |
| 同理，基于人人对话的数据的质检是同样的。 |
)
