紫光同创

1. 你们系统里如果用了消息队列，怎么保证消息不丢失、不重复消费，并且实现最终一致性？答案：先保证生产者发送可靠，发送失败要重试，关键业务可以配合事务消息或本地消息表。Broker 这一层要做持久化和副本，避免机器故障导致消息丢失。消费者要在业务处理成功后再 ack，不能先确认再执行业务。MQ 一般只能保证至少一次投递，所以消费者一定要做幂等。幂等常见做法是业务唯一 ID、去重表、Redis 去重、数据库唯一索引。最终一致性一般靠异步重试、死信队列、补偿机制来保证。面试里可以总结一句：生产者可靠发送，Broker 持久化，消费者幂等消费，失败靠补偿实现最终一致。2. 分布式事务有哪些常见方案？...

感觉自己还是挺狗运的，比不上牛客这些双非大佬随便秒终于戴上红围脖了，xdm 加油

面试迟到，还在面试前偷偷降100待遇，浪费我时间

1. 自我介绍2. 项目拷打3. Perplexity 的定义、公式和真正的使用边界是什么Perplexity 本质上是语言模型对测试序列平均不确定性的指数化表达。若测试集为(x1,…,xT),则 它等价于平均负对数似然的指数形式，值越低通常表示模型对数据分布拟合得越好。很多人只会背“越低越好”，但真正面试里要说明白：PPL 是训练分布拟合指标，不直接等价于问答质量、推理能力、事实性或者指令遵循能力。模型可能 PPL 更低，但在复杂推理或者对齐任务上不一定更强。4. 为什么不同 tokenizer 下的 Perplexity 不能直接横向比较因为 PPL 的分母是 token 数，而 toke...