V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  CodeCaster  ›  全部回复第 1 页 / 共 1 页
回复总数  11
6 小时 0 分钟前
回复了 CodeCaster 创建的主题 Java 使用 Java 写了一版 LangChain,想听听大家的意见
@JrD 我上面提到的 Python 的工程性比较差,这个是相对 Java 语言的,所有语言都可以通过“开发规范、架构设计、review 等问题来保证”,对不对?只是这么做的成本不同语言是不一样的吧? Java 是公认的工程性比较好的语言,Python 的确灵活性更强,相对的,工程性比 Java 差了不少。

感谢讨论,但是我也表达我的观点,我并不是想针对编程语言引战,我希望这个讨论可以相对客观的来看。Java 和 Python 各有特点,也都各有不足之处。
6 小时 5 分钟前
回复了 CodeCaster 创建的主题 Java 使用 Java 写了一版 LangChain,想听听大家的意见
@xiaomushen 不好意思,我不太明白你的重点讨论点是什么?我同意你说的“做应用,各种语言都可以”,但是我不太明白我上面提到的哪句话让你产生了“就好比大部分数据库都是 C 开发的,难道说,C 语言是做基于 DB 应用的首选?”这样的反问呢?谢谢指出,欢迎讨论
17 小时 19 分钟前
回复了 CodeCaster 创建的主题 Java 使用 Java 写了一版 LangChain,想听听大家的意见
@sighforever 明白你的观点,也感谢你的支持~但是对于其中的一点,就是“实在没必要在 python 以外的语言上整和 AI 相关的事儿”我觉得这个有待商榷。

我的观点是这样的:当前的事实是,从事 AI 工作的人使用 Python 的最多,Python 方面的 AI 库又多又方便,至于运行的快不快的确不是一个关键点,关键点在于 Python 语言的工程性非常差,而这个工程性差直接导致了,遇到问题难以调试,一旦实际生产遇到一个问题,排查的成本是完全会掩盖之前快速开发的成本的。还有一点就是安全性,Python 语言实在太灵活,导致有很多很多黑科技可以改变语言本身的运行逻辑。当前 AI 实在太火,大多数人又都是“好人”,以至于所有人都忽略了其潜在的风险(之前某大厂大模型投毒事件就是一个真实的例子),所以选择一个工程性非常优秀的语言来做 AI 相关的事情并不是没有必要的。

最后,还是感谢你的支持~
20 小时 31 分钟前
回复了 CodeCaster 创建的主题 Java 使用 Java 写了一版 LangChain,想听听大家的意见
@wyntalgeer 感谢你的意见,但是我们团队还是会坚持的。我这里说明一下,我们开源的这个项目,在写之前,并不是没有调研行业周边,而是看了其他框架,设计的思路的确不一样,上面也列出了几个特别的点。

除了这个和 LangChain 比较类似的模块外,我们还有其他几个模块,同样设计理念和业内其他框架不同,比如底层还有一个插件化的编程框架(借鉴 OSGI 的思路)等。我们开源的目的是希望将我们觉得好的东西分享给所有人,在大家的意见之下不断去完善。哪怕能给大家带来一点点思考,也是有价值的。

感谢
@INCerry 不好意思,这个软件我之前没有听说过,我刚刚去大致搜索了一下,感觉像是编排模型相关的。因为没有做过任何比较,所以不太好评论。但粗略感觉,我们应该不是在一个层次上的。抱歉
@Suger828 这位同学对响应式还是挺有研究的,这个可以好好讨论一下。个人观点,流式处理+异步回调不完全等同于响应式,但是响应式里面包含了流式处理和异步回调的内容。

我们来看一下响应式编程的定义:“响应式编程( Reactive Programming )是一种以 数据流 和 变化传播 为核心的编程范式,其核心是通过 声明式 的方式构建异步、非阻塞且具备弹性的数据流处理管道。”

通过以上定义,可以看到,响应式会处理数据流,存在流式处理,后面提到需要声明式的方式( map 、filter 、reduce 等算子方法)以及弹性的数据流处理(背压机制进行流量控制),所以,响应式的范围应该更大一些。

欢迎讨论~
@lower 这个想法非常好呀,感觉大家都在这个方向思考,其实我没有介绍我们低代码部分,篇幅限制,我重点先介绍了一下我们高代码部分。实际上,我们的低代码编排部分也在开源进程中,大概再过 2 个月左右,也会在我们的社区出现,的确也有一套前端组件~欢迎持续关注
@ReinerShir @clf ,非常感谢二位的提醒,我去大致看了一下 LangChain4J 项目的样例,这个项目拥有很多 Star ,的确是一个优秀的项目,但是我们的版本(我们这个模块叫 FEL ,项目整体叫 FIT ,这里是 FIT Expression for LLM 的缩写)相比之下还是有一些特点的:

1. 我看 LangChain4J 主要是流式处理+异步回调,而我们是采用了响应式编程,这意味着我们可以在编排的 AI 应用的任意节点间增加背压;
2. 我们在响应式的基础上增加了 BPM 的相关方法,比如支持并发流、条件判断等,这对于流程编排来说,更自然的在编码级别进行了支持。

非常欢迎讨论交流,我们也会吸取其他框架的优点,欢饮关注点 Star ,推动我们继续~
@lower 有的,其实上面的第二段代码 retrieveFlow 就是这方面的,我们社区的 example 中关于 fel 的部分例子就有,那边可以看代码和文档。不过因为我们现在刚刚开源,对于生态的一些支持还有限,打算接下来会像 LangChain 一样,对生态内容进行补齐,这样,开发者就比较方便实用了~
@wellCh4n 非常感谢支持,因为这部分代码还是比较多的,可以后面空了好好看一下~
微服务接口变化,而造成的调用方也要发生改变,最常规的解决方案,就是老的接口先不变,新增一个全新的接口,所有调用方根据自己的升级节奏逐步升级到新接口,待全部调用方都升级完毕之后,再将老接口下线。
其实,上述问题在微服务体系中非常常见,我觉得这个问题就是微服务架构这种模式造成的,因为不同的微服务本质上是离散的不同个体,他们之间的调用就是他们之间的强依赖关系,既然是强依赖,那么被依赖方发生改变,必然会造成依赖方要随之改变,这种变化是会传播的。
看到了微服务具有这样的问题,其实再看看过去的传统单体应用,调用方和被调用方都在一个进程中,这个时候,服务提供方发生改变,我们随手把调用方代码一起改了就完事了,根本不会有这样的问题,因为其实调用方和被调用是一个整体。
所以,这个问题,我觉得,没有什么更好的方案了,既然选择了微服务,就需要正视这样的问题存在,选择最常规最稳妥的解决方案吧。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5106 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 09:26 · PVG 17:26 · LAX 01:26 · JFK 04:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.