ainews-graphrag

GraphRAG:知识图谱与 RAG 的结合(或:知识图谱与 RAG 的联姻)

以下是为您翻译的中文内容:

微软研究院(Microsoft Research)开源了 GraphRAG,这是一种检索增强生成(RAG)技术。它通过从源数据中提取知识图谱并进行聚类,从而提升大语言模型(LLM)的回答质量,但同时也增加了 Token 消耗和推理时间。Gemma 2 系列模型正式发布,专注于高效的小型大模型,并引入了滑动窗口注意力机制(sliding window attention)和 RMS 归一化(RMS norm)等创新技术,其性能已接近规模更大的 Llama 3 70B。Anthropic 的 Claude 3.5 Sonnet 在指令遵循和编程基准测试中处于领先地位,而英伟达(Nvidia)也在 6 月发布了 Nemotron 340B 模型。Qwen2-72B(通义千问)在 HuggingFace 开源大模型排行榜上名列前茅,在数学和长程推理方面表现卓越。有关 RAG 的讨论重点关注了其局限性,以及如何通过函数调用来优化上下文的使用。一种角色驱动(persona-driven)的合成数据生成方法引入了 10 亿个角色,基于此微调的 7B 规模模型在数学基准测试中达到了与 GPT-4 相当的水平。此外,拥有 200GB 数据的 AutoMathText 数据集在数学数据合成方面的作用也受到了关注。

#retrieval-augmented-generation #knowledge-graphs #token-usage #inference-time #attention-mechanisms #instruction-following #coding #math #long-range-reasoning #synthetic-data #dataset-release #fine-tuning #context-windows #function-calling gemma-2 llama-3-70b claude-3.5-sonnet nemotron-340b qwen2-72b llama-3 microsoft-research anthropic nvidia hugging-face

KG 是 LLM 所需的一切。

2024年7月1日至7月2日的 AI 新闻。 我们为您检查了 7 个 subreddit、384 个 Twitter 账号30 个 Discord(419 个频道和 2518 条消息)。 预计节省阅读时间(以每分钟 200 字计):310 分钟。您现在可以标记 @smol_ai 进行 AINews 讨论!

神经符号(Neurosymbolic)的拥趸们欢呼吧!

image.png

image.png

Microsoft Research 最初在 4 月份发布了 GraphRAG,在上周 AI Engineer World’s Fair 的 Neo4j 工作坊和演讲中,它出人意料地受欢迎(视频尚未上线,所以我们还没看到,但很快就会有了 (tm))。他们现在已经开源了代码。正如 Travis Fischer 所说

  1. 使用 LLM 从源数据中提取知识图谱(Knowledge Graph)
  2. 将该图谱聚类为不同细节层级的相关实体社区
  3. 对于 RAG,遍历(map)所有社区以创建“社区回答”,并进行规约(reduce)以生成最终答案。

或者用他们相对不那么通俗易懂的话来说:

image.png

然而,这类性能提升技术都有一个公开的秘密:Token 使用量和推理时间都会增加 🙃

同样值得注意的还有:他们的 Prompt 重写方法


目录频道摘要已移至此邮件的网页版:


AI Twitter 摘要

所有摘要均由 Claude 3 Opus 完成,取 4 次运行中的最佳结果。我们正在使用 Haiku 进行聚类和流程工程(flow engineering)。

LLM 模型发布与改进

  • Gemma 2 模型发布@rasbt 指出 Gemma 2 模型在不增加数据集大小的情况下探索了新技术,专注于开发小型且高效的 LLM。关键设计选择包括 sliding window attention、group-query attention 和 RMS norm。Gemma 2 的表现几乎与体积大 3 倍的 Llama 3 70B 相当。
  • Anthropic 的 Claude 3.5 Sonnet 模型@alexandr_wang 报告称,Claude 3.5 Sonnet 在 ScaleAI 的隐藏评估中目前在 Instruction Following 和 Coding 方面排名第一。然而,与其他顶级模型相比,它在写作风格和格式方面失分较多。
  • Nvidia 的 Nemotron 340B 模型@osanseviero 分享了 Nemotron,这是一个 340B 参数模型,作为 6 月开源模型发布的一部分推出。
  • Qwen2-72B 登顶 HuggingFace Open LLM Leaderboard@rohanpaul_ai 指出 Qwen2-72B 平均得分 43.02,在 数学、长程推理和知识 方面表现出色。有趣的是,Llama-3-70B-Instruct 在 GPQA 上的得分比其预训练版本低了 15 分。

检索增强生成 (RAG) 技术与挑战

  • RAG 基础演讲@HamelHusain 分享了来自 LLM 大会的 RAG 基础演讲,涵盖了核心概念和技术
  • RAG 的局限性@svpino 讨论了 RAG 的局限性,包括 检索、长上下文窗口、评估以及配置系统以提供答案来源等方面的挑战
  • 改进 RAG 中的 LLM 上下文使用@AAAzzam 分享了一个让 LLM 更有效地使用上下文的技巧——LLM 对来自函数调用的信息的利用远高于普通上下文。将上下文转换为伪函数调用(pseudo function calls)可以改善结果。

合成数据生成与应用

  • 角色驱动的数据合成@omarsar0 分享了一篇论文,提出了一种角色驱动的数据合成方法来生成多样化的合成数据。它引入了 10 亿个多样化角色,以促进创建涵盖广泛视角的模型。在 107 万个合成数学问题上微调的模型在 MATH 测试中达到了 64.9%,以 7B 的规模达到了 GPT-4 的性能。
  • AutoMathText 数据集@rohanpaul_ai 强调了 200GB 的 AutoMathText 数据集,包含用于预训练数学语言模型的数学文本和代码。该数据集由来自 arXiv、OpenWebMath 以及编程仓库/网站的内容组成。
  • 数学能力的合成数据@rohanpaul_ai 指出一篇论文显示,在提高 LLM 的数学能力方面,合成数据几乎与真实数据一样有效。在合成数据上训练的 LLaMA-2 7B 模型在 GSM8K 和 MATH 基准测试中比之前的模型高出 14-20%。

