Skip to main content

黑洞资源笔记

  1. AMIE医疗诊断对话AI系统

    AMIE是一个基于大语言模型(LLM)的研究型AI系统,用于医学诊断推理和对话。它通过真实世界的数据集进行训练,包括医学推理、医学总结和真实世界的临床对话。

    AMIE使用了一种新的自弈仿真对话学习环境,可以在大量的疾病条件、专科和患者环境下提高诊断对话的质量。

    研究人员设计了一项随机双盲交叉研究,使用经验证的患者角色扮演者通过在线多轮同步文本聊天与执业医生或AMIE系统进行虚拟远程客观结构化临床考试(OSCE)。

    在149个不同科室的病例中,与20名初级保健医生相比,AMIE在诊断准确性和咨询质量的多个方面表现更好,从专科医生和患者角色的视角看是这样。

    AMIE作为辅助工具可显著提高临床医生解决复杂病例的诊断准确率,但AMIE有一定局限性,这项研究应谨慎解释,不能代表日常临床实践。需要更多研究来实现安全可靠的AI系统。

    临床专业知识仍然短缺,AMIE是探索AI系统与熟练临床医生相当属性的未来愿景的尝试,但还需要大量科学研究。
  2. SeamlessExpressive:高质量的语音到语音翻译,在翻译输出中保持原始说话者的声音风格、语气和独特的表达方式。

    SeamlessExpressive模型由两个主要模块组成:(1)Prosody UnitY2,它是基于UnitY2架构的韵律感知语音到单元翻译模型;(2)PRETSSEL,它是一种具有跨语言表达性保存的单元到语音模型。
  3. OpenWRT 将推出官方路由器

    为庆祝项目诞生 20 周年,OpenWRT 将推出首款官方路由器产品:「OpenWRT One / AP-24.XY」。根据 OpenWRT 团队的介绍,该项目在 17 - 18 年的 OpenWRT 峰会立项,但直到上个月才确定最终方案。

    根据目前公布的硬件提案,「OpenWRT One」将使用 MT7981B SOC 配合 1GB DDR4 内存组成运算核心,RF 芯片则会选用成熟的 MT7976C 方案。除此以外,这款产品还将配备 2.5 G + 1G 的 RJ45 电口、2042 规格的 M.2 硬盘位、以及支持 PD 协议的电源输入接口。OpenWRT 团队宣称这款产品将完全开源,并力争将价格控制在 100 美元以下。
  4. 介绍了一种更高效的方法来收集和标注图像数据,以用于视觉和视觉-语言应用。

    通过在电子商务网站上收集图像和描述文本,构建了一个名为Let's Go Shopping (LGS)的大规模公共数据集,包含1500万个图像-描述对。

    与现有的通用数据集相比,LGS图像更注重前景对象,背景较简单。实验结果表明,现有基准数据集上训练的分类器不容易推广到电子商务数据,而特定的自监督视觉特征提取器可以更好地泛化。

    此外,LGS具有高质量的电子商务焦点图像和双模态特性,在视觉语言双模态任务中具有优势,可以生成更丰富的图像描述并实现电子商务风格转换。

    为了使LGS可供公众使用,将以"BSD 3-Clause"许可证共享筛选后的图像-描述链接,并提供下载工具以便复现数据集。| paper
  5. MagicVideo-V2是一个多阶段的视频生成流程,将文本转图像、视频动作生成、参考图像嵌入和帧插值等模块集成到一个端到端的视频生成流水线中,能生成具有出色保真度和流畅度的高分辨率视频。

    MagicVideo-V2在美学质量和用户评估方面优于其他文本到视频系统。这一流程为从文本描述生成高质量视频提供了一种新的方法。
  6. ChatLLM 是一个 VSCode 扩展,用于以灵活且长格式的方式与 LLM API 进行交互。它利用 VSCode 笔记本支持来实现此目的,创建一种新型笔记本 (.chatllm) 文件,你可以在其中通过长文档与(基于 API 的)LLM 系统进行交互。

    注意:此插件需要你有自己的 OpenAI API 密钥(或其他 LLM API 密钥);它不适用于免费版本的 ChatGPT。

    特点包括:

    利用现有的笔记本用户体验,直接在 VSCode IDE 中进行聊天对话。
    在本地存储和操作长格式聊天对话,无需依赖云存储。
    将文件动态展开为提示,以更新提示以响应编辑。
    支持不同的LLM API(目前是OpenAI、Together、Google),支持多种不同的模型。

    chatllm-vscode | #扩展
  7. AIlice是一个正在开发的轻量级AI Agent,它也可以作为一个简单的开发框架,用于快速构建和试验各种AI Agent想法。特点如下:

    自然且高度容错的交互式代理调用树架构。
    以最灵活的方式解析 LLM 输出,支持更多样的函数调用机制。
    自构建、动态加载环境交互模块,提供无限的功能扩展潜力。
    专为开源模型设计,但无缝支持 GPT-4 等商业模型。
    支持对特定主题的深入调查。
    自动化编程和脚本执行。它是一个包罗万象的编码器和熟练的系统管理工具,掌握所有系统命令——类似于人工智能操作系统。

    设计AIlice时的基本原则是:

    以高度动态的提示构建机制丰富LLM行为;
    尽可能分离不同的计算任务,利用传统计算中的递归和分治法来解决复杂问题。
    代理应该能够双向交互。

    让我们简要解释一下这些基本原则。

    从最明显的层面开始,高度动态的提示结构使得代理不太可能陷入循环。外部环境新变量的涌入不断影响着法学硕士,帮助其避免陷入这种陷阱。此外,向法学硕士提供所有当前可用的信息可以大大提高其产出。例如,在自动化编程中,来自解释器或命令行的错误消息帮助法学硕士不断修改代码,直到获得正确的结果。最后,在动态提示构建中,提示中的新信息也可能来自其他智能体,作为一种联动推理计算的形式,使得系统的计算机制更加复杂、多样,能够产生更丰富的行为。

    从实际的角度来看,分离计算任务是由于我们有限的上下文窗口。我们不能指望在几千个代币的窗口内完成一项复杂的任务。如果我们能够分解一个复杂的任务,以便在有限的资源内解决每个子任务,那将是一个理想的结果。在传统的计算模型中,我们一直利用这一点,但在以LLM为中心的新计算中,这并不容易实现。问题是,如果一个子任务失败,整个任务就有失败的风险。递归更具挑战性:如何确保每次调用时,LLM 都能解决部分子问题,而不是将整个负担传递给下一级调用?我们在AIlice中用IACT架构解决了第一个问题,第二个问题理论上不难解决,但很可能需要更聪明的LLM。

    第三个原则是大家目前正在努力的:让多个智能代理交互、协作来完成更复杂的任务。这一原则的实现实际上解决了前面提到的子任务失败的问题。多智能体协作对于智能体运行中的容错能力至关重要。事实上,这可能是新计算范式与传统计算最大的区别之一:传统计算是精确且无错误的,仅通过单向通信(函数调用)来分配子任务,而新计算范式则容易出错且需要计算单元之间的双向通信来纠正错误。这将在下面有关 IACT 框架的部分中详细解释。