@TimePPT 还有，绑定手机号是有关部门规定，强制实行也十多年了，跟大模型也没啥关系。反而是，有司现在要求各家 LLM 加明水印、暗水印，方便回溯来源影响会更直接。

对广告推荐来说，从你问大模型问题里挖掘喜好搞广告，还不如你刷小红书/抖音 feed 流点击查看的反馈收集来得直接。
以及，就算输入 Query 分析的用户画像，Google / 百度都做了十几二十年了。又不是 LLM 时代才有的新鲜玩意。

不做 AI 开发的没必要知道底层原理，尽可能的在工作生活中用就行，擅长使用工具没必要都去知道工具底层是啥。

打个比方，Google ，百度这种搜索引擎出来二十多年了，不专业搞这块的。有几个人学过底层检索算法？甚至用 ES 做文本检索的都没几个。

如果要做相关 AI 应用开发的，至少知道些基本概念和算法原理也就差不多了。

这种没办法，几年前流行学 python 时，前同事阿里技术 P8 ，他老婆买了 python 编程基础课，也 2000 多块吧……

@beyondgamp 谢谢！用的索尼 a7r5 ，配 24-70GM2

@TimePPT 如果是特别垂的古诗词古文生成，还需要做一些领域微调，效果才能好

@grimpil 如果是通用的文言文和诗词创作，其实中文预训练过的大模型本身就不错，你如果想仿作，要的是把想仿的诗词古文作为范例放在 prompt 里，这时候用 RAG 没问题，但单纯做文本检索或向量检索是不够的，最好是有一些额外的索引 tag ，比如「怀古」，「咏物」这种

没明白你啥需求，文言文翻译？

@code0611 大公司做业务 LLM 部署和应用部署都是微服务多些，业务逻辑层如果需要配置单抽出来做配置中心多些，dify coze 这种低代码可视化配置都是纯运营托管的场景才用的多，但大多数场景根本不会有专有运营天天整 workflow

这个也不是我说的，基本上是业界共识，Anthropic 官方 Agent 指南里也提到了类似观点
Building effective agents
https://www.anthropic.com/research/building-effective-agents

When and how to use frameworks
There are many frameworks that make agentic systems easier to implement, including:

– LangGraph from LangChain;
– Amazon Bedrock's AI Agent framework;
– Rivet, a drag and drop GUI LLM workflow builder; and
– Vellum, another GUI tool for building and testing complex workflows.

These frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create extra layers of abstraction that can obscure the underlying prompts ​​and responses, making them harder to debug. They can also make it tempting to add complexity when a simpler setup would suffice.

We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code. If you do use a framework, ensure you understand the underlying code. Incorrect assumptions about what's under the hood are a common source of customer error.

See our cookbook for some sample implementations.

运营还是开发？应用开发小公司 dify ，langchain 会问。大公司即使做 LLM 应用开发，但如果不是专门做 Agent 平台开发的基本不会问这块，因为生产环境基本不用这些。

对于 2：
func-call 跟一般监督微调的过程没啥区别，难点在于数据准备：至少要求包含场景、func 定义、预期调取的 func ，预期回复等。
面向业务的 func-call 相对好做，有业务场景，人工构造一些基本就够用。
但通用 func-call 模型就需要有大量的 api 定义和场景测试数据。

但做好其实都不容易，比如函数功能相似，会出现无法精准召回等问题。
还有 input 槽位信息缺失，需要多轮收集，LLM 要知道会话状态等，都需要很多工作要做。

如果没有特殊需要，建议直接调取通用 func-call 能力的 LLM API ，或者市面上有些开源的通用 func-call 模型，自己拿来用，或者再继续微调一下适应自己业务。

playwright+无头浏览器，解决 80%问题

公司活，一般都是自己写，这些工具极少有公司直接上生产的。自己独立开发或者随便玩玩，选个顺手的就行

东京确实不错，去年在东京住了半个多月，印象很好。

京都的话，各类小巷子什么的也很好逛很好拍。走走逛逛很休闲。
拍二年坂三年坂清水寺附近这种热门景点，想出片，建议找晴天早上八点前去。人多拍出来就游客打卡照了。
天气好了，鸭川沿岸可以走走，能感受到当地人的闲适。
如果喜欢和咖啡吃甜点，京都有很多不错的小咖啡馆，走累了可以调一个顺眼的 walk in ，基本不踩雷。

@nicelixin 是的，特别是罗马，佛罗伦萨，米兰这种传统旅游城市。有机会还要去😁

@smlcgx 是的，特地在许愿池许了愿，再次回到罗马😄

@WizardLeo 哈哈估计是因为我拉高了对比度，降低饱和度，做了一些全局和局部的色彩调整。其实应该都没有过曝。整体还是偏暗和中间调子多一些