其他

  • 通过分块量化的 8-bit 优化器@rohanpaul_ai 回顾了 2022 年一篇关于 8-bit 优化器的论文,该优化器能 保持 32-bit 优化器的性能。关键创新包括分块量化(block-wise quantization)、动态量化和稳定嵌入层,以在不损失效率的情况下减少内存占用。
  • 理解并减轻语言混淆@seb_ruder 介绍了一篇分析 LLM 无法按用户要求的语言生成文本的论文。Language Confusion Benchmark 衡量了 15 种语言的这一现象。即使是强大的 LLM 也会表现出混淆,以英语为中心的指令微调会产生负面影响。论文提出了推理和训练阶段的缓解措施。
  • 托管 LLM 价格对比@_philschmid 分享了来自不同供应商的托管 LLM 的最新价格表。核心洞察:顶级闭源 LLM 每 1M 输出 tokens 约 15 美元,Deepseek v2 最便宜,为 0.28 美元/M,Gemini 1.5 Flash 性价比最高,Llama 3 70B 约 1 美元/1M tokens

AI Reddit 摘要回顾

涵盖 r/LocalLlama, r/machinelearning, r/openai, r/stablediffusion, r/ArtificialInteligence, /r/LLMDevs, /r/Singularity。评论抓取功能现已上线,但仍有很大改进空间!

LLM 开发与能力

Stable Diffusion 模型与训练

硬件与性能

优化与基准测试


AI Discord 回顾

摘要的摘要之摘要

  1. LLM 性能与基准测试进展

    • 来自 Microsoft 的 Phi-3 Mini 和来自 Google 的 Gemma 2 等新模型在指令遵循和性能方面表现出显著提升。

    • AI 社区正在积极讨论和比较模型性能,并围绕 AlignBench 和 MT-Bench 等基准测试展开辩论。

    • 人们对可复现的基准测试越来越感兴趣,并致力于使用 lm_eval 等工具为 Gemma 2 等模型复现结果。

  2. 优化 LLM 训练与推理

  3. 开源 AI 开发与社区协作

  4. 多模态 AI 与生成式建模

    • 视觉语言模型的进展正被广泛讨论,包括针对越南语的 Vistral 7B 以及通过 WebGPU 在本地运行的 Florence-2

    • 文本转视频生成正受到关注,Runway 的 Gen-3 等工具引发了关于功能和定价的讨论。

    • 社区正在探索模型和技术的组合,以实现 DALLE-3 级别的输出,这表明了向更复杂的多模态系统发展的趋势。


第一部分:高层级 Discord 摘要

LM Studio Discord

  • LM Studio 的崭新装甲LM Studio 0.2.27 版本发布,重点改进了对 Gemma 9B 和 27B 模型的支持,建议用户下载 新版本 或使用自动更新功能。发布的 更新日志 显示了多项 Bug 修复以及更新的 llama.cpp commit ID。
    • 社区成员还热烈讨论了 Microsoft 将 Phi-3 Mini 升级为 Phi 3.1 的举动,强调了其在性能和指令遵循方面的飞跃——可以前往 Hugging Face 体验这一新浪潮。
  • 硬件的热浪与障碍:在 LLM 任务中,VRAM 优于 RAM 的地位是热门话题,共识倾向于将 8GB VRAM 作为避免性能陷阱的最低推荐配置。一位用户展示了拥有 120GB VRAM(配备 5 块水冷 4090s)的装备,其处理 LLM 推理的强力方案引发了广泛关注。
    • 然而,并非一切都顺风顺水,有成员报告在 P40 GPU 等硬件上使用 LM Studio 时出现 GPU 待机温度问题,以及更新后特别是 AMD GPUs 的兼容性担忧,详见 Extension-Pack-Instructions.md
  • 开发者聊天中的协作调试LM Studio 中的 SDK 版本冲突导致用户在升级到 0.2.26 后陷入了 await client.llm.load(modelPath); 错误的困境。lmstudio.jsGitHub issue 记录了这一过程,为社区排查故障提供了平台。
    • Discord 机器人也未能幸免;一个由于缺少 MessageContent intents 导致的 TokenInvalid 错误案例,通过社区协作得到了解决,彰显了集体解决问题的精神。
  • 量化精要与 Gemma 2:对 Gemma 2 模型更新的热情与 Phi 3.1 的增强不相上下,两者都承诺在最新的 LM Studio 迭代中运行更加顺畅。社区向量化版本的转向(如 Gemma 2 9b 和 27b)表明了对性能优化的敏锐关注。
    • 尽管 Gemma 2AMD 6900 XT GPU 上遇到了意外挫折(如“模型加载失败”问题所示),目前的趋势似乎倾向于“重新下载并重试”的方法,不过成员们仍在等待更稳妥的修复方案。

HuggingFace Discord

  • Transformers 的技术凯旋:随着 Transformers 4.42 的发布,用户现在可以访问各种新鲜模型和功能,包括 Gemma 2RT-DETR 等,详见 更新日志
    • 社区反应显示出对此次更新的高度兴奋,期待其带来的增强功能和高效的 RAG 支持。
  • Chronos 数据纪元AWS 在 Hugging Face 上发布了其 Chronos 数据集及评估脚本,提供了用于预训练和评估的数据集,详情参阅 此处
    • 这些数据集的发布获得了社区的赞誉,被认为是对比特时间数据处理和分析感兴趣者的重大贡献
  • 大规模指标:Hub 的重要里程碑:已有 10 万个公开模型利用 Hub 存储 tensorboard 日志,功能汇总见 此处,展示了该平台不断扩展的实用性。
    • 这一成就被视为模型监控的重要枢纽,简化了在模型 Checkpoints 旁跟踪训练日志的过程。
  • 越南语视觉语言探索:越南 AI 的新浪潮由 Vistral 7B 引领,这是一款基于 LLaVA 和 Gemini API 的视觉语言模型 (Vision-Language model),旨在增强图像描述能力,如其 GitHub 所示。
    • 团队开启了社区参与渠道,通过交互式 Demo 寻求关于模型性能的见解,以进一步挖掘视觉能力。
  • 时尚界的 AI 艺术:电子商务的未来Tony Assi 展示了多个为电子商务量身定制的 AI 驱动项目,特别关注利用计算机视觉和机器学习在时尚领域进行创新。
    • 这些应用的多样性(可在 此处 查看)凸显了 AI 在转型电子商务行业方面的巨大潜力

