Havenask是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎，深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了Havenask的消息系统--Swift，它是一个设计用于处理大规模的数据流和实时消息传递的高性能、可靠的消息系统。
随着LLM技术应用及落地，数据库需要提高向量分析以及AI支持能力，向量数据库及向量检索等能力“异军突起”，迎来业界持续不断关注。简单来说，向量检索技术以及向量数据库能为 LLM 提供外置的记忆单元，通过提供与问题及历史答案相关联的内容，协助 LLM 返回更准确的答案。 不仅仅是LLM，向量检索也早已在OLAP引擎中应用，用来提升非结构化数据的分析和检索能力。ByteHouse是火山引擎推出的云原生数据仓库，近期推出高性能向量检索能力，本篇将结合ByteHouse团队对向量数据库行业和技术的前沿观察，详细解读OLAP引擎如何建设高性能的向量检索能力，并最终通过开源软件VectorDBBench测试工具，在 cohere 1M 标准测试数据集上，recall 98 的情况下，QPS性能已可以超过专用向量数据库。
本文旨在探讨字节跳动数据平台在处理计算治理过程中所面临的问题及其解决方案，并展示这些解决方案带来的实际收益。主要内容包括：探讨面临的痛点和挑战、提供自动化的解决方案、分析实践效果和收益、提出结论和未来展望。
最新越发觉得AI的发展，对未来是一场革命，LangChain已经在工程设计上有了最佳实践，类似于AI时代的编程模型或编程框架，有点Spring框架的意思。之前在LangChain上也有些最佳实践，所以在这里分享记录下。
在实际工作中，我们经常会遇到一堆数据，对数据的有效分析至为关键，而数据的分布就是一种非常重要的数据属性，需要通过合适的可视化手段进行分析。本文参考[1]，基于seaborn库介绍一些常用的数据分布可视化方法。
在 B 端研发过程中，产品原型在产品需求文档中起着重要的作用。然而，在实际的开发过程中，我们发现了一些问题。首先，在需求评审阶段，有些产品需求文档可能缺少原型或者原型与研发团队的规范不一致，这需要研发同学与产品同学沟通补充原型图或者按照研发团队的规范进行绘制，这增加了产品同学和研发团队之间的沟通成本以及增加了产品同学的学习成本。其次，在业务验收阶段，开发的页面或效果可能不符合业务侧的期望，这又需要产品和研发团队反复沟通，导致业务侧对效果的感知链路过长。此外，产品同学还需要花费大量时间来根据需求文档描述输出样式固定的原型文档。 为了解决这些问题，我们想到了利用产品在『市场需求文档（MRD）——产品需求文档（PRD）——页面（Page）』沟通过程中沉淀的『共识』，即产品需求文档中的页面描述。我们可以利用大语言模型强大的推理能力，将这些共识『翻译』成符合研发团队规范的页面，从而减少沟通成本并缩短业务侧对效果的感知链路。另外，为了减少产品在不同界面切换频次，可以让产品利用浏览器插件在 PRD 文档页面进行文字选择，然后唤起原型生成工具生成页面原型和修改原型。本文主要介绍了我们利用大模型辅助产品
随着AI技术的发展，越来越多的产品尝试结合AI进行功能升级，作为设计师的你是否也在面临这样的问题：如何将AI技术与场景需求更好的结合，为用户提供顺畅的AI原生设计体验呢？ 本文将以AI装扮项目为例，分两部分介绍我们是如何通过深入分析用户痛点与需求，结合公司内部能力支持，找到AI创新突破口。同时发挥设计优势，在没有行业参考前提下，探寻出一条AI创新实践之路，设计主导创新方案优化落地。
