Daily Study

更新: 6/18/2025 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

场景题

对AI的理解

在我看来，AI 的核心在于模仿、延伸和放大人类的智能。它不仅仅是自动化，更是关于学习、推理、感知、决策和创造。从弱人工智能（ANI）专注于特定任务，到我们仍在探索的通用人工智能（AGI），AI 的发展正在深刻改变各个行业。

关于我接触的两个领域，安全和大模型应用领域，我对AI的理解如下。

对于安全领域的防御方：

• AI能够提升智能检测与响应的能力，包括异常检测，恶意软件分析，入侵检测，管理与响应。
• AI能够提升身份认证与访问控制，包括生物识别，行为分析来做一些验证
• AI能够对漏洞进行管理和风险评估

对于安全领域的攻击方：

• AI能够做一些自动化攻击工具，自动化的发现和利用漏洞，然后进行大规模自动化的攻击
• AI能够利用深度学习进行一些身份的伪造，然后进行敲诈
• 攻击者可以做一些对抗攻击，欺骗AI模型，从而导致其做出误判和分类
• 攻击者还可以通过污染训练数据对AI做投毒攻击

对于大模型应用领域：

• 内容生成与辅助创作： 撰写邮件、报告、代码、营销文案、剧本等。
• 智能问答与对话系统： 作为客服、个人助手、信息检索工具。
• 代码生成与辅助开发： 帮助开发者编写、调试、解释和转换代码。
• 数据分析与洞察： 从大量文本数据中提取摘要、趋势、情感。
• 教育与培训： 个性化辅导、生成学习材料。
• 机器翻译与自然语言理解。

总结来说，我对大模型的理解，它在专业领域相当于是一把双刃剑，不仅要关注于它带来的便利，也要防范它带来的危害。关键在于：

• 持续的攻防演练：防御方需要不断利用AI提升能力，同时研究AI可能带来的新威胁。
• 关注LLM自身的安全：加强对提示注入、数据泄露等LLM特有漏洞的研究和防护。发展更安全的LLM架构和训练方法。
• 人机协同：AI目前还不能完全取代人类安全专家。最佳实践是人机协同，AI作为强大的助手，辅助人类专家进行决策和操作。

对一个好的大模型应用的理解

1. 清晰的价值主张与精准的问题解决 (Clear Value Proposition & Problem Solving):
   • 解决真实痛点，而非“为了用LLM而用LLM”: 应用的核心应该是解决用户或业务面临的实际问题，LLM只是实现解决方案的工具。如果传统方法能更简单、经济、有效地解决问题，就不应强行使用LLM。
   • 发挥LLM的独特优势: 好的应用会巧妙利用LLM在自然语言理解、生成、摘要、翻译、代码生成、复杂推理（在一定程度上）等方面的长处。例如，自动化繁琐的文本处理、提供个性化内容、赋能更自然的交互等。
   • 价值可衡量: 应用的价值应该是可以被感知的，无论是提升效率、降低成本、创造新体验，还是赋能新的业务模式。
2. 卓越的用户体验 (Excellent User Experience - UX):
   • 自然流畅的交互: 用户与应用的交互应该尽可能直观、自然。如果涉及对话，那么对话管理、上下文理解、多轮交互能力至关重要。
   • 有效的引导与预期管理: LLM并非万能，应用需要清晰地告知用户其能力边界，并通过良好的设计（如有效的提示工程、示例、模板）引导用户获得最佳输出，管理用户的期望值。
   • 迭代与修正能力: 用户应该能够方便地对LLM的输出进行反馈、修正或要求重新生成，形成一个有效的“人机协作”闭环。
   • 上下文感知与个性化: 好的应用能够记住历史交互信息、用户偏好，提供更具个性化和连贯性的体验。
   • 适当的反馈与透明度: 在适当的时候，应用可以解释LLM是如何得出结论的（例如，通过引用来源——尤其在使用RAG时），或给出置信度，增加用户的信任感。
3. 可靠性与可信赖性 (Reliability & Trustworthiness):
   • 准确性与事实性控制: 这是LLM应用面临的最大挑战之一。好的应用会采用多种策略来减少“幻觉”（hallucinations）和事实性错误，例如：
     • 检索增强生成 (Retrieval Augmented Generation - RAG): 将LLM与可靠的外部知识库或私有数据库结合，让LLM基于检索到的信息进行回答和生成，而不是仅依赖其内部训练数据。
     • Grounding (接地): 将LLM的输出与特定事实、数据源进行锚定。
     • 严格的后处理和验证: 对LLM的输出进行事实核查或规则校验。
   • 一致性与可预测性: 在相似的输入下，应用应该能提供相对一致和可预测的输出（除非其设计目标是创造性输出）。通过精细的系统提示（System Prompt）和参数调整来实现。
   • 鲁棒性与错误处理: 应用需要能够优雅地处理不明确的输入、超出LLM能力范围的请求，并给出清晰的错误提示或引导。