CUDA MODE Discord

  • CUDA Conclave Crunch:一场仅限 CUDA 的黑客松 (CUDA-only hackathon) 将于 7 月 13 日在旧金山举行。该活动由 Chris Lattner 主办,并提供 H100 访问权限,这体现了 Nebius AI 的支持。
    • 活动旨在培养硬核黑客精神,从中午 12:00 持续到晚上 10:00,严格遵守 CUDA 标准,并在 Twitter 上引发了讨论热潮。
  • 矩阵乘法大师 (Matrix Multiplication Mastery)Mobicham 发布了矩阵乘法指南,演示了在 CPU 上的计算,对于专注于基础操作的 AI 工程师来说是一个出色的资源。
    • 这一经常被忽视的 AI 模型效率核心成为了关注焦点,为围绕 AI 工作流中计算优化的讨论铺平了道路。
  • INTx 基准测试闪击战 (INTx’s Benchmarking Blitz):INTx 性能基准测试 超过了 fp16,其中 int2int4 在每秒 token 数 (tokens per second) 方面打破了记录。
    • torchao 量化实验表明,int8-weightintx-4 展示了惊人的速度,而在 batch size 为 1 时优化的评估则强调了未来的性能探索方向。
  • 基准测试脚本集市 (Benchmark Script Bazaar):MobiusML 分享了对 AI 社区至关重要的 基准测试脚本,以及每秒 token 数的测量方法。
    • 这些基准测试对于性能指标至关重要,特别是在解决了最近关于 Transformers 及其缓存逻辑的问题之后。
  • 从 CUDA 琐事到核心重构 (CUDA Chores to Core Overhaul):工程师们在 CUDA MODE 中重构了辅助函数和 kernel 函数,提升了效率和内存优化,同时倡导 GenericVector 的应用。
    • AI 从业者仔细研究了训练稳定性 (training stability),剖析了数据集的影响,简化了设置,并讨论了推理优化,这在对 llm.c 等仓库的贡献中可见一斑。

Perplexity AI Discord

  • 与 Perplexity 的 Android 应用畅谈:Perplexity AI 为 Android 发布了语音对语音功能 (voice-to-voice feature),实现了无缝的免提交互,并通过指定频道征集用户反馈。该应用提供 Hands-free(免提)和 Push-to-talk(一键通)两种模式。
    • Pro Search 更新增强了 Perplexity 处理复杂查询的能力,坚实支持多步推理、**Wolfram Alpha** 和代码执行。点击此处探索增强功能。
  • 使用 Perplexity AI 整理知识:用户讨论中反映了 Perplexity AI 搜索引擎的局限性,例如对印度新闻的偏见和不稳定的来源选择,并将其与 Morphic.sh 等同类工具进行了评估。显然需要增强来源设置并平衡全球内容。
    • 社区对话揭示了 Claude 在 Perplexity AI 中存在 32k tokens 的瓶颈,这降低了用户对宣传中 200k tokens 的预期。这标志着它正从理想的 AI Assistant 转向更以搜索为中心的模型。
  • 探讨 Perplexity 的绘图潜力:关于在 Perplexity AI 中进行数据可视化的咨询得出结论,虽然它本身不生成图表,但可以辅助生成用于 Google Colab 等外部平台的代码。成员们建议利用 AIlin 等扩展来实现集成的图形输出。
    • 针对推荐链接 (referral links) 的泛滥,Perplexity AI 用户群期待潜在的试用版本,尽管由于过去的滥用行为目前似乎并未提供。社区在订阅前获得亲身体验的渴望仍未得到满足。
  • 从魔方周年庆到 Meta 的危机:为纪念半个世纪的认知挑战,魔方 (Rubik’s Cube) 迎来了 50 周年纪念并发布了特别致敬视频,可在此处观看。在魔方的光辉之下,还有一系列杂乱的新闻,从 Meta 的欧盟指控到电动飞行的创新。
    • 出现了关于通过 Perplexity AI 创建业务计划的讨论,展示了一个用于构建创业战略的精益画布 (lean canvas) 教程。热衷于商业的头脑被该指南所吸引,详见此处
  • Perplexity 管线中的 API 焦虑与期待:Perplexity AI 的 API 生态系统遇到了 Chrome 设置无法加载的小故障,促使用户探索 Safari 作为替代方案,社区建议通过清除缓存进行修复。
    • 虽然 Sonnet 3.5 仍未进入 Perplexity API 的范畴,但通过 API 使用搜索引擎的兴趣引发了关于可用模型及其与 Hugging Face 实现的功能对等性的讨论。详细的模型文档请参考此处

Unsloth AI (Daniel Han) Discord

  • 十亿角色突破攻克 MATH 难题Aran Komatsuzaki 详细介绍了 Persona Hub 项目,该项目通过 10 亿个 personas 生成数据,将 MATH 分数从 49.6 提升至 64.9。他们在 GitHub repoarXiv 论文 中分享了这一概念,引发了关于数据价值高于代码的讨论。
    • 讨论围绕 Persona Hub 的复制难度以及扩展合成数据生成的潜力展开,一位成员强调:“数据远比代码重要”。
  • Phi-3 Mini 获得性能增强更新:Microsoft 宣布升级 Phi-3 Mini,增强了 Hugging Face 上的 4K 和 128K 上下文模型权重,并引发了对其未公开的高级训练方法的猜测。
    • LocalLLaMA 社区反应热烈,有人幽默地将其与 OpenAI 的保密做法进行对比,调侃道 “ClosedAI 的 CriticGPT”
  • Unsloth 采用 SPPO 以实现流线化集成theyruinedelise 确认了 SPPO 与 Unsloth 的兼容性,讨论了它如何与 TRL 协同运行,为 Unsloth 用户提供直接的集成方案。
    • 集成方面的进展仍在继续,Unsloth 通过 TRL 可靠地扩展了对 SPPO 的支持,简化了开发者的工作流。
  • 在 Discord 中与聊天机器人闲聊:由 jakobdylanc 开发的 llmcord.py 脚本已在 GitHub 上线,它将 Discord 重新利用为 LLM 界面,因其实用性和易用性赢得了社区的赞誉。
    • 社区成员受到该发布的启发,纷纷表达赞赏,如“做得好!”等评价,强调了对这一创新的集体支持。
  • 征集 Notebook 反馈:一个新的支持多个数据集的 Colab notebook 向社区征求反馈,旨在优化用户体验和功能。
    • 该 Notebook 的显著特性,如 Exllama2 quant 支持LoRA rank scaling,反映了社区的协作精神,期待获得建设性的反馈。

