Sequence 12 - AI 风控 / LLM 平台专项深挖：架构、技术设计、面试回答

这一页专门讲 AI Risk-Control and LLM Strategy Platform。它是你和 NVIDIA JD 最接近的项目，不能只说“做了 AI 风控”。面试里要把它讲成一个 production AI inference / LLM workflow / observability / correctness validation 系统。

1. 面试定位

一句话定位：

这是一个把 feature generation、online inference、retrieval-assisted LLM analysis、anomaly detection、strategy execution、observability、replayability 和 effectiveness evaluation 串起来的生产 AI 平台。我的重点不是简单接模型 API，而是把 AI workload 放进可观测、可回放、可验证、可优化的生产路径里。

English:

This was a production-oriented AI risk-control and LLM strategy platform. It connected feature generation, online inference, retrieval-assisted LLM analysis, anomaly detection, strategy execution, observability, replayability, and effectiveness evaluation. My focus was not just model integration, but making AI workloads observable, replayable, correct, and optimizable in a production path.

1.1 推荐项目讲解结构：中文一段 + English 一段

面试官让你讲项目时，不要从“用了什么模型”开始。先按这个结构讲：

1. Context: 这个系统解决什么生产问题。
2. Data source: 数据从哪里来，进入系统前是什么形态。
3. Data path: 数据经过哪些模块，如何变成 decision。
4. My work: 我具体负责什么。
5. Bottleneck: 主要瓶颈是什么。
6. Solution: 我怎么定位、怎么设计、怎么落地。
7. Metrics: 我看什么指标，怎么证明有效。
8. Boundary: 哪些数字不能披露，怎么用相对指标表达。

中文项目讲法：

这个项目的背景是：风控和策略系统需要把大量生产事件转成可解释、可回放、可验证的 AI decision，而不是只调用一个模型 API。数据来源主要是交易、钱包、安全、用户行为、策略执行结果和历史 case。进入系统后，事件先做 normalize 和 schema validation，再进入 feature generation，生成规则特征、统计特征和上下文特征；然后走 online model inference、retrieval-assisted LLM analysis 或 rule path；最后由 strategy engine 和 guardrail 把输出转成放行、拦截、升级复核、降级处理等 action。

我负责的重点是 production AI path 的工程化：把 event -> feature -> inference/LLM -> strategy -> guardrail -> decision -> feedback/replay 这条路径拆清楚，并且给每个阶段加 trace id、stage latency、error/fallback 记录和 replay 能力。我的目标不是只让模型返回结果，而是让线上 case 能追溯、能回放、能比较版本效果，出现 P99 高、误伤、漏放、LLM 输出不稳定时能定位是哪一段出问题。

指标上，我会看 end-to-end latency、stage latency、P50/P95/P99、fallback rate、replay success rate、decision distribution、false-positive/false-negative proxy、case review result 和策略命中率。真实生产数值如果涉及公司数据不能披露，面试时不要编数字；可以说“我用这些指标做 baseline 和版本对比，并用相对变化或归一化指标说明效果”。如果对方追问具体数值，就回答能披露的口径，比如“我们看 P95/P99 和 fallback rate，而不是只看 average latency；我可以讲指标体系和优化方法，但不能披露公司内部绝对数值”。

English project story:

The context of this project was that a risk-control and strategy system needed to turn production events into explainable, replayable, and verifiable AI decisions, not just call a model API. The data sources included transaction events, wallet events, security signals, user behavior, strategy execution results, and historical cases. The events were normalized and validated first, then converted into rule features, statistical features, and contextual features. After that, the system could trigger online model inference, retrieval-assisted LLM analysis, or rule-based paths, and the strategy engine plus guardrails would convert the outputs into actions such as allow, block, escalation, review, or fallback.

My focus was engineering the production AI path. I decomposed it as event, feature, inference or LLM, strategy, guardrail, decision, feedback, and replay. For each stage, the important engineering work was traceability, stage-level latency, error and fallback recording, and replayability. The goal was not only to get a model response, but to make online cases traceable, replayable, comparable across versions, and diagnosable when P99 latency, false positives, false negatives, or unstable LLM outputs appeared.