4. 深度技术整合与巧妙的系统设计 (Deep Technical Integration & Smart System Design):
   • 不仅仅是“API套壳”: 优秀的应用通常会将LLM作为核心组件，但会围绕它构建复杂的系统，包括数据预处理、精巧的提示工程、与其他业务逻辑和数据系统的集成、以及输出的后处理等。
   • “人机回圈” (Human-in-the-Loop): 对于关键决策或高风险任务，应设计人工审核和干预的环节，确保安全和质量。
   • 模型选择与优化: 根据具体任务选择最合适的LLM（考虑能力、成本、速度等因素），甚至可能需要对基础模型进行微调（Fine-tuning）以适应特定领域或任务。
   • 可观测性与持续监控: 建立完善的日志、监控和告警机制，追踪LLM的性能、输出质量、用户反馈、token消耗等，以便持续优化。
5. 负责任的AI与伦理考量 (Responsible AI & Ethical Considerations):
   • 偏见缓解: 认识到LLM可能存在的偏见，并采取措施（如数据增强、提示调整、输出过滤）来减轻其负面影响。
   • 数据隐私与安全: 严格保护用户输入数据的隐私，尤其是在处理个人身份信息（PII）或其他敏感数据时。确保数据在传输、存储和处理过程中的安全。
   • 透明度与可解释性: 尽可能让用户理解应用是如何工作的，以及为什么会产生特定的输出（尽管LLM的完全可解释性仍是难题）。
   • 防止滥用与有害内容生成: 设置有效的护栏（guardrails）和内容过滤器，防止应用被用于生成仇恨言论、虚假信息、恶意代码等有害内容。
6. 高效性与可持续性 (Efficiency & Sustainability):
   • 成本效益: LLM的调用是有成本的（token消耗）。好的应用会优化提示长度、选择合适的模型、采用缓存等策略，以实现成本效益。
   • 性能与延迟: 保证应用在可接受的时间内响应用户请求。对于实时性要求高的场景，需要特别关注LLM的推理速度和整体系统的延迟。
   • 可扩展性: 应用架构需要能够支持用户量和数据量的增长。 总结来说，一个好的基于LLM的应用，是以用户为中心，以解决实际问题为导向，巧妙利用LLM的优势，同时有效规避其固有缺陷，并通过精心的系统设计、用户体验打磨以及负责任的开发态度，最终为用户带来真实、可靠、高效价值的综合体现。 它往往不是一个孤立的LLM，而是一个精心编排的、包含LLM在内的复杂系统。

AI对后端的影响

AI正从根本上重塑后端开发，其核心影响体现在以下几个方面：

1. 开发效率与自动化飞跃：

   • AI驱动代码生成（如API、业务逻辑、测试用例）、文档撰写及代码审查，大幅缩短开发周期。
   • 辅助Bug定位与修复建议，提升代码质量与维护效率。

2. 系统架构与运维智能化：

   • 推动API网关、服务网格等基础设施向智能化演进，实现动态路由、自适应限流与弹性伸缩。
   • 催生AI原生后端架构，更好地支持ML模型服务、特征存储等。
   • AIOps：通过智能监控、异常检测、预测性维护和自动化根因分析，提升系统稳定性和运维效率。

3. 催生新型后端服务与能力：

   • 使得构建AI即服务（AIaaS）平台、高级个性化推荐引擎、复杂NLP接口等新型后端应用成为可能。
   • 强化后端实时数据处理、智能决策与自动化流程的能力。

4. 后端工程师角色与技能转型：

   • 工程师角色从纯粹的“编码者”向AI工具的“使用者、编排者、验证者”转变。
   • 对AI/ML基础、数据工程、MLOps以及提示工程等技能的需求日益增加。

5. 核心挑战与审慎考量：

   • 需关注AI生成代码/设计的质量、安全性、可解释性和可维护性。
   • 警惕过度依赖可能导致的技能退化，并重视数据隐私、算法偏见及伦理问题。

后端工作阐述思路/要注意哪些方面/关键点

参考链接：后端实习什么算有产出？ - 小红书

不要仅仅停留在“做了什么”，更要讲清楚“为什么这么做”、“遇到了什么挑战”、“如何解决的”、“有哪些考量和兜底方案”，从而体现自己的技术深度、owner意识和解决问题的能力。很多所谓的“难点”并非任务本身复杂，而是源于你是否“多想了一步”。

---

下面针对其中提出的问题，给出思考方向和解答思路：

ToC 场景-RPC 服务调用考量