Stability.ai (Stable Diffusion) Discord

  • 解决显存 (VRAM) 困扰的 Diffusion 难题:一位成员询问如何在仅有 12GB VRAM 的情况下使用 Stable Diffusion,因为 everydream2 trainer 需要 16GB。另一位成员分享了在 8GB VRAM 系统上经过 4 小时高强度运行后成功生成微型 checkpoint 的经验。
    • 对话转向了在显存受限的系统上运行 Stable Diffusion 的策略,成员们交流了关于不同模型和设置的技巧,以更好地适应硬件限制。
  • Stable Diffusion 3 面临挑战:社区剖析了 Stable Diffusion 3 (SD3) 的弱点,指出其在精细可调性方面未达预期,且功能实现不完整,例如 Low-Rank Adaptation (LoRA) 的训练效率低下。
    • 一位参与者对 SD3 在复杂姿势下的图像质量缺陷表示失望,主张进一步改进功能以克服模型性能不稳定的领域。
  • LoRA 的学习循环:关于为特定风格(从 3D 分形到游戏截图)训练 LoRA (Low-Rank Adaptation) 的讨论激增,尽管 Stable Diffusion 3 对 LoRA 训练的限制是一个制约因素。
    • 社区成员热烈地交流了辅助专业训练的变通方法和工具,反复强调在追求自定义模型精通的过程中,尝试与错误(trial and error)的价值。
  • Stable Diffusion 的风格光谱:参与者分享了他们在 Stable Diffusion 广泛风格光谱上的成功与尝试,从线条艺术的锐利到恐怖风格的诡异,每一个案例都包含了使用成功的经验和提示词(prompt)失控的不可预测性。
    • 尽管提示词有时会带来莫名其妙的混淆,成员们仍对模型交织不同视觉叙事的能力感到欣喜。
  • 艺术 vs AI:反 AI 算法的困境:公会辩论了开发软件以保护艺术家作品不被 AI 吸收的问题,参考了 Glaze 和 Nightshade 等工具,并承认这些方法在面对持续存在的漏洞时存在不足。
    • 辩论揭示了在艺术作品中嵌入反 AI 功能的实用性,并讨论了与数字艺术复制相关的道德问题,强调了有效防止 AI 同化的挑战。

OpenAI Discord

  • 价格冲击与硅片阻碍:工程界对 8 H100 GPUs 昂贵的价格议论纷纷,据称价格超过 50 万美元,且采购存在瓶颈,需要 NVIDIA 企业账户。
    • 侧边栏讨论揭示了对 Google TPUsPaperspace 等替代方案的兴趣,后者提供 每小时 2.24 美元的 H100,被视为具有成本效益的训练解决方案。
  • AI 创作者评估工具:人工智能图像爱好者对 Luma Dream MachineRunway Gen-3 等工具表示不满,认为其定价过高,15 美元 仅能生成寥寥 6-7 个输出
    • 随着人们认为这些工具相较于前代产品缺乏实质性进步,热情有所减退,这促使生成式工具市场需要更高的效率和创造力。
  • 模型 Prompt 中的多步失误:社区讨论了 GPT 在执行多步任务时尽管有明确指令却仍倾向于跳过步骤的问题,这损害了模型在任务执行中的彻底性。
    • 有人分享了一种按顺序构建指令的技巧,即使用“这个在那个之前”的逻辑,引导 GPT 完整执行预定流程而不遗漏步骤。
  • 意图查询的探究:讨论深入探讨了如何为意图检查设计精巧的 RAG-on-GPT-4o Prompt,将响应细分为模糊、历史记录或需要新搜索查询。
    • 开发者担心 Bot 会混淆历史记录与新查询,因此呼吁在上下文和意图解释方面保持一致性。
  • 局限性与编排层:对话深入探讨了 multimodal models 的局限性及其在特定领域的挣扎,并以 Python 编程等专业任务作为计算对比。
    • LangChain 这样的编排器因其在扩展 AI 上下文限制(突破 4k token 阈值)以及构建 GPT-4LLama 等高级模型架构中的作用而备受关注。

Eleuther Discord

  • vLLM 驰援 HF 救援:一位用户建议使用 vLLM 作为 HF 已知问题的解决方案,参考 wiki 指南 将模型转换为 16 Bit,从而提高效率。
    • 社区对这种模型部署的替代方案表示赞赏,因为 vLLM 被证明是有效的,用户对该建议表示感谢。
  • Gemma 2 复现问题受到关注:使用 lm_evalGemma 2 进行的准确率基准测试与官方指标不符,促使用户尝试使用 bfloat16 和特定的 Transformer 版本,详见此处
    • model_args 中添加 add_bos_token=true 后,得分更接近模型的论文基准,特别是 lambada_openai 的准确率从 0.2663 跃升至 0.7518
  • LLM Tokenization 中的语义混淆:一篇新论文审视了 LLM Tokenization 中的“擦除”效应,指出 Llama-2-7b 有时会将“northeastern”等单词拆分为不相关的 Token。
    • 该研究因深入探讨从随机 Token 组到高层表示的转换而引起关注,有助于理解 Tokenization 过程。
  • “分解诅咒”成为头条:一篇论文将“反转诅咒”重新定义为“分解诅咒(factorization curse)”,揭示了 LLM 在信息检索方面的问题,并引入了 WikiReversal 来模拟复杂任务。
    • 报告暗示在损坏或改写的数据上进行训练后,模型泛化能力更好,受此启发,有人建议采用 UL2 风格的目标。
  • Fewshot Prompts 的图形可视化:正在研究 Fewshot Prompting 对准确率影响的用户正在寻求可视化 Prompt 效果的方法,并尝试使用 --log_samples 进行更深入的分析。
    • 展示的一种方法是保存输出以供检查,旨在发现 Fewshot Prompting 的负面影响,并指导评估准确率的提升。

Nous Research AI Discord

  • Apple 在端侧表现惊艳Apple 的可变比特量化 (variable bit quantization) 优化了端侧 LLM,正如其 Talaria 工具 所展示的那样,该工具自发布以来已增强了 3,600 多个模型。该技术获得了最佳论文荣誉提名 (Best Paper Honorable Mention),功劳归于 Fred Hohman 和 Chaoqun Wang 等知名研究人员。
    • WWDC 2024 上,随着 Apple Foundation Models 的推出,端侧智能得到了进一步推动。这些模型整合了 iOS 18、iPadOS 18 和 macOS Sequoia。根据 Apple 的报告,展示了一个用于日常任务的 30 亿参数端侧 LLM。
  • Runway 变革:视频生成成本引发热议Runway 最先进的视频生成工具尽管技术领先,但 60 秒视频 12 美元的价格标签引发了争论。
    • 社区成员 Mautonomy 领头呼吁更合理的 每生成一次 0.5 美元 的价格,并将其与其他溢价服务进行了比较。
  • Genstruct 7B 催化指令创作:NousResearch 的 Genstruct 7B 模型脱颖而出,成为从原始文本构建指令数据集的工具包,其灵感源自 Ada-Instruct
    • Kainan_e 强调,Genstruct 旨在简化 LLM 的训练,使其成为寻求增强指令生成能力的开发人员关注的焦点。
  • VLLMs:动画中的视觉与语言融合:讨论涉及训练 VLLMs 以实现动画自动化,其中推介了一种基于扩散的关键帧补间方法
    • 社区一致认为 Hermes Pro 在该领域可能具有潜力,而 Verafice 则带头批评并寻求更有效的解决方案。