For metrics, I would look at end-to-end latency, stage latency, P50/P95/P99, fallback rate, replay success rate, decision distribution, false-positive and false-negative proxies, case review results, and strategy hit rate. If exact production numbers are confidential, I would not invent them. I would explain the metric system, the baseline, and the relative comparison method. If asked for concrete numbers, I would say that I can discuss the metric categories and optimization method, but I cannot disclose internal absolute values.

1.2 CV 实际口径：OKX AI 风控 / LLM 安全分析 / 策略执行

这一段按 CV 里的真实 bullet 写：AI risk-control and strategy platform、feature generation、online inference、effectiveness evaluation、anomaly detection、behavior-pattern analysis、strategy execution workflows，以及 embedding、hybrid retrieval、multi-agent workflows、KV cache management、speculative decoding、inference-path production integration。

中文项目讲法：

我在 OKX 做的 AI 风控和 LLM 安全分析，不是离线 demo，而是把 AI 能力接到生产风险事件和策略执行链路里。数据来源包括钱包/交易/安全相关事件、用户行为序列、策略命中结果、历史异常 case、人工 review 反馈和模型/规则输出。系统先做 event normalize 和 feature generation，再进入 anomaly detection、behavior-pattern analysis、online inference、retrieval-assisted LLM analysis，最后由 strategy execution workflow 生成风险动作或复核动作。

LLM 这部分的实际工作口径是 security analysis scenarios：embedding、hybrid retrieval、multi-agent workflow、输出约束、case trace、replay、effectiveness evaluation，以及 inference path production integration。KV cache 和 speculative decoding 在 CV 里是我对 LLM inference path 的优化意识和工程接入方向，面试时要讲成“我理解它们如何影响 TTFT/TPOT/throughput/P99”，不要夸大成我改过 NVIDIA runtime 内核。

English project story:

The AI risk-control and LLM security-analysis work at OKX was not an offline demo. It connected AI capabilities to production risk events and strategy execution paths. The data sources included wallet, trading, and security-related events, user behavior sequences, strategy-hit results, historical abnormal cases, human-review feedback, and model or rule outputs. The system first normalized events and generated features, then performed anomaly detection, behavior-pattern analysis, online inference, and retrieval-assisted LLM analysis, and finally used strategy-execution workflows to produce risk actions or review actions.

For the LLM part, the accurate CV framing is security-analysis scenarios: embedding, hybrid retrieval, multi-agent workflows, constrained output, case tracing, replay, effectiveness evaluation, and production integration of the inference path. KV cache and speculative decoding should be discussed as my understanding of LLM inference-path optimization and production integration: how they affect TTFT, TPOT, throughput, and P99. I should not overstate this as modifying NVIDIA runtime internals.

1.2.1 风控生产链路 / Risk-control production path

flowchart TB
    Event[Wallet / Trading / Security Events] --> Normalize[Normalize / Schema Validation]
    Normalize --> Feature[Feature Generation]
    Feature --> Rule[Rule / Risk Feature Path]
    Feature --> Model[Online Inference]
    Feature --> Retrieval[Embedding / Hybrid Retrieval]
    Retrieval --> LLM[LLM / Multi-agent Analysis]
    Rule --> Strategy[Strategy Execution Workflow]
    Model --> Strategy
    LLM --> Strategy
    Strategy --> Guardrail[Guardrail / Policy Check]
    Guardrail --> Action[Allow / Block / Review / Escalate]
    Action --> Feedback[Review / Feedback / Effectiveness]
    Feedback --> Replay[Replay / Evaluation]
    Replay --> Feature

中文解释：

这个链路的关键不是“LLM 回答了什么”，而是事件如何被结构化、特征如何稳定、模型和 LLM 输出如何接入策略、策略动作如何可解释和可回放。真正的工程难点是 schema 变化、feature consistency、retrieval latency、LLM 输出不稳定、策略冲突、P99 和误伤/漏放。

