使用 Python 这种动态语言进行 web 开发，团队中经常会遇到的问题就是代码的质量比较难控制。Python 语言本身灵活性比较高，不加控制的情况下代码质量可能最后很难维护。而且代码的各方面的标准，比如提示的 lint，代码格式化等等如果不加规范，不同开发者的协作也会比较困难。因此从公司角度来看，一个统一的代码规范是很有必要的。在 Python 的开发过程中，可以选择公司希望遵循的 Pytho

接触过大模型应用开发的研发同学应该都或多或少地听过 Dify 这个大模型应用基础服务，这个项目自从 2023 年上线以来，截止目前（2024-6）已经获得了 35k 多的 star，是目前大模型应用基础服务中最热门的项目之一。这篇文章对 Dify 中核心的基础模块 RAG 服务进行深入解读，后续可能会更新其他模块的内容。Dify 是一个LLMOps服务, 涵盖了大语言模型（如GPT系列）开发、部署

最近抽空参加了一个讯飞的 RAG 比赛，耗时两周终于在最后一天冲上了榜首。整体的框架是基于 RAG 能力有点弱弱的 Dify 实现。在比赛调优的过程中，经常需要批量提交几百个问题至 Dify 获取回答，并需要跟踪多轮调优的效果差异。借助 Langfuse 可以通过网页跟踪结果，相对比较方便了很多。但是现有版本的 Langfuse 不支持提交文件构建数据集，私有化部署的版本也不支持自动化评估，多版本

众所周知，大模型应用的输出存在着一些不确定性，往往需要迭代多轮才能得到较为稳定的输出结果，因此开发者往往需要关注大模型应用的实际表现，并进行有针对性的优化。然而常规 Web 服务的监控机制往往无法满足大模型应用的监控需求，因为大模型应用往往关注的不仅仅是响应延迟、吞吐量等基础指标，而是需要关注大模型应用输出的语义正确性。因此，本文将介绍如何借助 Dify 和 Langfuse 工具，展示如何为大模

在之前的软件应用中，我们总会在应用中保留大量的用户历史操作记录，方便用户下次使用时可以快速查看和复用，甚至基于这些用户记录可以为用户提供个性化的服务。而这些记录往往都保存在传统的结构化或非结构化数据库中。在大模型的应用，特别是助手类的大模型应用中，我们往往需要处理大量语义化的文本或多模态的信息，方便后续快速匹配，从而提供个性化的服务。为了支持这种语义检索的需求，往往会将数据保存至向量数据库中。向量

接触过大模型应用开发的研发同学应该都或多或少地听过 Dify 这个大模型应用基础服务，这个项目自从 2023 年上线以来，截止目前（2024-6）已经获得了 35k 多的 star，是目前大模型应用基础服务中最热门的项目之一。这篇文章对 Dify 中核心的基础模块 RAG 服务进行深入解读，后续可能会更新其他模块的内容。Dify 是一个LLMOps服务, 涵盖了大语言模型（如GPT系列）开发、部署

在构建大模型知识库，即检索增强生成 (RAG) 服务时，中间存在一个核心环节就是向量化搜索，如果不希望引入第三方的向量数据库，那么开源的 Faiss 就是一个不错的选择。Faiss 是 FaceBook 提供的开源向量库搜索库，在Github上已经有 28.1k star，相对成熟而且使用方便。之前构建的 RAG 服务使用的就是 Faiss 提供的向量化搜索服务，Faiss 功能强大，上手简单。但

之前在 GPU 服务器上部署了Dify 服务，使用的是 Dify 与 Xinference 组合，Xinference 部署的大模型是。基于本地部署的服务构建了知识库，并利用首页提供的任务流模板创建了一个 RAG 工作流知识库检索环节预期不需要调用大模型，实际却调用了大模型；本地没有配置 GPT3.5, 为什么会选择 GPT3.5 模型；这篇文章就从问题出发，借助源码与对应的服务 API 请求信息

自 2024 年底以来，行业不断有人喊出"2025 年 Agent 元年"的口号，不少大模型公司也开始调整战略方向，纷纷布局 Agent 领域。然而，大半年过去了，Agent 仅在有限领域实现了落地，在更多严肃的应用场景下，Agent 产品的落地效果并不理想。在新项目中持续进行 Agent 相关产品的开发落地，在探索过程中发现了 Agent 落地的一些关键障碍。结合最近解决问题时整理的资料以及个人

在之前的文章Agent 落地经验分享（一）中，介绍了 Agent 落地中存在的问题，并给出了一些初步的解决方案。在这篇文章中，针对 Agent 落地中的关键问题，给出更进一步的实战经验，希望对大家的 Agent 产品落地有所帮助。本文主要参考自。本文梳理了来自 humanlayer 的 12 条 Agent 构建经验。对我而言，最重要的启发是保持对 Agent 的“可控性”：避免将任务完全委派给大