传统广告系统旨在响应离散的用户意图单元。用户在网上搜索或浏览某内容，广告系统将这些查询和页面浏览作为事件接收，并基于这些事件寻找匹配的广告。为ChatGPT构建广告技术栈则有所不同：用户意图在对话中逐步形成，并在多轮对话中发生变化，有时并不存在合适的广告时机。为支持这一新范式，我们构建了一套定制的广告投放系统。这种新型广告技术栈基于一个经过定制后训练的前沿LLM，该LLM通过工具调用完成检索（识别最佳选项）、排序（预测用户参与度）、相关性评估（评估广告的有用性），以及运行拍卖以完成最终广告选择和定价。
我们的广告系统通过三项关键设计决策来支持不断演变用户目标的细微差别：1）实现有状态的广告会话，即信息在对话的多轮之间以及多次对话之间被记住；2）依赖一个经过定制后训练的LLM，该LLM使用工具调用架构来解释对话的上下文和底层意图，然后有效地选择、排序和投放广告；3）将广告选择过程与ChatGPT的答案生成分开运行，放在其自己的服务中，以防止广告影响答案并保持ChatGPT的中立声音。我们使用经过后训练的LLM来编排整个广告流程，根据用户当前轮次和对话历史确定在正确时间展示正确的广告。虽然像这样自举一个自我改进的广告系统过去需要数年时间，但ChatGPT Ads在推出后不到200天就达到了10亿美元的年化收入运行率；如今，自推出以来已有超过100,000名广告主在ChatGPT上投放了广告。
广告在智能体聊天中应如何运作？
传统的广告请求通常始于一个定义明确的事件。用户提交搜索查询或打开网页，广告系统收到请求。这类系统相当简单：它检索潜在的广告候选，对其进行排序，运行拍卖以为该机会合理定价，并向用户展示结果广告。ChatGPT并不会自然产生这样一个具体的时刻。
在ChatGPT对话中，人们带着目标而来，而不是一个单一答案的搜索查询。他们可能在规划旅行、为企业选择软件、布置家居或学习新爱好。这些并不都发生在一轮对话中。ChatGPT通常会帮助用户在此过程中厘清真正重要的内容。
例如，我们的工程团队曾问ChatGPT如何为比赛进行训练：对话从关于跑步的一般性问题开始。几轮之后，他们询问有助于训练的鞋子。随着每个约束条件的出现，对话的商业含义也在变化——而这种个性化上下文会在多个会话中演变。一个仅根据第一条消息就采取行动的系统可能会完全检索到错误的意图，可能降低用户体验并妨碍他们。
构建我们的广告系统要求我们超越请求-响应式广告架构，从头构建一个广告技术栈，以在优先考虑用户信任和价值的同时发现潜在的经济机会。
对话记忆，且不影响ChatGPT答案
像传统广告系统那样将每条消息转化为独立请求，在我们的聊天用例中会带来一些风险：1）因过度简化而误读用户目标；2）在用户真实需求尚未明确之前过早启动广告流程；3）展示妨碍而非支持用户旅程的广告；4）在请求每次变化时低效地重新运行广告流程，造成噪音并浪费成本。广告系统（由检索、排序和投放组成）不是围绕单个事件构建，而是维护一个有状态的会话，这意味着广告会话在符合条件的轮次持续期间运行，并随着信息演变而记住和更新信息。ChatGPT将初始请求上下文发送到广告服务器。广告系统跟随并适应发展中的交流，而不是依赖单个扁平化查询。
广告选择过程与ChatGPT的正常响应生成并行运行，以确保广告流程不影响ChatGPT的响应。广告通过一个单独的系统进行过滤和选择，该系统在其自身的资格、质量和投放约束下消费对话。这一重要的架构边界——使用独立模型和独立代码的不同服务——让核心ChatGPT服务器处理生成自然响应；与此同时，广告系统独立评估是否存在合适的广告机会，如果存在，则通过单独的投放流程准备赞助展示位。
广告与ChatGPT答案路径并行运行。
除了保护用户体验之外，这种分离还有一些实际后果。ChatGPT对广告系统没有依赖——这些服务在任何方面都不相互交织，也不共享内容生成模型。因此，如果广告投放系统不可用或速度较慢，ChatGPT的自然响应仍会继续不受影响。这意味着广告系统无法使ChatGPT产品宕机或延迟。这种分离的另一个好处是，它为有价值的广告保持了非常高的门槛。不返回广告是一种普通且成功的结果。系统只有在广告明显对用户和广告主都有益时才会投放广告。
LLM解释对话并调用工具
我们广告技术栈中的另一个关键架构组件是经过后训练的LLM，它解释对话并在智能体循环中运行整个广告流程——对广告系统的核心功能进行工具调用，从检索阶段到排序再到拍卖，最终到投放。我们将这个LLM称为_编排器_。
广告流程的第一部分是理解用户意图以启动检索过程，这是一次快速且刻意广泛的潜在广告来源筛选，以便后续过滤。增量接收对话会带来一个更丰富但也更模糊的检索问题，因为广告系统需要区分当前意图与过时上下文。编排器必须解释对较早消息的引用，识别用户何时是在假设性发言，并避免将每一次对产品或服务的提及都视为购买请求。
广告编排器利用可用的对话和用户上下文，反复迭代以寻找优质广告，并不断选择何时调用哪个工具，其根本目标是为该对话和上下文找到最合适的广告（即在用户价值与广告主价值之间取得平衡的广告）。如果用户选择个性化广告，编排器还会考虑用户过往对话中可用的非敏感信息，以找到最佳广告匹配。
广告编排器迭代调用广告投放工具以寻找有价值的广告。
随着对话的推进，广告编排器获得更多更新信息，编排器可以基于更新后的上下文运行新一轮工具调用，以找到更好的广告并将其返回给客户端，客户端随后可以在这些新广告及时到达时使用它们。
编排器的设计旨在平衡用户价值与广告主价值，始终将用户放在首位。
广告系统由各个独立工具组成，编排器迭代调用这些工具，为对话寻找最佳广告。在高层次上，编排器将对话转化为简短的文本摘要，然后将其转化为语义嵌入（存储的含义，便于广告系统筛选），使用这些语义嵌入检索广告候选，对这些候选进行资格过滤（基于预算、用户设置和其他初步检查），评估其质量和相关性，并进行最终排名，以识别在聊天回复末尾放置的高价值机会。因此，每个广告都必须满足资格和相关性的高标准，才有资格被放置。
准备捕捉意图的检索查询
编排器LLM首先准备一个或多个代表相关商业意图的查询。这可以包括重写对话上下文，以拓宽商业可能性，超越1：1搜索查询，然后创建语义表示，其中编排器将多轮对话提炼为检索系统的摘要版本——以聚焦的方式从我们的数据库中检索广告。
只有当深入理解用户意图时，广告放置才会对用户和广告主都更好。多个查询可以保留意图的不同方面。例如，关于规划旅行的对话可能包含与交通、住宿或活动相关的不同需求。检索系统可以保留这些区别，而不是将整个对话压缩成一个字面字符串。
举个例子，让我们看一个关于徒步鞋的潜在对话序列：
去优胜美地两天旅行应该准备什么？
下周会冷吗？
新的[插入品牌]产品线？
尽管用户没有将鞋品牌问题与优胜美地旅行联系起来，但这段对话在我们的广告系统中可能由两个查询表示，例如[适合徒步旅行的鞋子]和[适合旅行的新[品牌]产品线]。这可能只是第一次尝试；编排器设计为对这些表示进行迭代，直到在我们的广告库存中找到对用户具有高价值的广告。
检索可能的广告
检索是创建一个刻意宽泛的广告选项池的过程。候选可能来自不同的检索策略，并可以在相同的投放约束下竞争。我们构建多个索引，针对不同的系统和产品约束进行优化（例如，产品feed广告的索引在设计时会考虑正面或负面产品评论，以获取最佳可能的广告。这与其他可能没有相关评论的广告无关）。每个索引都针对某种版本的近似最近邻（ANN）搜索进行优化，使用代表用户意图的嵌入。这种ANN搜索是一种用于大规模语义索引检索的近似算法，意味着广告被非常快速地获取，接近一个好的解决方案，而不是寻找“正确”的解决方案，同时保留大多数相关候选。
广告系统在广告检索过程中使用重写查询创建语义嵌入，并生成广泛的广告候选池。
过滤不合格候选
过滤的目标是消除所有在相关性、出价和预算方面不符合放置标准的广告候选。根据候选和配置，过滤检查可以包括创意和活动可用性（活动或广告创意是否活跃）、活动定向（例如，活动允许在哪些地区运营）、政策限制（关于可以广告内容的合规要求）、预算可用性（活动是否仍有预算可花费）、投放节奏（活动现在是否应该花费预算，而不是一天中的其他时间）、放置兼容性（此广告有资格参与哪些类型的对话），以及广告主和活动级别的去重（为每个广告主选择适当数量的广告，以确保企业间的公平参与）。
评估相关性和质量
通过资格检查的候选进入评分阶段，编排器在此阶段调用各种评分系统——用于投放考虑因素，如语义相关性（广告是否与用户目标相关？）、预测参与度（广告是否可能被查看、点击并转化为广告主期望的结果？）、历史表现（广告在向用户展示时迄今为止表现如何？）。编排器还在拍卖前过滤广告以确保相关性和安全性。这些系统将范围缩小到准备拍卖的较小候选池，但它们仍不决定最终投放的广告。
运行广告拍卖
编排器在对话上下文中评估准备好的候选，并选择哪些广告候选足够合理以进入最终拍卖。编排器不直接决定将投放哪个广告，也不设定价格。它提名上下文合适的候选，供拍卖工具评估。
拍卖应用最终投放机制，包括拍卖准入（通过相关性和价值的最低阈值）、投放节奏（更均匀地花费广告预算）、出价和拍卖特征计算、质量调整排名、定价和最终选择。
最终资格检查
拍卖后，广告可能因两种方式未能投放，这两种方式都特定于ChatGPT对话媒介。
广告在聊天中可能显得不合适：即使对话本身被完整性模型（决定何时适合投放广告的模型）判定为可安全投放广告，且广告本身也被认定符合政策，有时广告在特定对话语境中仍可能显得不合适。编排器会阻止这些广告展示。
广告请求可能无法及时到达：如果ChatGPT模型已准备好响应，但广告尚未准备好投放，广告请求就会超时，广告便不会被送达。因此，广告系统的一个目标是尽可能快地运行。ChatGPT模型的响应时间是动态的，我们不会为了等待广告加载而延迟聊天响应。
如果满足上述所有检查，我们会将广告发送至前端进行渲染。我们将其视为服务器端广告送达，但我们仍可能不会向用户展示该广告——这是有意设计的。
最后一步：向用户展示广告
在ChatGPT这样的对话式产品中，服务器端送达广告创意并不保证广告会被展示；广告还必须及时到达以被纳入当前轮次。广告创意包括标题、描述、目标链接以及任何行动号召。此外，广告系统还会返回一个模型生成的前言，这是一段简短、中立的介绍，解释广告与对话的关联。将前言与创意分开，既保留了广告主的信息，又保持了ChatGPT声音的中立性。
ChatGPT前端将前言和广告创意作为一个包接收。如果它在ChatGPT的响应完全生成之前到达，前端会在ChatGPT的响应下方展示广告，并明确标注为赞助内容。如果到达太晚，该轮次就不会展示广告。这就是服务器端广告送达与面向用户的广告曝光之间的区别。
获胜者选择与送达是独立的事件。被选中的广告只有在ChatGPT批准并展示该投放位置且送达被确认后，才成为一次送达。
我们的广告技术栈使用传统的日志记录和数据管道，这有三个主要好处：广告主可以更轻松地将其现有系统与我们的技术栈集成，广告主可以利用报告数据改进其策略，我们的团队可以找到系统中需要改进的领域。除了这些报告和优化工具外，我们还部署了一个高质量模型来评估我们的送达情况并训练其他广告模型，从而创建一个强大的自我改进循环。
详细的事件分解有助于我们孤立地理解和改进广告系统的每个部分。日志处理系统还记录细粒度的结果，例如：
该轮次不符合广告投放条件。
广告会话已启动但未请求检索。
检索未返回任何候选。
候选已被检索，但未能通过水合或资格检查。
广告已送达，随后收到了互动。
这些详细的分解有助于我们孤立地改进广告投放系统的每个部分。改进机会检测所需的证据与改进检索、候选质量、竞价参与或送达可靠性所需的证据不同。
送达、投放和质量系统观察的是生命周期中不同的部分。隐私受控的处理决定了哪些数据可用于衡量和模型改进。
高能力模型评估并改进整个技术栈
基于模型的评估背后的理念是，我们最强、推理能力最高的模型观察并评判我们系统的结果，然后通过训练后训练LLM使其表现更好来改进它。例如，如果我们最强大的模型收集反馈并训练这些小型工作器尽可能做好工作，我们就可以使用更小、更高效的模型或推理能力较低的模型来进行编排或检索。
人类反馈引导有品位的方向
我们收集并依据人类反馈（用户的点击和隐藏）采取行动，同时还有用户调查以及广告主通过我们的Ads Manager提供的直接反馈。我们还在构建过程中让团队随时接受反馈，并直接倾听ChatGPT用户和广告主的需求。这一反馈来源比模型的观察性反馈更能指引我们的方向，也是让我们能够快速迭代到正确产品决策的部分原因。模型或许能够理解用户意图并进行批判性思考以提供有价值的内容，但品味是由人来塑造的。
下一步
一年前，我们还没有广告系统，只有少数人在思考这个领域。现在我们拥有一个强大的广告系统，支撑着超过10亿美元的年化运行率，并由基于LLM的编排器运行广告流程。Codex是一个根本性的力量倍增器，使我们能够以无与伦比的速度引导我们的系统实现这一重要的使用里程碑。从一开始，我们就建立了团队和开发工作流程，使用Codex来快速构建和扩展系统。我们为Codex构建了护栏，以可靠、安全地交付代码。同时，我们为Codex设置了数据基础设施插件，以大幅收紧洞察收集和系统改进的循环，包括新产品功能、质量改进和更好的系统性能。
我们系统的边界（植根于我们的广告原则）与基于LLM的编排器的结合，使我们能够在不将每次对话都视为广告请求的情况下让广告变得有用。展望未来，我们将继续尝试更动态的广告格式，以提升用户价值（例如让用户能够通过广告直接与企业对话）和广告主价值。该技术栈的自我改进架构建立在OpenAI模型之上，并具有持续的反馈循环，将加速我们随时间推移不断改进相关性和个性化的能力。
Traditional advertising systems are built to respond to discrete units of user intent. A user searches for or views something online, the ads system receives those queries and page views as events, and the system looks for matching ads based on those events. Building an ads stack for ChatGPT was different: user intent develops across conversations and shifts over multiple turns of a conversation, sometimes without a fitting advertising moment. To support this new paradigm, we built a bespoke ads delivery system. This new type of ad stack is based on a custom, post-trained frontier LLM that makes tool calls for retrieval (identifying the top options), ranking (predicting user engagement), relevance (evaluating the usefulness of the ad), and running auctions for final ad selection and pricing.
Our ads system supports the nuance of evolving user goals by making three key design decisions: 1) implementing stateful ads sessions, meaning information is remembered across turns of a conversation and across multiple conversations, 2) relying on a custom, post-trained LLM that uses a tool call architecture to interpret a conversation’s context and underlying intent, and then effectively select, rank, and deliver ads, and 3) running the ads selection process separately from ChatGPT’s answer generation, in its own service, to keep ads from influencing answers and maintain ChatGPT’s neutral voice. We use our post-trained LLM to orchestrate the entire ads flow, determining the right ad to surface at the right time based on both the user’s current turn and conversation history. While bootstrapping a self-improving ads system like this used to take years, ChatGPT Ads reached $1 billion in annualized revenue run rate less than 200 days after launch; now, more than 100,000 advertisers have run ads on ChatGPT since launch.
How should ads work in agentic chat?
A conventional advertising request usually starts with a well-defined event. A user submits a search query or opens a webpage and the ads system receives a request. This type of system is fairly simple: it retrieves potential ad candidates, ranks them, runs an auction to appropriately price the opportunity, and shows the resulting ad to the user. ChatGPT does not naturally produce such a concrete moment.
In a ChatGPT conversation, people arrive with goals rather than a one-answer search query. They might be planning a trip, choosing software for their business, furnishing a home, or learning a new hobby. This doesn’t all happen in one turn of a conversation. ChatGPT often helps the user clarify what matters along the way.
As an example, our engineering team asked ChatGPT how to train for a race: A conversation begins with a general question about running. Several turns later, they ask about shoes to help train. The commercial meaning of the conversation changes as each constraint arrives—and this personalized context evolves across multiple sessions. A system that acted on the first message could retrieve the wrong intent entirely, potentially degrading the user’s experience and getting in their way.
Building our ads system required us to move beyond the request-response advertising architecture and build an ads stack from scratch to find potential economic opportunities while prioritizing user trust and value.
Conversation memory, without influencing ChatGPT answers
Turning every message into a standalone request, like a traditional ads system, would have carried a few risks in our chat use case: 1) misreading the user goal by oversimplifying it, 2) beginning the advertising flow too soon, before the user’s real need has become clear, 3) showing ads that get in the way of the user journey instead of supporting it, and 4) inefficiently rerunning the ads flow every time the request changes, creating noise and wasting cost. Instead of building around individual events, the ads system (consisting of retrieval, ranking, and delivery) maintains a stateful session, meaning the ads session runs for the duration of an eligible turn, remembering and updating information as it evolves. ChatGPT sends the initial request context to the ads server. The ads system follows and adapts to the developing exchange rather than relying on a single flattened query.
The ads selection process runs alongside ChatGPT’s normal response generation to ensure the ads flow doesn’t influence ChatGPT’s responses. Ads are filtered and selected through a separate system consuming the conversation under its own eligibility, quality, and delivery constraints. This important architectural boundary—different services that use separate models and separate code—lets core ChatGPT servers handle generating the organic response; meanwhile, the ads system independently evaluates whether there’s an appropriate advertising opportunity and, if so, prepares a sponsored placement through a separate serving process.
Advertising runs alongside the ChatGPT answer path.
Beyond protecting the user experience, this separation has some practical consequences. ChatGPT has no dependency on the ads system—the services are in no way intertwined and don’t share a content generation model. So if the ads serving system is unavailable or slow, ChatGPT’s organic response continues unaffected. This means the ads system can’t take down or delay the ChatGPT product. The other benefit of this separation is that it keeps the bar very high for valuable ads. Returning no ad is an ordinary, successful outcome. The system only delivers an ad if it’s clearly beneficial to users and advertisers.
An LLM interprets conversations and calls tools
The other key architectural component in our ads stack is the post-trained LLM that interprets conversations and runs the entire ads flow in an agentic loop—making tool calls to the core functions of the ads system, from the retrieval stage to ranking to auction and, ultimately, delivery. We call this LLM the orchestrator.
The first part of an ads flow is understanding user intent to start the retrieval process, which is a fast and deliberately broad sourcing of potential ads to later filter through. Receiving the conversation incrementally creates a richer but more ambiguous retrieval problem because the ads system needs to distinguish current intent from stale context. The orchestrator must interpret references to earlier messages, recognize when a user is speaking hypothetically, and avoid treating every mention of a product or service as a request to buy something.
The ads orchestrator uses the available conversation and user context, iterating to find good ads and repeatedly choosing when to call which tool with the underlying goal of finding the most appropriate ad (the ad that balances high user value and high advertiser value) for that conversation and context. If the user chooses to personalize ads, the orchestrator also considers available nonsensitive information about the user’s past conversations to find the best ad matches.
The ads orchestrator iteratively calls ads delivery tools to find valuable ads.
As the conversation progresses and the ads orchestrator gets more updated information, the orchestrator can run a fresh set of tool calls with the updated context to find better ads and return them to the client, which can then use these new ads if they arrive in time.
The orchestrator is designed to balance user value and advertiser value, always putting users first.
The ads system consists of individual tools, and the orchestrator calls them iteratively to find the best ads for a conversation. At a high level, the orchestrator turns conversations into brief text summaries, which are then turned into semantic embeddings (stored meanings that are easier for an ads system to sift through), retrieves ad candidates using those semantic embeddings, filters those candidates for eligibility (based on budget, user settings, and other preliminary checks), assesses their quality and relevance, and does a final ranking to identify high value opportunities for placement at the end of a chat response. Each ad must therefore meet a high bar on eligibility and relevance in order to be eligible for placement.
Preparing retrieval queries that capture intent
The orchestrator LLM first prepares one or more queries representing the relevant commercial intent. This can include rewriting conversation context to broaden the commercial possibilities beyond 1:1 search queries and then creating semantic representations, where the orchestrator distills a multiturn conversation into a summarized version for the retrieval system—retrieving ads from our database in a focused way.
Ad placements will be better for both users and advertisers if they only appear when there’s deep understanding of the user’s intent. Multiple queries can preserve different aspects of intent. A conversation about planning a trip, for example, might contain distinct needs related to transportation, lodging, or activities. The retrieval system can preserve these distinctions rather than compressing the entire conversation into one literal string.
As an example, let’s look at a potential conversation sequence about hiking shoes:
What should I cover on a two-day trip to Yosemite?
Will it be cold next week?
New [insert brand] product lines?
Although the user hasn’t connected the shoe brand question to the Yosemite trip, this conversation might be represented in our ads system by two queries, such as [shoes appropriate for hiking trip] and [new [brand] product lines good for travel]. This might only be the first attempt; the orchestrator is designed to iterate on these representations until it finds ads in our inventory that are highly valuable to the user.
Retrieving possible ads
Retrieval is the process of creating a deliberately broad pool of ad options. Candidates may come from different retrieval strategies and can later compete under the same serving constraints. We build multiple indices that optimize for different system and product constraints (for example, the index for product feed ads is designed to be aware of positive or negative product reviews as it fetches the best possible ads. This is not relevant to other ads that may not have reviews associated with them). Each index is optimized for some version of approximate-nearest-neighbor (ANN) search, using embeddings representing the user’s intent. This ANN search is an approximation algorithm for retrieval over large semantic indices, meaning ads are fetched very quickly, getting close to a good solution rather than looking for “the right” solution, while retaining most of the relevant candidates.
The ads system uses rewritten queries to create semantic embeddings during the ad retrieval process and produce a broad pool of ad candidates.
Filtering ineligible candidates
The goal of filtering is to eliminate all ad candidates from consideration that don't meet the bar for placement when it comes to relevance, bids, and budget. Depending on the candidate and configuration, filtering checks can include creative and campaign availability (whether the campaign or ad-creatives are active), campaign targeting (e.g., which locales a campaign is allowed to operate in), policy restrictions (compliance requirements around what can be advertised), budget availability (whether or not a campaign still has budget available to spend), pacing (whether a campaign should be spending budget now versus another time in the day), placement compatibility (what kinds of conversations this advertisement is eligible for), and advertiser and campaign level deduplication (picking an appropriate number of ads per advertiser to ensure fair participation across businesses).
Evaluating relevance and quality
Candidates that survive eligibility checks move on to a scoring phase, where the orchestrator makes tool calls to various scoring systems—for serving considerations such as semantic relevance (is the ad relevant to the user’s goal?), predicted engagement (is the ad likely to get viewed, clicked, and converted into the advertiser’s desired outcome?), historical performance (has the ad performed well when shown to users so far?). The orchestrator also filters ads to ensure relevance and safety before the auction. These systems narrow the field into a smaller candidate pool ready for auction, but they still don’t determine the final delivered ad.
Running the ads auction
The orchestrator evaluates the prepared candidates in the context of the conversation and chooses which ad candidates are plausible enough to enter the final auction. The orchestrator doesn’t directly decide which ad will be served, nor does it set a price. It nominates contextually appropriate candidates for the auction tool to evaluate.
The auction applies the final serving mechanics, including auction admission (passing a minimum threshold of relevance and value), pacing (spending ad budget more evenly), bid and auction-feature computation, quality-adjusted ranking, pricing, and final selection.
Final eligibility checks
After the auction, there are two ways an ad might fail to deliver, both specific to the ChatGPT conversational medium.
The ad might not feel appropriate in the chat: Even though the conversation itself was deemed safe for ad placement by integrity models (the models that decide when it’s appropriate to serve an ad), and the ad itself was deemed policy-compliant, sometimes the ad might feel inappropriate in the context of certain conversations. The orchestrator blocks these ads from being shown.
The ad request might not arrive in time: If the ChatGPT model is ready to respond, but the ad is not yet ready to place, the ad request times out and the ad doesn’t get delivered. One goal of the ads system, therefore, is to run as fast as possible. The ChatGPT model response time is dynamic, and we don’t delay chat responses to wait for ads to load.
If all of the above checks are met, we send the ad to the frontend for rendering. We consider this a server-side ad delivery, but we still might not show the ad to the user—and this is by design.
The final step: showing the ads to the user
In a conversational product like ChatGPT, server-side delivery of an ad creative does not guarantee an ad will be displayed; the ad must also arrive in time to be included in the current turn. The ad creative includes the title, description, destination link, and any call to action. Additionally, a model-generated preamble, which is a short, neutral introduction explaining how the ad relates to the conversation, is also returned by the ads system. Keeping the preamble separate from the creative preserves the advertiser’s message while keeping ChatGPT’s voice neutral.
The ChatGPT frontend receives the preamble and ad creative as a bundle. If it arrives before ChatGPT's response is fully generated, the frontend displays the ad below ChatGPT’s response, clearly labeled as sponsored. If it arrives too late, the ad is not shown for that turn. This is the difference between server-side ad delivery and a user-facing ad impression.
Winner selection and delivery are separate events. A selected ad becomes a delivery only after ChatGPT approves and displays the placement and the delivery is acknowledged.
Our advertising stack uses traditional logging and data pipelines, which have three main benefits: advertisers can more easily integrate their existing systems with our stack, advertisers can improve their strategies with the reporting data, and our team can find areas of the system to improve. Beyond these reporting and optimization tools, we deploy a high quality model to evaluate our delivery and train other ads models, creating a powerful self-improvement loop.
Detailed breakdowns of what happened help us understand and improve each part of the ad system in isolation. The logs processing system also records granular outcomes such as:
The turn was not eligible for advertising.
An ads session started but no retrieval was requested.
Retrieval returned no candidates.
Candidates were retrieved but failed hydration or eligibility.
An ad was delivered and later received an interaction.
These detailed breakdowns help us improve each part of the ad serving system in isolation. Improving opportunity detection requires different evidence from improving retrieval, candidate quality, auction participation, or delivery reliability.
Delivery, serving, and quality systems observe a different part of the lifecycle. Privacy-controlled processing determines what may be used for measurement and model improvement.
High-power models evaluate and improve the entire stack
The idea behind model-based evaluation is that our strongest, highest-reasoning models watch and judge the results of our system, then improve the post-trained LLM by training it to perform better. For instance, we can use smaller, more efficient models or lower-reasoning models for orchestration or retrieval if our most powerful model gathers feedback and trains these small workers to do the best job possible.
Human feedback steers tasteful direction
We gather and act on human feedback (clicks and hides from users), as well as surveys for users and direct feedback from advertisers through our Ads Manager. We also make our team available for feedback as we build, and directly listen to what both ChatGPT users and advertisers want. This source of feedback informs our direction even more than the model’s observational feedback and is part of what allowed us to iterate toward the right product decisions quickly. The model may be able to understand user intent and think critically to deliver something valuable, but people shape taste.
What’s next
A year ago, we had no ads system and only a few people thinking about this problem space. Now we have a robust ads system powering more than $1 billion in annualized run rate, with an LLM-based orchestrator running the ads flow. Codex was a fundamental force multiplier that allowed us to bootstrap our system to achieve this major usage milestone with unparalleled speed. From the start, we set up the team and development workflows to use Codex to rapidly build and scale the system. We built guardrails for Codex to reliably and safely ship code. In parallel, we set up data infrastructure plugins for Codex to massively tighten the loop of insight gathering and landing improvements to the system, including new product features, quality improvements, and better system performance.
The combination of our system’s boundaries (grounded in our advertising principles) and our LLM-based orchestrator lets us make advertising useful without treating every conversation as an ad request. Looking ahead, we’ll continue to experiment with more dynamic ad formats to increase user value (e.g. giving users the ability to talk directly to businesses through ads) and advertiser value. The stack’s self-improving architecture, built on OpenAI models with continuous feedback loops, will accelerate our ability to keep improving relevance and personalization over time.
本文内容采集自官方网站，排版和翻译可能与原页面存在差异。
阅读官方全文