English explanation:

The key point in this path is not what the LLM says. It is how events are structured, how features remain consistent, how model and LLM outputs are integrated into strategy execution, and how actions remain explainable and replayable. The real engineering challenges are schema changes, feature consistency, retrieval latency, unstable LLM outputs, strategy conflicts, P99 latency, false positives, and false negatives.

1.2.2 风控怎么多写“网络”和通信路径 / Networking and communication path in the risk platform

中文：

风控项目里的网络不是 RDMA，而是生产分布式系统通信路径：事件从上游服务进来，经过 queue/stream、feature service、model/LLM service、strategy service 和 action service。这里会遇到 gRPC/Kafka 路径、routing、queueing、backpressure、retry、timeout、慢消费者和下游依赖抖动。我的 CV 里写的 communication-path diagnosis 可以自然接到这里：如果 P99 高，要判断是 queueing、feature 依赖、retrieval I/O、model service、LLM service、strategy conflict，还是 downstream action 慢。

English:

The networking in this risk platform is not RDMA; it is production distributed-system communication. Events enter from upstream services and pass through queues or streams, feature services, model or LLM services, strategy services, and action services. The system can face gRPC/Kafka paths, routing, queueing, backpressure, retries, timeouts, slow consumers, and downstream dependency jitter. This connects directly to the communication-path diagnosis in my CV. If P99 is high, I would determine whether it comes from queueing, feature dependencies, retrieval I/O, model service, LLM service, strategy conflicts, or downstream actions.

2. 系统总架构

flowchart TB
    Event[Production Events] --> Ingest[Event Ingestion]
    Ingest --> Feature[Feature Generation]
    Feature --> RiskInfer[Online Risk Inference]
    Feature --> Retrieval[Retrieval / Embedding]
    Retrieval --> LLM[LLM Analysis / Agent Workflow]
    RiskInfer --> Strategy[Strategy Engine]
    LLM --> Strategy
    Strategy --> Guardrail[Policy / Guardrail]
    Guardrail --> Decision[Risk Decision / Action]
    Decision --> Feedback[Feedback / Effectiveness]
    Feedback --> Eval[Evaluation / Replay]
    Eval --> Feature

    Ingest --> Obs[Metrics / Logs / Traces]
    RiskInfer --> Obs
    LLM --> Obs
    Strategy --> Obs
    Decision --> Audit[Audit / Traceability]

3. 核心 data path

面试时要把路径讲清楚：

event -> feature -> model/LLM -> strategy -> guardrail -> decision -> feedback -> replay/evaluation

更具体：

4. 为什么和 NVIDIA JD 相关

不能夸大：

不要说：这个项目就是 NVIDIA GPU networking。
要说：这个项目证明我能把 AI workload 放进生产系统路径里，并用 data path、metrics、replay、correctness validation 和 profiling 思维处理复杂系统。

English:

I would not present this project as direct GPU networking experience. I would present it as production AI infrastructure experience: decomposing the inference path, defining latency and correctness metrics, building observability and replayability, and validating behavior under production constraints. Those skills transfer to NVIDIA's AI networking role because GPU inference and data movement also require clear data paths, measurable bottlenecks, and reproducible validation.

5. 关键技术设计

5.1 Request / event path 设计

flowchart TB
    Request[Risk Event] --> Parse[Parse / Normalize]
    Parse --> Feature[Feature Builder]
    Feature --> Cache[Feature / Context Cache]
    Cache --> Model[Model Inference]
    Cache --> RAG[Retrieval Context]
    RAG --> LLM[LLM Reasoning]
    Model --> Decision[Decision Composer]
    LLM --> Decision
    Decision --> Action[Action / Review / Block]

回答重点：

我会先把 AI 系统拆成 request path，而不是只谈模型。每一步都要有 latency、error rate、fallback 和 trace id。这样当线上行为异常或 P99 高时，可以定位是 feature、retrieval、model、LLM、strategy 还是 downstream action 的问题。

