1作者: jongwony24 天前原帖
AI 编程助手通常会假设用户的意图并直接执行。有时这样做很快;但往往意味着花更多时间在撤销操作上,而不是实际执行。<p>Epistemic Protocols 是一个 Claude Code 的插件,它在不可逆操作之前、存在多种方法时或意图可能被误解时插入决策检查点。<p>三个协议: - /lens — 在分析之前,让你选择视角(性能、操作复杂性、数据模型适配等) - /gap — 在决策点,提出潜在的差距作为问题 - /clarify — 当你的请求可能模糊时,帮助明确意图<p>原则:AI 照亮选项;你来选择。识别优于回忆——从明确的选择中选择胜过猜测。<p>GitHub: <a href="https://github.com/jongwony/epistemic-protocols" rel="nofollow">https://github.com/jongwony/epistemic-protocols</a><p>示例: ``` &gt; /lens "我应该使用 Redis 还是 PostgreSQL 作为这个缓存?" ``` Claude 显示出视角(性能、操作复杂性、数据模型适配……)。你选择重要的内容,然后它通过这些视角进行分析。
2作者: rabinovich24 天前原帖
archive.today 最近(我大约三天前注意到的)开始自动向某个人的博客的 CAPTCHA 页面发起请求。以下是我所说内容的截图:https://files.catbox.moe/20jsle.png 相关的 JavaScript 代码是: ```javascript setInterval(function() { fetch("https://gyrovague.com/?s=" + Math.round(new Date().getTime() % 10000000), { referrerPolicy: "no-referrer", mode: "no-cors" }); }, 300); ``` 查看这个博客,似乎只有一篇文章提到 archive.today——“archive.today:追踪互联网神秘游击档案员”(https://gyrovague.com/2023/08/05/archive-today-on-the-trail-of-the-mysterious-guerrilla-archivist-of-the-internet),在这篇文章中,博客的作者挖掘了一些关于 archive 拥有者的信息。 所以这或许是一种报复/拒绝服务攻击尝试/故意浪费他们带宽以回应这篇文章?也许是试图让他们沉默并迫使他们删除文章?但如果真是这样,我有很多疑问。比如,为什么 archive 的拥有者会在文章发布 <i>2.5 年</i> 后才这样做?或者他们为什么会这样做,他们难道不知道斯特赖桑效应吗? 我很困惑。
9作者: arsentjev24 天前原帖
请访问以下链接: [https://github.com/stepandel/chroma-explorer](https://github.com/stepandel/chroma-explorer)
1作者: synsqlbythesea24 天前原帖
在进行机器学习特征工程和多组学数据处理时,我遇到了一个实际限制。 在某个时刻,问题不再是“有多少行”,而是“有多少列”。列数从几千到几万,有时甚至更多。 我在实践中观察到: - 标准SQL数据库通常限制在大约1000到1600列。 - 像Parquet这样的列式格式可以处理宽度,但通常需要Spark或Python管道。 - OLAP引擎速度很快,但通常假设相对较窄的模式。 - 特征存储通常通过将数据拆分为连接或多个表来解决这个问题。 在极宽的情况下,元数据处理、查询规划甚至SQL解析都会成为瓶颈。 我尝试了一种不同的方法: - 不使用连接 - 不使用事务 - 列分布而不是行 - 将SELECT作为主要操作 通过这种设计,可以在具有数十万到数百万列的表上运行原生SQL选择,并且在访问部分列时具有可预测的(亚秒级)延迟。 在一个小集群(2台服务器,AMD EPYC,每台128 GB内存)上,粗略的数据如下: - 创建一个100万列的表:约6分钟 - 插入一个包含100万值的单列:约2秒 - 在约5000行中选择约60列:约1秒 我很好奇这里的其他人是如何处理超宽数据集的。你们是否见过在这种宽度下能够顺利工作的架构,而不需要依赖繁重的ETL或复杂的连接?