美的

提问环节，想的美的说的美团！天气太热全程红脸，一面

1.对大模型的了解
（1）参数规模巨大
大模型通常包含数十亿甚至万亿级参数（如GPT-3有1750亿参数），通过增加模型深度和宽度提升表征能力，能捕捉更复杂的模式和上下文关系。

（2）预训练+微调范式
采用两阶段训练：

预训练：在无标注文本（如书籍、网页）上通过自监督学习（如掩码语言建模、自回归生成）获取通用知识。
微调：针对特定任务（如问答、翻译）用少量标注数据调整模型，适配下游应用。

（3）基于Transformer架构
依赖自注意力机制（Self-Attention）并行处理长序列，突破传统RNN的梯度消失限制，显著提升对上下文的理解能力。
通用性与泛化能力

2.es如何进行数据聚合，不同表的数据聚合

3.binlog的三种数据形式

MySQL的binlog日志是数据库实现主从复制、数据恢复等功能的重要工具，它提供了三种不同的记录格式，分别为Statement、Row和Mixed格式。

Statement（基于SQL语句的复制，SBR）
Statement格式的binlog会记录每一项更改数据的SQL语句本身。这意味着每当主库上执行了一个数据修改操作，其对应的SQL语句就会被完整地记录在binlog中。

优点：
记录的内容相对简洁，不包含每一行具体的变化细节，因此可以减少binlog日志的大小，节省磁盘IO，提升性能。

缺点：
由于仅仅记录了SQL语句，为了在备库上精确重现主库的执行效果，还需要记录诸如session变量、用户定义变量等相关上下文信息，以防备库因环境差异而导致执行结果不同。

对于涉及特定存储过程、函数、触发器调用的情况，可能无法确保复制的一致性。

Row（基于行的复制，RBR）
Row格式的binlog不再记录SQL语句，而是直接记录数据行级别的更改详情。

优点：
明确记录了每一行数据的修改细节，能精确反映数据变化，避免了SBR中可能出现的复制一致性问题。
即使在主从服务器的表结构稍有差异或者存在触发器、函数等情况，也能确保复制的正确性。

缺点：
由于需要记录每一行的具体修改，可能导致binlog日志量增大，占用更多存储空间，增加网络传输负担。

Mixed（混合模式复制，MBR）
Mixed格式则是对前两种格式的综合运用，MySQL会智能地根据执行的具体SQL语句选择合适的日志记录方式。

特点：
对于大多数常规SQL语句，MySQL会选择使用Statement格式记录binlog，以减少日志量。
当遇到那些在备库上直接执行原始SQL语句无法达到与主库相同效果的情况，如涉及不确定性的函数、存储过程、触发器等，MySQL会自动切换到Row格式，确保复制的准确性。

通过灵活运用Mixed格式，MySQL既能尽量减小binlog日志大小，又能最大程度地保障主从复制的一致性。

参考链接：https://blog.csdn.net/unbuntu_luo/article/details/143944904

4. 消息的最终一致性

消息队列（MQ）系统中，确保最终一致性通常涉及以下几个关键策略：
1. 消息持久化
持久化存储：将消息存储在持久化存储中，以防系统崩溃后数据丢失。
确认机制：消费者在处理完消息后发送确认（ACK），确保消息不会被丢失。
2. 消息重试
重试机制：在处理消息失败时，允许系统重新处理消息，直到成功为止。
死信队列：将无法处理的消息转移到死信队列，以便后续分析和处理。
3. 幂等性
设计幂等操作：确保同一消息被处理多次时，不会影响最终结果，避免数据重复。
4. 顺序保证
顺序消费：在需要顺序处理的场景中，确保消息按照特定顺序被消费。
5. 最终一致性模型
异步更新：允许系统在短时间内出现不一致状态，但最终会通过后台任务或补偿机制达到一致性。
版本控制：使用版本号或时间戳来跟踪数据变化，确保数据在更新时的一致性。
6. 监控与告警
实时监控：监控消息队列的状态和处理情况，及时发现并处理异常。
告警机制：设置告警规则，当系统出现异常时及时通知相关人员。