最新

我正在进行一个项目，需要动态生成简单的图标和图表。我尝试过GPT-4和Claude，它们可以输出SVG代码，但结果有时好有时坏，尤其是对于基本形状以外的内容。 有没有人找到可靠的工作流程？我在想是否有专门的模型、更好的提示技巧，或者我是否应该直接使用传统的图形库，完全跳过大型语言模型的路径。你们在实际生产中使用的是什么有效的方法？

英特尔®侧带技术 英特尔服务器可管理性接口概述 英特尔®局域网接入部门 法律声明 本文件中的信息与英特尔产品相关提供... BunnyPeople、Celeron、Celeron Inside、Centrino、Centrino 标志、Chips... 英特尔、英特尔标志、Intel386... Xeon Inside 和 Xircom 是英特尔的商标或注册商标。 https://cdrdv2-public.intel.com/321786/sideband-technology-appl-note.pdf

几周以来，我一直收到冒充Gmail的垃圾邮件。这些邮件总是包含指向 https://storage.googleapis.com/rightsmoves/... 的链接。邮件的样子是这样的：<p>https://imgur.com/xyXfPI8<p>甚至连谷歌自己的Gemini也知道这是个骗局：<p>&gt; URL https://storage.googleapis.com/rightsmoves/ 指向一个名为“rightsmoves”的特定Google Cloud Storage存储桶。根据最近的安全数据和网页扫描，这个存储桶与恶意活动有关，特别是网络钓鱼和“流量窃取”计划。<p>我已经通过Google Cloud Platform的滥用报告表单多次举报，但他们对此置之不理。<p>这是谷歌的完全无能吗？为什么他们会允许自己域名下的骗局存在？

嗨，HN， 最近我一直在处理大量的法规文件，有一件事让我感到困扰。常规的RAG（检索增强生成）管道往往无法将相关的文章一起检索出来，即使它们通过引用、定义或条款明显相关。 在尝试了几种RAG设置后，我主观上觉得GraphRAG是处理这类数据的更好思维模型。微软的GraphRAG论文和参考实现为我提供了很好的起点。然而，在实际操作中，我发现一个反复出现的问题：图形存储和向量索引通常由不同的系统处理，这对于短期分析任务来说显得过于繁重。 为了探索这种权衡，我构建了GibRAM（图形内存检索与关联记忆）。这是一个实验性的内存中GraphRAG运行时，其中实体、关系、文本单元和嵌入在一个进程中并存。 GibRAM是故意设计为短暂的。它旨在用于探索性任务，如在有限文档集上进行摘要或对话查询。数据存储在内存中，按会话范围划定，并通过TTL自动清理。没有持久性保证，重新计算被认为比持久化更便宜，适用于预期的使用场景。 这不是一个数据库，也不是一个生产就绪的系统。它是一个随意的项目，主要是基于感觉编码，旨在探索当内存是主要限制而不是存储时GraphRAG的样子。技术债务是存在的，许多权衡是显而易见的。 该项目是开源的，我非常欢迎反馈，特别是来自从事RAG、搜索基础设施或基于图形的检索的人的意见。 GitHub: [https://github.com/gibram-io/gibram](https://github.com/gibram-io/gibram) 很高兴回答问题或听取关于这种方法可能存在缺陷的意见。