英国政府数字服务发布了一个基于Claude3的“无代码”表单工具，手绘表单然后识别为真正可用可交互的表单。

github.com

Vox这篇文章介绍了现在外国亚马逊的电子书商店被AI自动生成的垃圾书充斥的情况，不过这产业链背后最赚钱的不是靠卖书，而是靠教人做垃圾书来赚钱，割韭菜的形式确实是不分国界。

www.vox.com

在huggingface.co体验了一把llama3，对中文的支持不错，甚至还能知道鲁迅为什么不能打周树人，可惜上下文窗口只有8k，按当前的标准来看其实是有点偏低了

利用RAG的漏洞进行Prompt注入攻击一例，连谷歌也未能幸免。

embracethered.com

编程AI助手Cody在他们的博客上分享他们怎么用大模型来做代码补全的产品实现思路和实践经验，有各种细节和应对LLM各种奇奇怪怪的问题的方法，还是很有启发的。

sourcegraph.com

“在我看来，人们容易陷入麻烦的地方在于试图将RAG视为解决搜索问题的解决方案，而不是认识到RAG需要有用的搜索作为其实现的一部分。有效的RAG方法取决于高质量的检索和过滤机制，大规模下能够良好地工作。例如，对于RAG的高层视图，有些人可能认为他们可以用RAG替代他们的搜索技术（例如Elasticsearch），但只有在您的数据集非常小且可以容忍更高的响应延迟时才成立。

“从我的角度来看，挑战在于大多数抄近路的解决方案看起来好像是在处理小数据集，同时让你假装搜索相关性之类的事情不重要，而实际上，当你超越原型阶段时，相关性会显著影响响应质量（无论是文字搜索相关性还是更好调整的 SQL 查询以检索更合适的行）。这会产生一个关于原型如何转化为生产能力的错误期望，带来可预测的后果：低估时间表、生产行为/性能差等。”

lethain.com

OpenAI现在给Batch API打了五折，这个Batch API就是一次性把大量的请求打包发送过去获取结果——唯一的问题是没有实时返回，只能保证24小时内完成。想了下，某些实时性要求没那么强的场景或许能省下不少的成本，例如像微信读书那种AI大纲，或者像Cubox那种幻影解读（尽管我个人一向对这种总结类用例的价值存疑）

twitter.com

不过日常个人使用的API，那还是白嫖的GPT3.5香 github.com

之前使用【沉浸式翻译】都主要使用谷歌翻译服务，最近开始尝试主力使用GPT3.5（API)，在“信达雅”的雅方面，后者翻译的效果的确更加流畅自然，但在“信”的方面，还是经常会发现不如谷歌的地方，经常会出现翻译错误，经常使用的同学也要稍微注意一下，如果不是双语对照我也不一定能发现问题。

下面是两例，单数张是GPT3.5，划线出来是翻译错误的地方，偶数是谷歌翻译，对应的翻译才是对的。

一篇不错的解释embedding的入门文章，既有原理也有实操示例。

又一例