热门景点尽量避开周末，需要预约的景点提前点定。
北京除了二环内景点聚集那片，其他景点离得都不近，带老人旅游别排太满，两点距离地铁公交单程超过 1 小时的这种，都尽量错开。

从一开始就不要把涉密信息硬编码到代码里，这跟使用不使用大模型无关，是一种良好的代码安全意识。

生快！

@xiaohupro 不用客气，也不是啥普及，只是感觉最近拿着大模型锤子找钉子的人越来越多了😂

另外补充下，我第一条想表达其实是，虽然大模型能获取到更多用户主动发送的信息，但其实，这种挖掘并没有比传统方法高到哪里去。
主要原因也还在：
1. 和 LLM 对话的信息量级远少于在线推荐系统的反馈，也就是说，这类特征更加稀疏——从使用频次、时长上来说都是这样。
2. 非结构化数据挖掘整理到结构化，这个成本比直接的结构化数据要高。
3. 对普通用户来说，张口表达把问题问清楚，把 context 讲清楚，这个要求远高于让他们去点/划表达喜恶——咱们冷静想想，搜索引擎出现二十年了，真正善用搜索的人有多少？简单几个 Keyword 都数不清楚的普通人，有几个能明白现在 LLM 的那些 Prompt 技巧？

@xiaohupro 另外，多模分析也不是今天才有的，抽帧截图做实体识别，七八年前业内就开始做了，从搜索推荐到内容审核现在广泛应用。只是现在这波让这些技术更多暴露在了非从业者眼前罢了。

@xiaohupro 从业者表示，根本不用这么麻烦，几个大厂通过非 LLM 做的用户画像模型，精准度在 90%以上。当年我们在全国随机抽几百个用户找人做了用户调研访谈，结果中年龄、性别、职业、泛爱好这种纬度，都准得一批。

@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 模型，自己拿来用，或者再继续微调一下适应自己业务。