Modular (Mojo 🔥) Discord

  • Mojo 的树莓派难题:在 Raspberry Pi 5Ubuntu 24.04 上运行 Mojo 时出现了一个问题,引发了对故障排除支持的寻求。
    • 该情况在对话中仍未解决,突显了对社区驱动解决方案或进一步对话的需求。
  • Mojo 拓展视野:讨论揭示了 Mojo 在推进 基于模型和模拟器的 RL(用于 LLM Agent)、符号推理 (symbolic reasoning) 以及 亚符号模型引导 (sub-symbolic model steering) 等领域的潜力。
    • 参与者集中讨论了这些新兴应用,社区成员表达了合作和交流见解的渴望。
  • 基准测试的利与弊:社区努力为 Mojo 的测试和基准测试框架带来了显著增强,特别是提高了性能指标。
    • 尽管取得了进展,但由于舍入误差导致的基准测试失败以及 GFlops/s 测试期间的死循环等挑战,凸显了优化工作的迭代本质。
  • Nightly 编译器复杂性:Mojo 编译器 Nightly 版本 2024.7.205 的发布促使了关于使用 modular update nightly/mojo 进行版本控制的讨论,并解决了 CI 转换问题。
    • 周边商品查询得到了社区的直接支持,而一些成员面临的 Nightly/Max 软件包更新挑战最终也得到了解决。
  • 矩阵乘法思索:大量活动集中在 src/main 编译错误上,特别是 matrix.mojo 中的 DTypePointer,导致了使用稳定构建版本的建议。
    • 参与者集思广益改进矩阵乘法,提出了向量化 (vectorization)、分块 (tiling) 以及集成 StrassenWinograd-Copper 等算法的方案。

OpenRouter (Alex Atallah) Discord

  • 模型页面改版:宣布了 /models 页面更新,承诺带来新的改进,并在此征求社区反馈 此处
    • Gemini 和 PaLM 的 token 尺寸变更将使统计数据标准化,但也会改变定价和上下文限制 (context limits);社区将面临调整。
  • 弃用默认模型:OpenRouter 设置中的默认模型 (Default Model) 正面临弃用 (deprecation),取而代之的是特定模型设置或自动路由 (auto router) 等替代方案。
    • 针对 OpenAI API 密钥的自定义认证头 (Custom auth headers) 也正在逐步淘汰,这表明正转向更新、更可靠的身份验证方法。
  • Discord 机器人对话精简化:社区成员分享了优化对话机器人的技巧,强调了高效利用 token (token-efficient) 的策略,例如在 prompt 中仅包含必要的消息部分。
    • 这引发了关于平衡模型上下文限制 (context limits) 与保持对话吸引力的讨论,并参考了 SillyTavern Discord 的方法。
  • Claude 3.5 的代码纠纷Claude 3.5 间歇性出现的错误引起了轰动,而 Claude 3.0 则未受影响,这表明可能存在特定于模型的问题
    • 社区正在积极分享变通方法并等待修复,突显了工程领域协作调试的本质。
  • iOS 前端发现 OpenRouter 的乐趣:关于支持 OpenRouter 的 iOS 应用查询得到了推荐,Pal Chat 和 Typingmind 在修复 bug 后处于领先地位。
    • 寻找适合 OpenRouter 集成的多样化前端平台的参与度表明,移动 AI 应用生态系统正在不断壮大。

OpenAccess AI Collective (axolotl) Discord

  • Eager vs Flash:Gemma2 的注意力机制升温:训练 Gemma2 模型时推荐使用 Eager attention,在 AutoModelForCausalLM.from_pretrained() 中将设置修改为 ‘eager’ 以增强性能。
    • 为 eager attention 配置 YAML 文件得到了全面覆盖,为训练 Gemma2 以达到性能基准提供了细粒度控制。
  • 优化讨论:评估 Adam-mini 和 CAME:关于在 axolotl 中集成 CAMEAdam-mini 优化器的讨论非常热烈,主要围绕它们较低的内存占用和潜在的训练稳定性。
    • Adam-mini 作为 AdamW 在内存效率方面的竞争对手出现,引发了关于其在大模型优化中务实使用的讨论。
  • 衡量标准:数值精度优于文本描述:一位用户寻求在模型输出中优先考虑精确的数值响应而非解释性文本,思考使用加权交叉熵 (weighted cross-entropy) 来引导模型行为。
    • 虽然对这种微调 (fine-tuning) 方法的研究仍在进行中,但社区将加权交叉熵视为提高模型准确性的一个有前景的途径。
  • Gemma2 的微调挫折:应对巨大的梯度范数 (Gradient Norm):分享了关于 Gemma2 27b 的微调 (finetuning) 困扰,报告显示其 grad_norm 值很高,与 9b 等较小模型更平滑的训练体验形成对比。
    • 降低学习率 (learning rates) 和利用 ‘flash attention’ 是提出的解决 grad_norm 巨兽并缓解 Gemma2 训练情绪的方案之一。
  • ORPO 的硬性规则:训练必须成对:一位成员在为 ORPO 生成接受/拒绝 (accepted/rejected) 样本对时感到困扰,寻求确认训练数据中的每一行是否都需要这两者。
    • 社区共识强调了样本对生成在 ORPO 对齐 (alignment) 过程中的关键作用,并强调了其在实践中的复杂性。