• 问题精髓： 调用一个RPC服务时，你做了哪些技术考量？如何处理其不稳定性？超时如何设定？
• 思考方向与回答思路：
  1. 选型与必要性：
     • 为什么选择这个RPC服务？ （它提供了什么核心能力？数据来源？是唯一的选择还是有替代方案？）
     • 业务场景： 这个RPC调用在用户完成哪个操作的链路中？是核心路径还是旁路功能？
  2. 接口指标观察：
     • 是否观察过指标？ （调用前是否有调研？调用后是否有监控？）
     • 关键指标： 平均耗时、P95/P99耗时、错误率、QPS/TPS。这些指标如何影响你的设计？
  3. 调用方式：
     • 同步还是异步？
       • 同步考量： 业务流程强依赖其结果、用户需实时感知结果、实现简单。但需注意下游延迟会直接影响本服务。
       • 异步考量： 允许最终一致性、可削峰填谷、主流程无需等待其结果、提升用户体验。但增加了系统复杂度（如需要回调、状态管理、消息队列等）。
       • 选择理由： 结合业务需求、性能要求、用户体验和系统复杂度进行阐述。
  4. 容错与兜底 (RPC调用失败/服务宕机/超时)：
     • 重试机制： 是否有重试？次数？间隔策略（固定、指数退避）？针对哪些错误类型重试（如网络错误、超时可重试，业务错误一般不重试）？
     • 熔断机制： 当错误率或慢调用达到阈值时，快速失败，避免雪崩效应，保护下游。
     • 降级/兜底：
       • 返回默认值/缓存数据。
       • 调用备用接口/本地实现。
       • 提示用户稍后再试/功能暂时不可用。
       • 选择理由： 业务对该RPC的依赖程度，是否有可接受的B方案。
     • 幂等性保证： 如果RPC是写操作且有重试，如何保证幂等性？（见后续问题）
  5. 超时配置：
     • 超时时间是多少？为什么是这个值？
       • 下游服务SLA： 下游承诺的P99耗时是多少？
       • 本链路总耗时预算： 用户可接受的整体响应时间是多少？给这个RPC调用分配了多少时间片？
       • 接口容忍度： 业务上能容忍这个调用花费多长时间？超过多久就认为失败或用户已无法忍受？
       • 经验值与调优： 是否根据线上实际监控数据进行过调整？
       • 举例： "下游RPC P99承诺200ms，我的服务链路总预算500ms，在其之前还有A、B操作共耗时100ms，所以我设置其超时为250ms，留有一定buffer，并略高于其P99，避免因网络波动频繁超时。"

---

ToB 业务设计与数据一致性

• 问题精髓： ToB业务复杂，为什么要这么设计？如何保证数据一致性？
• 思考方向与回答思路：
  1. 业务驱动设计：
     • 核心业务流程是什么？ （例如：订单处理、库存管理、审批流转等）
     • 关键业务实体有哪些？ （用户、商品、订单、账户等）
     • 设计目标： 当前设计是为了解决什么核心业务问题？（提升效率、降低成本、满足合规、增强扩展性等）
     • 权衡与取舍： 在设计中做了哪些权衡？（例如，为保证强一致性牺牲了部分性能；为提高灵活性增加了模型复杂度等）
  2. 数据一致性：
     • 场景识别： 哪些场景对数据一致性有强要求？哪些可以接受最终一致性？
     • 一致性模型选择：
       • 强一致性： 常用于金融、库存等场景。可通过分布式事务（如2PC/3PC，但实现复杂、性能影响大，慎用）、基于数据库事务、悲观/乐观锁等实现。
       • 最终一致性： 适用于高并发、可接受短暂数据不一致的场景。可通过可靠事件模式（如事务消息）、定期校对、TCC（Try-Confirm-Cancel）补偿事务等实现。
     • 具体方案与理由：
       • “在订单创建和支付环节，我们采用了本地事务+可靠事件投递的方式，确保订单状态和支付状态的最终一致性。因为支付是外部系统，无法纳入本地事务，而用户对支付结果的即时反馈要求高，但允许后台数据在秒级内达到一致。”
       • “对于用户账户余额操作，我们使用了数据库的行级锁配合事务，保证了操作的原子性和强一致性，因为金额准确性至关重要。”

k8s

简单实践教程参照：Kubernetes 教程

k8s的功能

• container：涉及到有技巧的便携dockerfile，尽量优化镜像的大小，然后上传到docker中
• pod：Kubernetes 中创建和管理的、最小的可部署的计算单元代码如下：

apiVersion: v1

kind: Pod

metadata:

  name: hellok8s

spec:

  containers:

  - name: hellok8s-container

    image: 1106094445/hellok8s:v1

• deployment：用来管理pod，涉及到扩容、滚动更新、存活指针、就绪指针。
• service：为 pod 提供一个稳定的 Endpoint。Service 位于 pod 的前面，负责接收请求并将它们传递给它后面的所有pod。一旦服务中的 Pod 集合发生更改，Endpoints 就会被更新，请求的重定向自然也会导向最新的 pod。涉及到三种方式：clusterip、nodeport、loadbalancer
• ingress：Ingress公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、 SSL/TLS，以及基于名称的虚拟托管。
• namespace ：名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等。
• configmap：将配置数据和应用程序代码分开，将非机密性的数据保存到键值对中。ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据，你可能考虑挂载存储卷。
• secret：是一种包含少量敏感信息例如密码、令牌或密钥的对象。由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。
• job：创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。 随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pod。 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。