5.2 Observability 设计

5.3 Correctness validation 设计

flowchart TB
    Prod[Production Case] --> Trace[Trace / Feature Snapshot]
    Trace --> Replay[Replay Engine]
    Replay --> Compare[Compare Expected vs Actual]
    Compare --> CaseReview[Case Review]
    CaseReview --> RuleFix[Rule / Strategy Fix]
    CaseReview --> ModelEval[Model Evaluation]
    ModelEval --> Rollout[Shadow / Canary / A-B]

面试回答：

AI 风控系统不能只看响应成功，还要看 decision correctness。我的验证方式包括 trace、feature snapshot、replay、shadow、case review、metric comparison 和 staged rollout。这样可以把线上复杂行为变成可复现、可分析、可迭代的问题。

5.4 Guardrail / fallback 设计

6. 面试 Q&A

Q1: 讲讲这个项目 / Tell me about this project.

中文：

这个项目是 production-oriented AI risk-control 和 LLM strategy platform，把 feature generation、online inference、retrieval-assisted LLM analysis、anomaly detection、strategy execution、observability、replayability 和 effectiveness evaluation 串起来。

重点不是简单调用模型 API，而是 AI 在生产系统里的路径：event 如何变成 feature，inference/LLM 如何接入，strategy 如何做 decision，输出怎么 guard，case 怎么 trace 和 replay。从系统角度看，它关注 latency、correctness、observability、fallback 和 continuous evaluation。

连接 NVIDIA 岗位时，我会强调 request path decomposition、latency/throughput tradeoff、KV/cache awareness、production validation 和 bottleneck diagnosis。

English:

This project was a production-oriented AI risk-control and LLM strategy platform. It connected feature generation, online inference, retrieval-assisted LLM analysis, anomaly detection, strategy execution, observability, replayability, and effectiveness evaluation.

The important part is that it was not just calling a model API. I worked on the production system path around AI: how events become features, how inference and LLM analysis are integrated, how strategy decisions are made, how outputs are guarded, and how cases can be traced and replayed. From a systems perspective, the project was about latency, correctness, observability, fallback, and continuous evaluation.

For the NVIDIA role, I would connect this to AI inference systems: request path decomposition, latency and throughput tradeoffs, KV/cache awareness, production validation, and bottleneck diagnosis.

Q2: 技术上最难的是什么 / What was hard technically?

中文：

难点不是某一次模型调用，而是让整条 AI decision path 在生产约束下可靠、可解释、可回放。

具体挑战包括 feature consistency、retrieval latency、LLM output stability、strategy conflict、tail latency，以及异常 case 必须能 replay。我的做法是把系统拆成多个 stage，为每个 stage 加 metrics 和 trace，让 decision record 可审计，并在信任改动前用 replay 或 shadow validation 验证。

English:

The hard part was not a single model call. The hard part was making the whole AI decision path reliable and explainable under production constraints.

There were several challenges: feature consistency, retrieval latency, LLM output stability, strategy conflicts, tail latency, and the need to replay abnormal cases. My approach was to break the system into stages, add metrics and traces for each stage, keep decision records auditable, and use replay or shadow validation before trusting changes.

Q3: 如果改成 GPU 推理系统，你怎么设计 / How would you redesign it for GPU inference?

中文：

我会先定义 serving workload：model size、request rate、context length、SLO、throughput target。然后把 request path 拆成 queueing、scheduling、prefill、decode、KV cache allocation、post-processing 和 strategy execution。

GPU inference 里我会看 TTFT、TPOT、P95/P99、GPU utilization、memory pressure、batch composition 和 communication time。如果 prefill 和 decode 的资源画像不同，可以考虑 disaggregation，但必须同时测 KV/state movement 的成本。NIXL、UCX、NCCL 是否相关，取决于瓶颈是 inference state movement、transport，还是 collectives。

English:

I would first define the serving workload: model size, request rate, context length, SLO, and throughput target. Then I would separate the request path into queueing, scheduling, prefill, decode, KV cache allocation, post-processing, and strategy execution.