LlamaIndex Discord

  • Llama-Leap 迈向微服务Mervin Praison 制作了一个深入的视频教程,介绍了全新的 llama-agents 框架,概述了高层概念和实际实现。
    • 该教程被广泛认为非常详尽,深入探讨了将 Python 系统转换为微服务的复杂性,社区对其涵盖的高级特性给予了高度评价。
  • 知识助手变得更聪明AI Engineer World Fair 展示了关于增强知识助手的突破性讨论,强调了需要创新数据模块来提升其效率。
    • 专家们主张转向更复杂的数据处理方式,这是从朴素 RAG 结构向下一代知识深化(knowledge deepening)迈出的关键一步。
  • 微软 Graph RAG 详解:微软创新的 Graph RAG Architecture 在社区引起了轰动,它被构想为一个灵活的、基于图的 RAG 系统。
    • 这一发布引发了专业人士的好奇和热情,许多人渴望剖析其在建模架构方面的潜力。
  • Pinecone 的元数据困境:在处理 DocumentSummaryIndex 信息时,Pinecone 的元数据限制引发了技术挑战,迫使一些人编写变通方案。
    • 这一排错过程引发了关于替代框架的广泛讨论,强调了 Pinecone 在元数据处理上的僵化,并激发了对动态元数据模式(dynamic metadata schema)的呼吁。
  • 聊天机器人:RAG 革命:AI 工程师探讨了开发基于 RAG 的聊天机器人,旨在利用 LlamaHub 的数据库读取器接入跨不同 SQL 和 NoSQL 平台的公司数据。
    • 对话开启了制定用户文本查询的策略,关于数据库路由的知识共享展示了社区协作排错的精神。

tinygrad (George Hotz) Discord

  • 图嫁接(Graph Grafting)取得进展:Tinygrad 的讨论集中在增强现有的 graph rewrite followup, speedup / different algorithm,目前尚未就首选算法达成共识。Egraphs/muGraphs 已被列入后续关注名单。
    • 尽管不是图灵完备的,成员们仍大胆支持基于规则的方法,因为它易于推理。同时,也有人呼吁在 graph rewrite 中嵌入更多算法(如 scheduler)。
  • 揭开 ‘image dtype’ 的神秘面纱Tinygrad 的 ‘image dtype’ 在代码库中无处不在却又显得神秘,引发了辩论;目前尚未记录消除它的具体行动。
    • 诸如“你尝试过移除它吗?”之类的询问在盘旋,讨论悬而未决,缺乏详细的探索或结果。
  • 错误信息的低语:Tinygrad 反复出现的错误 RuntimeError: failed to render UOps.UNMUL 强调了在 Tinygrad 迈向 v1.0 里程碑之际,迫切需要彻底改革错误消息机制。
    • George Hotz 认为这更多是一个 assert 问题,表示它“永远不应该发生”,而一位社区成员正准备通过一个带有失败测试用例的 PR 来解决此问题。
  • 内存混乱与梯度处理:热烈的讨论指出了 Tinygrad 在梯度累积期间的 CUDA memory overflow 问题,用户交流了诸如每步减少 loss 和管理梯度内存等策略。
    • Tensor.no_grad = True 成为 Tinygrad 在推理期间对抗梯度计算的利器,类似于 torch.no_grad();而 a = a - lr * a.grad 是目前的操作方式,因为 a -= lr * a.grad 会触发断言。
  • 文档困境需要深思熟虑:为了追求清晰度,Tinygrad 频道的参与者呼吁提供更丰富的文档,特别是涵盖 TinyJit 和细致的梯度累积等高级主题。
    • 随着开发者在创新与用户支持之间寻求平衡,制作全面指南和生动示例以照亮 Tinygrad 认知盲区的倡议得到了支持。

LangChain AI Discord

  • RAG 策略大比拼:HydeRetrieval vs. MultiQueryRetrieval:围绕检索策略的优劣展开了激烈讨论,HydeRetrievalMultiQueryRetrieval 互不相让。几位用户参与了对话,其中一位在使用 MultiQueryRetrieval 时遇到了结果为空的情况,引发了关于潜在回退方案(fallbacks)和修复方法的讨论。
    • 讨论延伸到了分片数据库(sharded databases)领域,一位求知者寻求实现此类系统的建议。大家分享了见解,并提到了 serverless MongoDB Atlas,但社区对于分片查询映射(shard-query mapping)的具体细节仍渴望更多信息。
  • API 愿景与文件上传查询:在 LangServe 领域,出现了一个关于将 fastapi-userslangserve 结合的难题,旨在通过用户特定逻辑保护端点。目前讨论区较为安静,尚无明确的指引路径。
    • 另一位 LangChain 爱好者寻求关于启用文件上传的指导,希望摆脱静态文件路径的限制。技术群体分享了代码片段和见解,但分步解决方案仍未完全明朗,依然笼罩在技术迷雾中。
  • LangChain 聊天机器人:行动 Agent:在 LangChain 开发者中,一项新任务是赋予聊天机器人预约演示和建立人工连接的能力。有人给出了回应,概述了使用 AgentsAgentDirector 的方法,并展示了通过 LangSmith 进行调试的潜力。
    • 随着对 Python 代码实现聊天机器人执行动作技能的需求增加,讨论进一步扩展。回应中包含了丰富的方法步骤和教程,为那些敢于为其数字作品启用动作功能的人提供了社区知识。
  • CriticGPT 的征程与 RAFT 的启示:OpenAI 的 CriticGPT 凭借一段视频揭秘走进聚光灯下,剖析了其优化 GPT-4 输出的方法,并提高了代码生成精准度的标准。敏锐的思想者吸收了这些智慧,思考着论文相关视频评测所标志的进步。
    • 前瞻者们并未停歇,深入探讨了 RAFT 方法论的深度,分享了学术文章,并将其与传统的 RAG 机制进行对比。一个关于使用 LLM 构建聊天机器人的协作号召广泛传播,公开邀请各方加入创新。

Latent Space Discord

  • Runway Revolution with Gen 3 Alpha:Runway 推出了 Gen-3 Alpha Text to Video,这是一个面向所有用户的高保真、快速且可控的视频生成工具。可以在这里体验,或在这里查看公告。
    • 社区进行的与 SORA 的正面对比突显了 Gen-3 Alpha 在即时可用性方面的独特优势,让人们得以窥见视频生成的未来。你可以在这里查看对比评测。
  • Sonnet Syncs with ArtifactsSonnet 与 Artifacts 的融合因提高了可视化和操作流程图的效率而受到赞誉,促进了更直观、更快速的设计工作流。
    • 爱好者们对这种能以思维速度合成视觉概念的能力表示赞赏,它消除了手动调整的繁琐,并简化了创作过程。
  • Figma Debunks Design Data Doubts:Figma 针对用户的担忧做出了回应,澄清其 ‘Make Design’ 功能并未在 Figma 的专有内容上进行训练,官方声明可见这里
    • 尽管 Figma 进行了说明,但社区讨论仍对输出中出现的识别度较高的元素(如 Apple 的天气应用)表示怀疑,引发了关于 AI 生成设计伦理的持续辩论。
  • Microsoft’s Magnified Phi-3 Mini:Microsoft 增强了 Phi-3 Mini,提升了其在代码理解和多语言支持方面的能力极限,以实现更高效的 AI 开发。在这里查看更新。
    • 改进涵盖了 4K 和 128K 模型,重点在于丰富上下文和结构化响应能力,预示着在代码细微理解方面的进步。
  • Magic Dev’s Market Magic:初创公司 Magic Dev 尽管缺乏具体的产品或收入,但其目标是实现雄心勃勃的 15 亿美元估值,这凸显了 AI 领域狂热的市场投机。详情见 Reuters 的讨论。
    • 这个由 20 人精干团队设定的估值目标,指向了 AI 投资领域的看涨趋势,并在缺乏坚实基本面的情况下,再次引发了对潜在泡沫的担忧。