For GPU inference, I would track TTFT, TPOT, P95/P99, GPU utilization, memory pressure, batch composition, and communication time. If prefill and decode have different resource profiles, I would consider disaggregation, but I would also measure the cost of KV/state movement. This is where NIXL, UCX, and NCCL become relevant depending on whether the bottleneck is inference state movement, transport, or collectives.

Q4: 如果他们质疑这不是 GPU networking，你怎么回答 / What would you say if they challenge that this is not GPU networking?

中文：

这个质疑是合理的。我不会说这个项目是 GPU networking production experience。我会用它证明我对 AI workload 的系统基础：request-path decomposition、latency analysis、observability、replayability、correctness validation、fallback 和 prototype-driven improvement。

GPU networking-specific stack 是我正在补深的方向，特别是 NIXL、UCX、GPUNetIO、NCCL 和 CUDA/Nsight。我的优势是能把这些技术放到 production data path 里，并用可度量实验验证。

English:

That is fair. I would not claim this project is GPU networking production experience. I would use it to demonstrate my systems foundation around AI workloads: request-path decomposition, latency analysis, observability, replayability, correctness validation, fallback, and prototype-driven improvement.

The GPU networking-specific stack is the area I am ramping up on, especially NIXL, UCX, GPUNetIO, NCCL, and CUDA/Nsight. My advantage is that I can place those technologies into a production data path and validate them with measurable experiments.

Q5: 数据从哪里来，怎么进入系统 / Where did the data come from, and how did it enter the system?

中文回答：

数据不是单一模型输入，而是多类 production events。主要包括交易事件、钱包事件、安全事件、用户行为事件、策略执行结果和历史 case。进入系统后先做 normalize、schema validation 和 trace id 绑定，再进入 feature generation。这样后续无论是模型输出、LLM 分析、策略 decision，还是 replay/debug，都能回到同一个 case id 和 feature snapshot。

English:

The data was not a single model input. It came from multiple types of production events: transaction events, wallet events, security signals, user behavior, strategy execution results, and historical cases. After ingestion, the first steps were normalization, schema validation, and trace-id binding. Then the data entered feature generation. This made it possible to trace model output, LLM analysis, strategy decisions, and replay/debug results back to the same case id and feature snapshot.

Q6: 你具体做了什么 / What exactly did you build or own?

中文回答：

我会把我的 ownership 讲成 production path engineering，而不是“我训练了某个模型”。我做的是把 event、feature、inference/LLM、strategy、guardrail、decision、feedback/replay 这条路径拆开，并补上可观测、可回放和可验证能力。具体包括阶段耗时记录、错误和 fallback 记录、case trace、feature snapshot、replay 对比、策略版本对比，以及把 LLM 输出接入 guardrail 和 strategy composer。

English:

I would describe my ownership as production-path engineering rather than claiming that I trained a specific model. I worked on decomposing the path from event, feature, inference or LLM, strategy, guardrail, decision, to feedback and replay, and making that path observable, replayable, and verifiable. Concretely, that included stage-level latency recording, error and fallback recording, case tracing, feature snapshots, replay comparison, strategy-version comparison, and integrating LLM outputs with guardrails and a strategy composer.

Q7: 具体瓶颈是什么，怎么解决 / What was the bottleneck, and how did you solve it?

中文回答：

我不会把瓶颈说成单点，而会按路径拆。常见瓶颈包括 feature generation 依赖慢、retrieval I/O 慢、LLM 调用 P99 高、策略冲突导致 decision path 变长、下游 action 依赖不稳定。解决方式是先加 stage-level tracing，建立 baseline，再区分 average latency 和 tail latency。对非关键路径做 async/degrade，对高频 context 做 cache，对 LLM 输出做 timeout/fallback，对策略冲突做 priority 和 audit log。

English:

I would not describe the bottleneck as a single point. I would decompose it by path. Common bottlenecks included slow feature-generation dependencies, retrieval I/O latency, high P99 latency from LLM calls, longer decision paths caused by strategy conflicts, and unstable downstream action dependencies. My approach was to add stage-level tracing, establish a baseline, and separate average latency from tail latency. Then I would make non-critical paths asynchronous or degradable, cache high-frequency context, add timeout and fallback for LLM outputs, and use priority plus audit logs for strategy conflicts.

Q8: 具体数值怎么讲 / How should you talk about concrete numbers?

中文回答：

如果真实生产数值涉及公司机密，不要编。正确讲法是：“我看的是 end-to-end latency、stage latency、P50/P95/P99、fallback rate、replay success rate、decision distribution、false-positive/false-negative proxy。我可以讲指标体系、baseline 方法、相对变化和 debug 路径，但不能披露内部绝对值。”如果对方必须要数字，可以给非敏感口径，例如 LLM serving 常见会看 TTFT、TPOT、P99；实时系统常见会把 P95/P99 和 fallback rate 当作上线 gate。

English:

If exact production numbers are confidential, I should not invent them. The right answer is: I tracked end-to-end latency, stage latency, P50/P95/P99, fallback rate, replay success rate, decision distribution, and false-positive or false-negative proxies. I can explain the metric system, baseline method, relative comparison, and debug path, but I cannot disclose internal absolute values. If the interviewer insists on numbers, I can use non-confidential metric categories, such as TTFT, TPOT, and P99 for LLM serving, or P95/P99 and fallback rate as release gates for production systems.

Q9: 如果让你把它改造成 GPU 推理系统，你怎么做 / How would you turn this into a GPU inference system?

中文回答：

我会先定义 workload：模型大小、QPS、prompt length、output length、SLO、并发数、是否需要 retrieval、是否需要 streaming。然后把路径拆成 gateway、queue、scheduler、prefill、KV allocation、decode、postprocess、strategy/action。指标上看 TTFT、TPOT、P95/P99、throughput、GPU utilization、GPU memory pressure、KV cache usage、communication time。只有当确认瓶颈在 state movement 或 prefill/decode disaggregation 时，才引入 NIXL/UCX/GPUDirect 方向的优化。

English:

I would first define the workload: model size, QPS, prompt length, output length, SLO, concurrency, whether retrieval is needed, and whether streaming is required. Then I would decompose the path into gateway, queue, scheduler, prefill, KV allocation, decode, post-processing, and strategy/action. The key metrics would be TTFT, TPOT, P95/P99, throughput, GPU utilization, GPU memory pressure, KV cache usage, and communication time. I would introduce NIXL, UCX, or GPUDirect-related optimization only after confirming that the bottleneck is state movement or prefill/decode disaggregation.

7. 90 秒英文项目讲法

One project closest to this role is an AI risk-control and LLM strategy platform I worked on at OKX. The system connected feature generation, online inference, retrieval-assisted LLM analysis, anomaly detection, strategy execution, observability, replayability, and effectiveness evaluation.

My focus was not simply model integration. I cared about the production AI path: how events become features, how inference and LLM analysis are triggered, how strategy decisions are composed, how risky outputs are guarded, and how abnormal cases can be traced and replayed. The key engineering concerns were latency, correctness, fallback, auditability, and continuous evaluation.

For this NVIDIA role, I would connect it to AI inference infrastructure. Large-scale inference also requires clear request paths, metrics such as TTFT, TPOT, P99, cache and state management, and reproducible performance validation. I would not claim this as direct NIXL or GPUNetIO production ownership, but it shows how I approach complex AI systems: data path first, metrics second, prototype and validation next.

8. 面试前检查

你要能闭眼画出：

event -> feature -> inference / LLM -> strategy -> guardrail -> decision -> feedback -> replay

你要能回答：

1. 这个项目不是调 API，而是 production AI system。
2. 最核心的技术点是 request path、observability、correctness、replay、fallback。
3. 和 NVIDIA 的连接是 AI inference path、serving metrics、data movement awareness、prototype validation。
4. 边界是：它不是直接 GPU networking production ownership。