Mozilla AI Discord

  • Llama.cpp 在轻量级硬件上运行?再想想吧:关于运行 llama.cpp 的讨论揭示,iPhone 13Raspberry Pi Zero W 都不符合成功运行所需的 64-bit 系统前提条件,特定的型号和内存规格至关重要。
    • 社区成员指出,尽管便携式设备很有吸引力,但像 Raspberry Pi Zero 这样的型号由于系统和内存限制而力不从心,这促使人们重新评估合适的硬件。
  • Llamafile v0.8.9 随着 Android 支持的加入实现飞跃:Mozilla 宣布 发布 llamafile v0.8.9,增强了 Android 兼容性,且 Gemma2 模型更贴近 Google 的框架。
    • 反馈称赞了该版本对 Gemma2 的对齐改进,根据公开评估,这表明它现在可以与更大的模型竞争。
  • 通过简单的开关修复 Mxbai 模型怪癖mxbai-embed-large-v1 模型的一个奇怪行为(对不同的文本输入返回相同的向量)通过将输入键从 ‘text’ 更改为 ‘content’ 得到了解决。
  • 探索大语言模型的硬件迷宫:AI 爱好者聚集在一起,为运行重量级语言模型确定最佳硬件配置,对话中 VRAM 容量和 CPU 内存 性能占据了主导地位。
    • 用户的实际见解倾向于将 3090/4090 GPU 用于主流用途,同时为那些追求极限的用户推荐 A6000/RTX 6000 工作站,强调了对有利硬件配置的尝试与平衡。
  • 模型训练中 CPU 与 GPU 的大辩论:对于模型训练,GPU 仍然是优于 CPU 的首选平台,这归功于它们的计算实力,正如多核 CPU 在处理大型模型时表现出的缓慢且不足的处理能力所证明的那样。
    • 关于 基于 CPU 训练 可行性的推测正在酝酿,社区使用 llm.c 训练 GPT-2 等模型的测试凸显了 CPU 在大规模学习应用中的明显局限性。

OpenInterpreter Discord

  • Windows 上的苦与乐:用户在 Windows 上构建 01 时遇到了挑战,piranha__ 寻找指导未果,但偶然发现了一个可能具有挽救意义的 Pull Request,该请求承诺更新安装指南。
    • 讨论中的 Pull Request 汇集了过去用户克服 Windows 安装难题的尝试,有望为未来的尝试扫清障碍。
  • 排除 OI 中的并发故障chaichaikuaile_05801 讨论了 OI 部署并发 和资源隔离的困惑,辩论了 OI 多实例 (Multiple Instances) 与其他上下文解决方案的优劣。
    • 交流中考虑了使用 .reset() 来规避代码共享障碍,结论是不同的实例可以避免共享 Python 执行环境带来的混乱。
  • OI 中的图像难题chaichaikuaile_05801 的一份恳切请求强调了通过 OI 的 MatPlotLib.show() 显示图像时面临的障碍,并引用了一个开放的 GitHub Issue,展示了版本之间的差异。
    • 随着用户在 0.1.18 和 0.2.5 版本之间切换,他们呼吁未来的版本加强图像返回功能,表明了对可视化改进的渴望。
  • 寻找高性能本地 AI Agentblurrybboi 正在寻找具有超越基础查询的网页搜索能力的本地 AI Agent,目标是那些能够从冗余信息中筛选出优质输出的 Agent。
    • 尽管发出了请求,但目前还没有收到回复,关于 AI Agent 在高级在线过滤方面的能力问题仍未得到解答。

Torchtune Discord

  • WandB 助力工作流:一位用户庆祝了他们成功微调模型 (finetuning a model),通过利用在线资源克服了对个人 GPU 的需求,并采用了 WandB 以获得更好的训练洞察。
    • 社区讨论得出结论,根据分享的 WandB logger 文档,精简 YAML 配置并采用 WandB’s logger 可以简化训练过程。
  • 评估 AMD 的 AI 表现:成员们交流了使用 AMD GPUs 进行 AI 开发的经验,尽管有些人在 ROCmtorchtune 上取得了成功,但仍推荐 NVIDIA 替代方案,详情见 Reddit 指南
    • 一位用户分享了他们在 6900 XT 上艰难但最终成功的历程,强调了社区在 AMD 硬件上对 torchtune 进行故障排除的支持。
  • 为 Torchtune 模型提供 HuggingFace 支持:有人询问如何将 torchtune 模型转换HuggingFace 格式,表明用户有意合并工具集。
    • 虽然没有讨论转换过程的具体细节,但参与者分享了命名规范和集成策略,展示了在模型兼容性方面的工程努力。

Cohere Discord

  • Cohere Toolkit 的多步处理奇迹:用户确认了 Toolkit 的多步处理能力 (multi-step capabilities),具有已启用的前端和后端支持,并分享了实际运行的示例。
    • 讨论还赞扬了 Sandra KublikSF AI Engineer 会议上的分享,并强调了 LLM-UNIVERSITY 频道 的关闭,引导用户前往 Cohere 的 API 文档以获取持续支持。
  • Slack Bot 的快速同步:一位用户创建了一个 Cohere Slack bot,表示其在工作区中非常易于使用,并得到了社区的即时好评。
    • 对话强调了快速模型处理的重要性,因为 Slack 对 bot 有 3 秒响应规则,突显了对响应式 AI 模型的需求。
  • 伦敦 AI 爱好者集会Cohere For AI 宣布将于 7 月 10 日在伦敦举行活动,重点关注多语言 AI (multilingual AI),包括闪电演讲和 Expedition Aya 的启动等精彩活动。
    • Expedition Aya 是一项旨在突破多语言 AI 模型界限的全球挑战,为团队提供独家资源、API 额度,并有机会因显著贡献赢得周边产品和奖品。

LAION Discord

  • 模型评估迷宫 (Model Evaluation Maze):一篇文章详细介绍了评估微调后的 LLM 进行结构化数据提取的复杂现状,强调了复杂的指标体系以及在没有可靠服务来维护评估的情况下过程的乏味。重点在于准确率指标和经常拖慢工作进度的隐藏代码层。
    • 用户强调了 LM 评估日益增长的挑战,理由是资源需求大以及随着时间的推移难以保持评估的完整性。没有分享额外的资源或图表。
  • phi-CTNL 的重大胜利:一篇开创性的论文介绍了 phi-CTNL,这是一个仅有 100 万参数的精简 LLM,展示了它在各种学术基准测试中的完美得分,以及类似于 grokking 的金丝雀预测(canary prediction)能力。该论文的摘要介绍了该模型实力的全部细节。
    • 这个基于 TransformerLLM 在专门策划的数据集上进行了预训练,因其能够以极高的精度预测评估基准而脱颖而出,引发了 AI 工程社区关于这种灵活而强大的模型潜在应用的讨论。
  • AIW+ 问题被破解:一位用户展示了 AIW+ 问题正确解法已获验证的证据,建议使用图表来展示经过正式检查的答案。他们引用了 Claude 3 Opus 模型的准确回答作为验证。
    • 该解决方案的确认引发了关于问题陈述中所使用的假设及其如何直接影响结果的讨论。研究人员被敦促仔细检查支撑这些 AI 谜题的逻辑。
  • Terminator 架构师:提出了一种名为“Terminator”的新模型架构,通过消除残差(residuals)、点积注意力(dot product attention)和归一化(normalization),彻底背离了传统设计。
    • Terminator 模型在社区中被分享,并为那些有兴趣探索其独特结构和对模型开发潜在影响的人提供了论文链接。

LLM Finetuning (Hamel + Dan) Discord

  • Chainlit 打造音频解决方案:一位 AI 工程师将用于语音检测的 SileroVAD 与用于转录的 whisper-fast 相结合,并通过 Chainlit 语音助手示例 为同行提供建议。还评估了 elevenlabs (turbo)playhtdeepgramTTS 替代方案,以优化音频工作流。
    • 进一步的讨论围绕知识图谱以及 Lang GraphAI 中的利用展开,社区成员积极寻求将图技术嵌入 AI 系统的更深层见解。
  • Dask 深入数据维度:在处理大型数据集(特别是来自 USPTO Kaggle 竞赛的数据)时,使用 Dask 导致了内存溢出 (OOM) 错误。讨论转向了使用 Modal 高效执行 Dask 作业的策略,旨在管理海量数据。
    • 一位从业者向小组询问了在 Modal 上运行 Dask 作业的成功案例,暗示了 Modal 在更好地适应高需求计算工作负载方面的潜力。
  • Autotrainer 还是别的?这是个问题Autotrainer 的角色受到质疑,不确定它是属于 Axolotl 的功能还是 Huggingface autotrain。社区正努力确定其归属。
    • Autotrainer 的来源仍不清楚,至少有一位成员寻求澄清,并在调查后推测其与 Huggingface autotrain 有关。
  • OpenAI 的慷慨引发愧疚感OpenAI 的定价在用户中引起了幽默与愧疚交织的情绪,有人感叹无法在提供的 3 个月期限内用完其 $500 额度
    • 另一位成员也表达了这种情绪,他风趣地使用了倒脸表情符号来表达对这种低消耗额度的复杂心情。
  • 幻灯片支线任务:围绕视频幻灯片的位置展开了对话——Remi1054 和 jt37 等成员正在搜寻通常托管在 Maven 上的难以找到的演示材料。
    • 搜寻仍在继续,hamelh 表示并非所有演讲者(如 Jo)都会轻易分享他们的幻灯片,这迫使从业者直接请求访问权限。

AI Stack Devs (Yoko Li) Discord

  • Hexagen.World 揭晓新地点:来自 Hexagen.World 的全新地点(locations)已推出,为用户扩展了数字地形。
    • 该公告引发了成员们对这些 Hexagen.World 新增内容的潜在用途和开发的兴趣。
  • AI Town 停靠 Docker 之岸:社区呼吁提供 AI Town 的 Docker 适配,讨论了增强便携性和简化设置的好处。
    • 一位积极的成员分享了一个 GitHub 指南,用于在 Windows 上使用 WSL 设置 AI Town,并建议将其集成到主仓库中。

Interconnects (Nathan Lambert) Discord

  • Apple 潇洒夺得 OpenAI 席位Phil Schiller 将作为观察员加入 OpenAI 董事会,使 Apple 在旨在增强其 Apple Intelligence 产品的战略合作伙伴关系中占据优势,详见此处
    • AI 社区反应热烈,Microsoft 的巨额投资与 Apple 的精明举动形成鲜明对比,引发了关于 Microsoft 劣势的辩论和一些幸灾乐祸,如此讨论所示。
  • 科技巨头在 OpenAI 关系上展开角逐:社区对话深入探讨了 OpenAI 合作伙伴关系的业务动态,审视了 Apple 获得观察员席位与 Microsoft 直接财务投资相比的战略胜利。
    • 见解和嘲讽贯穿于讨论中,参与者将“观察员席位交易”比作一场国际象棋比赛,Apple 以极小的支出实现将军,而 Microsoft 的巨额支出既引起了旁观者的钦佩,也引发了笑声。

Datasette - LLM (@SimonW) Discord

  • 网络以智慧取胜Be Better, Not Smaller 分析了早期移动互联网服务(如 WAP)的失误,将其比作现代 AI 产品。它解释了 iPhone 时代之前移动浏览的局限性,并为当前产品提出了更好的方法。
    • 文章鼓励当前的 AI 开发者优先考虑提升用户体验,而不仅仅是适应更小的平台。移动浏览曾经就像是“通过钥匙孔窥视互联网”
  • 政府礼品引人注目:一篇 Scoop 文章 揭示了美国官员从外国实体收到的各种不寻常礼品,例如鳄鱼保险金牌
    • 它讨论了这些礼品在数据管理方面的困难,指出它们通常是非结构化格式且存在存储问题,这反映了政府数据处理中更大的问题。“这些外国礼品确实就是数据。”

第 2 部分:按频道划分的详细摘要和链接

为了便于邮件阅读,完整的逐频道明细已被截断。

如果您想查看完整的明细,请访问此邮件的网页版:

如果您喜欢 AInews,请分享给朋友!预谢!