905: Why RAG Makes LLMs Less Safe (And How to Fix It), with Bloomberg’s Dr. Sebastian Gehrmann

这是第905期节目，嘉宾是医生。

This is episode number nine zero five with Doctor.

格赫曼，彭博社负责任人工智能负责人。

Gehrmann, Head of Responsible AI at Bloomberg.

本期节目由对话式分析平台Adverity和戴尔AI工厂与NVIDIA联合呈现。

Today's episode is brought to you by Adverity, the conversational analytics platform, And by the Dell AI Factory with NVIDIA.

欢迎收听超级数据科学播客，这是数据科学领域收听人数最多的播客。

Welcome to the Super Data Science Podcast, the most listened to podcast in the data science industry.

每周，我们都会为您带来有趣且鼓舞人心的人物与思想，探索机器学习、人工智能及相关技术的前沿，这些技术正在让我们的世界变得更好。

Each week, we bring you fun and inspiring people and ideas exploring the cutting edge of machine learning, AI, and related technologies that are transforming our world for the better.

我是您的主持人，乔恩·克劳恩。

I'm your host, Jon Krohn.

感谢您今天与我一同收听。

Thanks for joining me today.

现在，让我们化繁为简。

And now, let's make the complex simple.

欢迎回到超级数据科学播客。

Welcome back to the Super Data Science Podcast.

今天我们的嘉宾是塞巴斯蒂安·盖尔曼博士，他是一位在清晰阐释前沿人工智能研究方面极具天赋的人。

Today, our guest is doctor Sebastian Gehrmann, an exceptionally gifted individual at thoroughly and clearly explaining cutting edge AI research.

塞巴斯蒂安是彭博社负责任人工智能部门的负责人，彭博社是一家总部位于纽约的金融软件、数据和媒体公司，拥有两万名员工，规模庞大。

Sebastian is head of responsible AI at Bloomberg, the New York based financial software data and media company that with 20,000 employees is huge.

此前，作为彭博社自然语言处理部门的负责人，他领导了语言技术的开发与应用，为彭博终端带来了最先进的人工智能增强产品。

Previously, as head of NLP at Bloomberg, he directed the development and adoption of language technology to bring the best AI enhanced products to the Bloomberg terminal.

在加入彭博社之前，他曾是谷歌的高级研究员，参与了大语言模型的开发，包括开创性的Bloom和PaLM模型。

Prior to Bloomberg, he was a senior researcher at Google where he worked on the development of LLMs, including the groundbreaking Bloom and Palm Models.

他拥有哈佛大学计算机科学博士学位。

He holds a PhD in computer science from Harvard University.

今天的节目内容略微偏向技术型听众，比如数据科学家、人工智能工程师和软件开发者，但任何希望了解最新人工智能研究进展的人都值得一听。

Today's episode skews slightly towards our more technical listeners like data scientists, AI engineers, and software developers, but anyone who'd like to stay up to date on the latest AI research may want to give it a listen.

在本期节目中，塞巴斯蒂安详细阐述了一个令人震惊的发现：尽管普遍认为检索增强生成（RAG）能提升安全性，但实际上它反而使大语言模型变得更不安全。

In today's episode, Sebastian details the shocking discovery that retrieval augmented generation, RAG, actually makes LLMs less safe despite the popular perception of the opposite.

为什么有益且无害的AI之间的区别比你想象的更重要，当RAG与企业数据结合时出现的隐藏攻击面，当LLM超出其设计上下文窗口时可能产生的问题，以及如何确保你的LLM在特定应用场景中做到有益、诚实和无害。

Why the difference between helpful and harmless AI matters more than you think, the hidden attack surfaces that emerge when you combine RAG with enterprise data, the problems that can happen when you push LLMs beyond their intended context window, and what you can do to ensure your LLMs are helpful, honest, and harmless for your particular use cases.

好的。

Alright.

你准备好听这期非凡的节目了吗？

You ready for this exceptional episode?

我们开始吧。

Let's go.

Sebastian，欢迎来到Super Data Science播客。

Sebastian, welcome to the Super Data Science Podcast.

很高兴你来参加我们的节目。

It's great to have you on the show.

今天你从哪里连线？

Where are you calling in from today?

非常感谢你邀请我。

Thank you so much for having me.

我从费城打来的。

I'm calling in from Philadelphia.

不错。

Nice.

在录制时，纽约这里将迎来酷热天气，气温最高将达到100华氏度。

It's gonna be a scorcher here in New York coming up at the time of recording, heading up to 100 degrees Fahrenheit.

希望你那边能保持凉爽。

I hope you're able to stay cool down there.

是的，我们这儿也差不多。

Yeah, not too much different here.

昨天傍晚我们收到了高温预警，接下来几天会很难熬。

We all got the heat warning yesterday evening, and it's going to be a rough couple days.

是的，是的，是的。

Yeah, yeah, yeah.

今年我们第一次要测试空调系统了。

We'll test the air conditioning systems for the first time this year.

当然。

For sure.

好的，你是彭博社负责任人工智能部门的负责人，彭博社是一家举世闻名的金融软件、数据和媒体公司。

All right, so you are the head of responsible AI at Bloomberg, a hugely well known financial software, data, and media company.

在你加入彭博社之前，你就一直在研究自然语言生成与可信赖、透明、可靠的负责任人工智能解决方案的交叉领域。

Long before you started at Bloomberg, you were researching at the intersection of natural language generation and responsible AI solutions that are trustworthy, transparent, reliable.

而现在，你把这些研究整合到了你最新的论文中，当然我们会在节目笔记中提供这篇论文的链接。

And now you've kind of brought all those things together with your latest paper, which of course we'll link to in the show notes.

这篇论文名为《RAG语言模型并不更安全》。

It's called RAG LMs are not safer.

它对大型语言模型的检索增强生成技术进行了安全性分析。

It's a safety analysis of retrieval augmented generation for large language models.

研究得出了一个反直觉的结论，也正是我邀请你做客节目的主要原因——当我发现RAG实际上让大型语言模型更不安全、输出更不可靠时，我震惊了，因为我的理解本以为它应该恰恰相反。

And this finds counterintuitively, and this is the main reason why I wanted to have you on the show, is because it blew my mind when I discovered that RAG actually makes LLMs less safe and their outputs less reliable because my understanding is that it was supposed to be exactly the opposite.

是的，完全正确。

Yeah, absolutely.

是的，我应该提一下这一点。

Yeah, I should mention this.

这是一篇去年由一位实习生主导完成的论文，他与我们首席技术官办公室和AI工程团队的同事合作完成了这项工作。

This was a paper that we had an intern work on last year who has been working with colleagues from our CTO's office and the AI engineering organization.

这是我们在更广泛的负责任AI研究主题下开展的工作，我们的目标是确保如果我们的客户或用户使用我们的AI系统时做了不该做的事，我们能够识别、阻止并长期监控这些行为，这一点至关重要，尤其是在我们所处的这种高度监管的行业中。

This was part of our broader responsible AI research theme that we have going where we want to make sure that if our clients or our customers use our AI, that if they use it for something that they shouldn't, that we can identify this, we can block this, we can monitor this over time, which is incredibly important, especially for such heavily regulated industries, such as the one that we are operating in.

我们的客户面临众多规章制度。

There are so many rules that apply to our clients.

他们非常希望确保没有人会故意或无意地滥用我们的技术。

They really want to make sure that people can't abuse purposefully or completely accidentally our technology.

作为这一研究方向的一部分，我们关注RAG的安全性，因为最终，RAG是一种无处不在的技术，对于将回答锚定在可信的数据源上至关重要。

As part of that research direction, we were interested in the safety of RAG because in the end, RAG is such a ubiquitous technology and it is absolutely necessary to ground responses and trusted sources of data.

如果我们想回答那些基于我们所处领域的广泛且极具挑战性数据的问题——每天有数千亿条数据流入我们的系统——就不可能绕开这一点。

There's no way around that if you want to answer questions that are grounded in this broad and really challenging area that we operate in where there's hundreds of billions of pieces of data coming into our systems every single day.

要实现这一点，唯一的方法就是使用RAG，或其他类似的检索增强技术或文档锚定技术。

The only way to do this is if you use RAG or some kind of other similar retrieval augmented technology or document grounded technology.

我们的论文将不安全的查询进行了关联。

What our paper did was it coupled unsafe queries.

想象一下你可能想问大型语言模型的最糟糕的问题。

Think of the worst thing that you might want to ask a large language model.

我该如何进行内幕交易？

How do I do insider trading?

我们将这个问题与RAG结合了起来。

We coupled that with RAG.

我们从维基百科检索了完全不当的文档。

We retrieved completely obnoxious documents from Wikipedia.

虽然我们研究的大多数大型语言模型对原始问题没有回应，但当与这些完全无害的维基百科文档结合时，回应却常常变得不安全，这就是为什么我们给这篇论文起了一个非常强烈的标题，因为所有人都在谈论RAG如何让事情更安全。

While most large language models that we looked at didn't respond to the original question, when coupled with these completely harmless documents from Wikipedia, the response was often then unsafe, which is why we gave the paper this title that was very, very strong because everyone has been talking about how RAG makes things more safe.

它们更加有依据。

They are more grounded.

它们基于真实的事实信息，而不是让大型语言模型随意编造内容。

They are grounded in actual factual information rather than using the large language model to kind of make up things.

我们发现，实际上RAG可以绕过大型语言模型提供商内置的安全机制。

What we found is that actually RAG can circumvent these built in safety mechanisms that large language model providers put into these models.

我明白了，我明白了。

I gotcha, I gotcha.

现在我懂了。

Now I understand.

而且我想，当我们讨论RAG时，可能还应该提一下——

And I guess we should also, it occurs to me as we're talking about RAG and probably a

很多听众可能已经了解检索增强生成是什么，但也许我们该花几分钟解释一下。

lot of listeners out there are aware of what retrieval augmented generation is, but maybe we should spend just a couple of minutes explaining it as well.

我不知道，你可能更擅长解释这个。

I don't know, you can probably do a better job of this.

但总的来说，就像你刚才举的例子，你可以使用维基百科、互联网公开内容的文档，而RAG的常见用例之一是使用大量内部文档。

But at a high level, it's you already kind of gave an example there where you can be using documents from Wikipedia, the public internet, or it could be a common use case with RAG is to have lots of documents, internal documents.

比如你是一家律师事务所，积累了数百万份多年来保存的合同。

So you might be a law firm with millions of contracts that that your firm has saved from over the years.

你可以将所有这些数百万份合同放入一个RAG类型的系统中。

And you could put all of those millions of contracts into a RAG type of system.

你可以使用自然语言查询所有这些数百万份文档。

And you can search, you can use natural language to query over all of those millions of documents.

最相关的文档会从数百万份中被筛选出来。

The most relevant ones will be pulled out from the millions.

然后，你通常可以把这些被筛选出来的少量文档——可能只有五六份或十几份——放入某个大语言模型的上下文窗口中。

And then you can you could typically fit that small number of documents that's pulled out, maybe it's half a dozen or a dozen into the working memory of a given large language model.

接着，你就能得到一个自然语言形式的响应结果。

And then you can have a natural language response come out as a result of that.

你觉得我刚才对RAG的解释怎么样？

What do you think about my RAG explanation there?

完全正确。

Absolutely correct.

我想再补充一点，如果我们讨论的是大语言模型，这是一项这样的技术：在某个时刻训练完模型后，它就固定不变了。

I think just to put some more color on this, if we're talking about Lateral Language Model, very much this is a technology where at one point in time you train a model and then once you're done training this model, it is stuck.

你冻结模型，然后说：好的，这个模型的知识截止日期是2021年1月。

You freeze the model and you say, Okay, this is the model, the knowledge cutoff is January 2021.

如果你问一个需要2021年之后知识的问题，唯一能把这些信息输入模型的方法就是通过上下文提供。

Then if you ask a question that requires knowledge from beyond 2021, the only way that you can get this into the model is by actually providing it in its context.

几年前，研究人员在为大型语言模型开发RAG技术时提出：最自然的做法是将搜索系统与大型语言模型结合起来。

Researchers a couple of years ago when they developed this RAG technique for large language models in particular said, well, the most natural thing to do is to couple a search system with the large language model.

大型语言模型在综合、总结和提取信息方面非常出色，但这种时间上的冻结确实是个大问题。

Large language model very good at synthesizing, summarizing, extracting information, but this freeze in time is really bad.

为了解决这个问题，我们接入了一个搜索工具，这就是为什么它被称为检索增强生成——在RAG成为论文之前，许多搜索引擎就已经提供答案摘要了。

To overcome it, we plug in a search tool and that's why it's called retrieval augmented generation or before RAG was a paper, a lot of search engines already gave answer snippets.

那时，这被称为搜索增强的问答系统。

At that point it was search enhanced question answering.

但如今，所有这些都演变成了我们用来泛指这种包含检索和生成步骤的通用术语。

But they all have become this overall term that we use for not just this vanilla setup where we have a retrieval step and the generation step often.

我们现在用RAG作为总称，指任何通过从外部检索数据来为大型语言模型的响应提供依据的方法。

We use RAG as kind of the overarching term for anything where you ground a Large Language Model response with some kind of data that you retrieve from somewhere.

这些数据可能是结构化的，也可能是非结构化的，可能来自多个不同的来源。

That could be structured data, could be unstructured data, it could be unstructured or structured data from multiple different sources.

所有这些都属于检索增强生成这个大范畴，这也是为什么它成为当今讨论的热门话题，因为这是目前构建应用程序的主要方式之一。

All of these are kind of under this whole umbrella term of retrieval augmented generation, which is why this has become such a big topic to talk about because this is one of the predominant ways in which applications today are built.

当然。

For sure.

我喜欢你使用的这个‘接地’术语。

And I like how you're using this term grounding.

我觉得这很有道理。

I think that that makes a lot of sense.

你在最近的一期播客中还使用了另一个术语，强调RAG对于将生成式AI产品锚定在真实可信的信息中至关重要。

Another term that you've used in a recent podcast, you were emphasizing that RAG is essential for grounding Gen AI products in actual trusted information.

然而，你提到RAG的架构会创造出不可预测的攻击面。

However, you've described RAG's architecture is creating unpredictable attack surfaces.

所以，我想深入探讨一下这个‘攻击面’的概念。

So that's kind of the other term that I want to get into here, this idea of attack surfaces.

一方面，我们需要RAG来将生成式AI产品锚定在更近期或真正可信的信息上，或者锚定在企业或组织拥有的机密信息上。

So on the one hand, we need RAG for grounding Gen AI products in more recent or an actual trusted information or maybe in confidential information that an enterprise or an organization has.

但与此同时，这也会产生不可预测的攻击面。

But at the same time, this creates these unpredictable attack surfaces.

那么，攻击面到底是什么？

So what the heck are attack surfaces?

是的，关于这一点，我们来探讨一下什么是攻击面。

Yes, so for that, let's explore what we mean by attack surface.

显然，当我们谈到网络安全时，攻击面无处不在，比如那些未受保护的端点，或者可以注入代码的系统。

Obviously, we think about something like cybersecurity, attack surfaces are everywhere where you have unsecured endpoints or you have code that you can inject into.

你还有那些暴露在外的数据库。

You have databases that are just out in the open.

但大型语言模型的情况非常不同，因为除非你主动提供信息，否则它们本身并不存在这类攻击面。

Less language models are very different because unless you give them the information, they don't have that kind of attack surface.

但确实存在其他类型的攻击面或风险，我们通常称之为内容风险，即输入到语言模型中的内容可能要求生成极具危害性的输出，或者输出本身可能违反既定的法规、法律。

But there are other attack surfaces or risks, specifically what we call them typically content risks where either inputs to the Light Language Model can be asking for very harmful output or the output itself could lead to something that is harmful or against the established regulation rules, laws.

这种攻击面在很大程度上取决于你如何使用这个语言模型或你正在构建的应用程序。

This attack surface very much is grounded in the way that you want to use this language model or this application that you're building.

以我们为例，我们是一家金融服务公司。

Take us for example, we're a financial services company.

我们的内容主要聚焦于帮助人们在金融领域进行分析、整合信息、总结信息，并将所有这些内容基于我们彭博终端上的实时数据进行溯源和引用。

Our content is very much focused on helping people conduct analyses in the financial space, synthesize information, summarize information, ground all of this and attribute all of this to our just in time data that we have on our Bloomberg terminal.

对我们而言，攻击面与我们所处的行业领域密切相关。

For us, the attack surface is very much linked to the domain that we operate in.

因此，我们关心的问题包括：有人能否借助语言模型实施金融犯罪？

So what we care about are things like, can someone conduct financial crimes with the help of language models?

它是否可能助长内幕交易？

Can it facilitate insider trading?

它是否会提供未经请求的财务建议，导致人们据此交易并蒙受巨大损失？

Does it give unsolicited financial advice that people might trade on and lose a lot of money?

它是否会造成信息不平衡或信息不对称，将一家公司的交易策略泄露给另一家公司？

Does it create an information imbalance or an asymmetry where it discloses trading strategies from one company to the other?

但我们只是众多使用这些语言模型的案例之一。

But we are just one of many, many examples of people who use these language models.

当我们谈论未预料到的攻击面时，构建语言模型的人无法列举出所有可能的应用方式。

When we talk about unanticipated attack surface, the people who build language models, they can't enumerate every single way in which they are being applied.

这些模型正被应用于医疗、法律、教育，并且如今在全球各地都有应用。

They're being applied to healthcare, they're being applied to law, they're being applied to education, they're being applied everywhere around the world now.

此外，不同司法管辖区和地理区域可能适用不同的法律法规。

On top of that, the jurisdictional differences, the different geographic locations, they might have different laws even applying.

现在，我们有了一个建立在大型语言模型之上的庞大应用网络，但只有一个提供商说：是的，我们的模型是安全的。

Now we have this whole web of applications that are built on top of large language models, but we only have one provider who says, Yeah, actually our model is safe.

要真正预测全球范围内所有相关法规所涵盖的每一种使用场景，是不可能的。

There's no way that would be possible to really anticipate every single use case around the world grounded in all the relevant regulation.

所有这些都指向我们一再强调的核心观点。

All this coming to the main point that we're really trying to keep making over and over.

你必须在你打算部署它们的环境中，真正评估你的AI应用。

You need to really evaluate your AI application in the context you want to deploy them.

因为归根结底，只有开发你所集成的大语言模型应用的组织才了解其自身风险。

Because in the end, only the organization developing the application that you integrate the Large Language Model in understands their risks.

这正是我们开展这类研究的真正原因。

That is really why we're doing this kind of research.

我们希望了解那些与我们构建应用的方式以及使用我们应用的客户相关的特定风险。

We want to understand what are the risks that are specific to us and the way that we're building applications and the clients that use our applications.

当我们谈到未预料到的风险时，这正是核心所在。

When we talk about unanticipated risks, this is very much it.

如果我们不加以衡量，就无法理解这些风险。

We don't understand the risk unless we measure it.

构建模型的人，尤其是当我们使用第三方模型时，并不了解我们的风险。

The people who build models, especially if we use third party models, they don't understand our risks.

我们需要研究这些问题，真正理解风险所在，而不是面对一个不可衡量、不可预知的风险面，我们要建立一个能清晰认知风险并知道如何缓解它们的体系。

We need to study this to really understand and instead of having an unmeasurable unanticipated risk surface, we want to have one where we very much understand what are the risks and how do we mitigate them.

那么，最终你们是否为自己的特定用例建立了一份风险和应对措施的清单？

So does that end up being the case that then you end up having this kind of list of risks and mitigations for your specific use case?

因为这听起来意味着，使用RAG系统或使用LLM的用户必须在自己的特定情境下保持谨慎，因为LLM的开发者无法像你所说的那样预见到所有可能的使用场景。

Because it like, so it sounds like basically it's the user of a RAG setup or the user of an LLM that has to be cautious in their particular circumstance, given that the LLM creator couldn't have anticipated, like you said, all the possible use cases.

对吗？

Is that right?

有点吧。

Slightly.

什么？

What

我的意思是，构建RAG系统的人通常清楚自己为什么要构建它。

I mean really is the people who build the RAG system, they usually know what they're building it for.

他们了解进入数据库的数据，或者至少应该了解。

They understand the data that goes into the database or should at least.

他们明白数据是如何被检索以及如何被整合在一起的。

They understand how data is being retrieved and how it's all being put together.

因此，存在几种风险来源。

Then there are a couple of sources of risks.

第一，是数据本身。

Number one, you have the data.

如果数据中包含危险信息，比如如何在不该藏钱的地方藏钱的指令，当你向大型语言模型询问‘给我相关信息’时，它把这类信息纳入上下文，这就可能成为让语言模型输出有害信息的一个途径。

If there is dangerous information in the data and write an instruction on how to shelter money in places that money shouldn't be sheltered, and you ask the Large Language Model, hey, give me information, and it adds that information into context, that could be one vector of getting harmful information out of the language model.

但还有另一种情况，即大型语言模型自身可能就不安全。

But there is another vector in which the large language model itself could be unsafe.

它可能会主动提供这些建议。

It could be unsolicited, give that advice.

但用户本身也是一个攻击面。

But then the user is another attack vector.

如果用户直接输入这些内容呢？

What if the user types that in?

我该怎么在任何地方藏钱？

How do I shelter money wherever?

我该怎么逃税？

How do I commit tax fraud?

在这种情况下，我们可以依赖大型语言模型来阻止这些查询，但这实际上将大量信任寄托在了大型语言模型的开发者身上，而他们通常与构建RAG系统的组织并非同一实体。

In this case, we can rely on the Large Language Model to block these queries, which really puts a lot of trust in this developer of the Large Language Model that often there is a different entity from the organization that builds the RAG system.

或者，作为RAG系统的构建者，我可以查看这三种情况。

Or as the builder of the RAG system, I can take a look at those three.

我可以观察一下，用户通常会做些什么？

I can look at, okay, what are users typically doing?

用户可能会对我们系统尝试哪些攻击方式？

What are attack vectors that users might be trying with our system?

数据库中包含哪些数据？

What data is in the databases?

我如何确保自己理解这些数据，并防止向无权访问的用户泄露信息？

How do I make sure that I understand this data and safeguard us from exposing information to users that shouldn't have access to this information?

大型语言模型对于我们使用场景的安全性究竟如何？

And how safe is the Large Language Model really for our use cases?

我们的论文主要聚焦于第三种领域，因为我们希望了解语言模型内置的防御机制。

Our paper is very much in that third realm here because we wanted to know the built in defenses of the language model.

它们实际上有多好？在实际部署环境下表现如何？

How good are they actually and how well do they stand up to a rack setup?

在我们的情况中发现，对于所研究的通用危险查询，RAG的安全性会失效，因为语言模型仅针对非RAG环境进行了安全加固，这意味着我们需要在应用程序中构建超越语言模型提供者所给保护措施的防护机制。

In our case, found that for the general purpose dangerous queries that we looked at, RAG safety breaks down because language models really are only secured for non RAG setups, which means that we need to build guardrails around our applications that go beyond what the Light Language Model builders are actually providing to us.

本集由Adverity赞助，这是一家用于大规模连接、管理和使用数据的集成数据平台。

This episode is sponsored by Adverity, an integrated data platform for connecting, managing and using your data at scale.

想象一下，你可以像问同事一样向你的数据提问，并立即得到答案。

Imagine being able to ask your data a question just like you would a colleague and getting an answer instantly.

不再需要翻阅仪表板、等待报告或应对复杂的BI工具。

No more digging through dashboards, waiting on reports, dealing with complex BI tools.

只需在你需要的时候，立即获得所需的洞察。

Just the insights you need right when you need them.

借助Adverity的AI驱动数据对话，营销人员终于能用通俗的英语与数据交流。

With Adverity's AI powered data conversations, marketers will finally talk to their data in plain English.

获得即时答案，做出更明智的决策，更轻松地协作，并将报告时间缩短一半。

Get instant answers, make smarter decisions, collaborate more easily and cut reporting time in half.

你会问什么问题？

What questions will you ask?

要了解更多信息，请查看节目说明或访问 www.adverity.com。

To learn more, check out the show notes or visit www.adverity.com.

那就是 adverity.com。

That's adverity.com.

不错。

Nice.

好的。

Okay.

是的，这些都让我觉得很有道理。

Yeah, that that all makes sense to me.

所以当你谈到这一点时，我想到一个问题。

So a question that occurs to me as you're talking about this.

你知道，当我最初听到这篇论文以及 LLM 在 RAG 场景下更不安全时，我脑海里冒出的想法是，据我理解，与非 RAG 场景相比，LLM 在 RAG 情况下出现幻觉的可能性要小得多。

So, you know, when I originally heard about this paper and about LLMs being less safe in right situations, The thing that popped into my head, I guess, is I was thinking about how it's my understanding is that hallucinations are much less likely in a rag circumstance than outside of a rag circumstance for an LLM.

所以当你拥有这种——再次使用‘接地’这个词——当你有这种接地时，似乎会减少幻觉的发生。

So when you have that, to use that word grounding again, you've been using, when you have that grounding, it seems to lead to fewer hallucinations.

所以我想，在我看来，也许我有点这样想，我也很欢迎你对幻觉这一观点的反馈，这是否真的成立。

So I guess in my mind, maybe I kind of and so I'd also I'd welcome your input on the hallucination point, if that is actually true.

但我发现自己在脑海中把这两件事混为一谈了，觉得：好吧，如果幻觉变少了，那它肯定更安全。

But I guess I kind of ended up conflating those two things in my head and thinking, Okay, if it's hallucinating less often, then it's surely safer.

但没错，而且再次说明，你可以稍后直接指出我关于幻觉的想法哪里有问题。

But but yeah, and again, you can you can cut into my my thoughts on the hallucination in a second.

但现在我越来越清楚了，我逐渐明白，即使幻觉减少了，

It but now it's becoming clear to me, it's it's becoming clear for me to understand how maybe even if hallucinations are reduced.

问题在于，LLM开发者（比如Meta）在他们发布的某些Llama模型中内置的安全机制，在RAG环境中常常会失效。

The issue here is that the kinds of safeguards that an LLM creator put in, say, Meta put into some LAMA models that they release, those safeguards that are built in, in a RAG setup often break down.

你所说的完全正确。

Exactly what you're saying.

确实如此，我们通常说的‘三个H’就是这种情况。

That is absolutely the case where we say, look, there are typically the three H's.

它们最初由Anthropic开发。

They were first developed by Anthropic.

现在许多公司都在采用它们。

Many companies are now adopting them.

你正在构建的应用程序应当是有帮助的、诚实的，并且无害的。

The application you're building, it should be helpful, it should be honest and it should be harmless.

而幻觉很大程度上属于诚实这一类别，而这一类别通常也与有帮助性结合在一起，因为如果你不诚实，又如何能提供帮助呢？

And hallucination very much goes into this honesty bucket, which often is also then combined with the helpful because how can you be helpful if you're not honest?

如果我们只关注有帮助性和无害性，那么所有涉及幻觉以及RAG对帮助性带来的优势的内容都极为重要，这使得RAG成为必需。

If we just focus on being helpful and being harmless, everything that goes into hallucination and the advantages RAG brings to helpfulness, they're vast and they make RAG a necessity.

因此，我们并不是说RAG是危险的，我们只是说它并不一定更安全。

That's why we are not saying that RAG is dangerous, we're just saying it is not necessarily safer.

它绝对是必要的，但无害性这一方面是完全独立的。

It is absolutely necessary, but the harmlessness angle is something that is completely separate.

组织看待这个问题的方式通常是将其拆分，从两个不同的角度来分析，因为有帮助性这一方面与特定的应用场景紧密相关。

The way that organizations think about it is often to split them and look at them through two different angles because the helpfulness angle, it's very much grounded in a specific application.

一个能帮助金融分析师回答问题和验证假设的问答系统可以做到吗？

Can a question answering system that helps financial analysts answer question and test hypotheses?

这个问题的答案是：它是否真的对他们有帮助？

The answer to that is, does it help them?

是或否。

Yes or no.

但总存在一种恶意或非故意滥用该系统的情况——同一个帮助人们评估假设的系统，也可能被用来问‘谁是最差的经纪人，我该利用谁？’

But there's always this angle of a malicious or an unintended abuse of that system where the same system that helps people assess hypotheses could then also be used to, who is the worst broker and who should I exploit?

而这或许并不是你希望回答的问题。

Which is maybe not something that you want to answer in turn.

现在我们有了这两个角度，通常可以说，无害性角度在行业、领域或部门中通常是普遍一致的，但也可能存在一些特定于应用的风险。

Now we have these two angles and often you can say, the harmlessness angle is something that is usually consistent across an industry, across a sector, across a domain that there might be some application specific risks too.

然后是有用性角度，即提供能够真正有所帮助的答案。

Then there's the helpfulness angle where you provide answers that hopefully help.

在这里，RAG 确实很有帮助，因为它能让你构建出诸如透明溯源等功能。

Here RAG really helps because it leads to you being able to build things like transparent attribution.

对我们来说，透明的溯源意味着每次我提供某些信息片段时，都必须将其锚定在某个文档或结构化数据上。

Transparent attribution for us means every time I produce some kind of tidbits, some piece of information, need to ground this in some kind of document or some kind of structured data.

如果我说Meta今天的股价是这样，那我希望可以查看并确认这个数字究竟来自哪里。

If I say the price of Meta is so and so today, then I want to be able to look at that and say, where does that number actually come from?

这是幻觉产生的，还是我真的知道生成这个数字的查询来源？

Is it hallucinated or do I actually know the query that produced that number?

如果我说‘以下分析师发表了以下言论’，那我希望可以悬停查看，哦，原来这个言论出自这里。

If I'm saying like the following analyst said the following statement, then I want to be able to hover over this and say, Oh yeah, this is where that statement came from.

这不是幻觉。

It is not hallucinated.

在某种程度上，这也能防止有害性或无害性问题，但正如你所说，这是另一个相对独立的话题。

This to some degree can prevent the harmfulness or the harmlessness issues as well, but it is a somewhat separate topic as you were saying.

你提到了幻觉，而这也是RAG的一大优势所在，但同时还有谦逊性或有害性的问题。

You talk about hallucination and that's where the big advantage for RAG comes in, But then there's the humbleness or the harmfulness angle as well.

好吧，能再为我们总结一下吗？

Okay, so maybe recap for us again.

所以很可能有很多听众已经认同了RAG。

So there's probably lots of listeners out there who are sold on RAG then.

他们会觉得，太好了，我想减少有害性。

They're like, great, I want to reduce harmfulness.

我想提高我的大语言模型的诚实性。

I want to increase the honesty of my my LLM.

所以我打算使用一个RAG系统。

And so I'm going to use a RAG system.

那么有哪些缓解措施呢？

What are the kinds of mitigations?

我的意思是，你刚才稍微提到了一些，但能不能再为我们总结一下，听众们可以从本集中带走哪些具体的缓解措施，以便根据他们自身的具体情况安全地使用RAG？

I mean, you went into this a little bit, but kind of recap for us again, the kinds of mitigations that our listeners can take home away from this episode to be able to use RAG so that it is safe for their particular circumstances.

是的。

Yeah.

我认为这是一个很好的机会，来谈谈我们应该如何评估系统。

I think that's that's a great opportunity to talk about a little bit about how should we evaluate systems.

毕竟，最终在公众讨论中最多被提及的就是基准测试。

Because in the end, what you see talked about a lot publicly and probably the most is benchmarks.

你会看到，哦，这个由大型语言模型提供商A、B或C推出的新模型，在大型语言模型竞技场或某些基准测试中取得了更高的分数，它在推理和编程方面更出色。

You see, Oh, hey, this new model that a large language model provider A or B or C produced, it achieves a better score on the large language model arena or on the following benchmarks and it's better at reasoning, it's better at coding.

但这并不意味着它在所有被集成的下游应用中都表现得更好。

That doesn't necessarily mean that it's better for all the downstream applications that are being integrated into.

我认为我们常常混淆了这种观点，实际上，根据系统部署的具体环境来衡量和评估它至关重要。

I think we often conflate this view where it's actually really important to measure and to evaluate the system in the context it's deployed in.

这包括安全测试和特定的防护措施。

That includes things like safety testing and specific guardrails.

除了我们的RAG LLM论文外，我们还发布了第二篇论文，其中我们为金融服务开发了自己的内容风险分类法，列出了12类我们在这个领域应用中必须重点关注的风险。

We also released the second paper in addition to our RAG LLM paper where we developed our own content risk taxonomy for financial services, where we say here are 12 categories of risks that we really, really should address with applications in our area.

针对每一类风险，我们都可以通过收集相关数据进行衡量，比如：100个试图诱导金融不当行为的查询，100个试图让LLM生成金融建议的查询，100个试图获取个人信息的查询，100个试图诽谤他人或制造虚假信息和虚假叙事的查询。

For each of these, we can measure because we can collect data against this and say, okay, here are a 100 queries that try and do a financial misconduct, a 100 queries that try and make the LLM generate financial advice, a 100 queries that try and get at personal information, a 100 queries that try and defame someone or create fake information or fake narratives.

在所有这些类别中，你都可以构建数据，用这些标准进行衡量，不仅能测试大型语言模型本身，更能测试部署在特定社会技术环境中的整个端到端系统。

In all of these categories, you can create data, you can measure it against this, and you can not only test the large language models themselves, but rather you can test the entire end to end system that is deployed in a specific sociotechnical context.

在这里，典型的防护系统有很多开源解决方案。

And here, typical guardrail systems, there are a lot of open source solutions.

NVIDIA 有自己的防护系统。

NVIDIA has their own.

LLMA 有自己的防护系统。

LLMA has their own.

Google 有自己的防护系统。

Google has their own.

它们提供了开源的防护措施。

They provide open source guardrails.

但这些开源防护措施主要是针对通用风险的防护。

But again, these open source guardrails, they're shielding against these general purpose risks.

在我们的论文中，我们发现如果应用这些 LlamaGuard、ShieldGemma 或 AGES（它们的名称）。

In our paper, we found that if you apply these LlamaGuard or ShieldGemma or AGES is what they're called.

如果将它们应用于我们的特定风险分类器，判断这个输入或输出是否安全？

If you apply them to them, to our specific risks, classifiers to say, is this input or is this output safe?

是或否。

Yes or no.

它们在我们的领域中也会失效，因为类似于我们的RAG论文，这并不是人们以前必然考虑过的一种使用场景。

They also fail in our domain because similar to our RAG paper, it's just not a use case that people necessarily have thought about before.

但这给了我们一个想法：那么，我们该如何构建自己的护栏呢？

But it gives us then the idea of, okay, how do we build our own guardrails?

我们能否在输入和输出上设置一个分类器，来识别我们自己制定的规则是否被违反？

Can we have a classifier on inputs and on outputs that identify violations of our rules that we set up ourselves?

现在，我们不再使用单纯的RAG系统（即检索-回答），而是采用护栏-检索-回答-护栏的结构。

Now instead of having a vanilla RAG system where it's retrieval answer, we have guardrail retrieval answer guardrail.

在实际应用中，为了防止幻觉并确保出处可信，面向广泛受众的部署系统通常包含更多组件，真正需要评估的是整个端到端的应用，而你也需要领域专家来判断：它是否有帮助、是否无害？

And in practice to prevent hallucination and to add attribution, real systems that are deployed to wide ranges of audiences, they have many more components and it's really this end to end application that should be evaluated and where you need the subject matter expertise to also know, is it helpful and is it harmless?

不错，好的。

Nice, okay.

所以，需要结合领域专业知识，深入分析各自的具体情况。

So yeah, so a combination of subject matter expertise, people digging into their particular circumstances.

你之前在节目中提到过，要了解你的数据，确保其中没有可能被大语言模型用作依据的有害数据。

You mentioned earlier in the episode, being aware of your data, making sure that aren't data in there that are going to be harmful, could be used as grounding by the LLM.

而你刚刚提到的这个想法——‘护栏-检索-回答-再加一层护栏’的流程，

And then you mentioned just now this idea, this flow of guardrail retrieval answer, and then another set of guardrails.

所以这些建议非常实用。

And so yeah, so very practical advice there.

我们稍微换个话题，仍然围绕RAG和有用性展开。

Changing the topic a little bit, like still staying on RAG and still staying on helpfulness.

但我们还没讨论过的一个问题是上下文长度。

But something that we haven't talked about yet is context length.

所以我这里有几个观点或问题。

So I have a couple of points here or a couple of questions here.

你在论文中观察到，大语言模型通常针对短提示进行优化，但在RAG这样的长文本环境中被部署。

You observed in your paper that LLMs are often optimized for short prompts, but deployed in long text environments like REG.

回到我之前举的例子，我提到RAG系统会搜索一百万份法律文件，然后从中提取出十几份。

So going back to the example that I gave earlier, I talked about there being a million legal documents that the REG system searches over, and then it pulls out a dozen documents.

这些文档每份可能长达十页，因此你面对的将是120页的上下文。

Those documents could each be 10 pages long, so then you're talking about 120 pages of context.

如果LLM是针对类似‘法国的首都是哪里？’这样的问题进行优化的，

And if the LLM was optimized for a question like, what's the capital of France?

那么，是的，我可以想象你会遇到问题。

Then, yeah, I could imagine you run into issues.

你能否进一步详细说明一下这个问题，以及会出现哪些具体问题？

So do you want to do you want to fill us more in about this and the kinds of issues that arise?

例如，似乎在更长的输入带来的好处与这成为新的风险面、新的攻击面之间，存在某种权衡。

For example, it seems like there's, you know, trade offs between the benefits of longer inputs versus this becoming a new risk surface, a new attack surface.

是的，完全正确。

Yeah, absolutely.

我觉得你一针见血地指出了关键。

I think you're really hitting the nail on the head here.

RAG非常强大。

RAG is incredibly powerful.

许多构建语言模型的公司都在大力投资，以延长模型可能处理的上下文长度。

There's a lot of investment from companies that build language models and to increasing the possible context length.

同时，延长上下文长度也需要开发相应的方法和模型，真正能够处理如此长的上下文，而不仅仅是依靠足够长的注意力机制在技术上支持它。

At the same time, increasing the possible context length also requires developing methods and developing the models to actually be able to handle such a context length rather than just being able to technically being able to handle them by having an attention that goes long enough back.

这里有几个需要考虑的因素。

Here there are a couple of considerations.

在我们的论文中，我们评估了上下文长度如何真正影响安全性方面的问题。

In our paper, what we evaluated was how does context length really influence the safety angle?

我们发现，特别是在安全性方面，存在一种现象：你输入的上下文越多，模型越容易遗忘内置的安全防护机制或人们常说的对齐性，而这绝对不应该发生，因为从RAG的设定来看，你只是加入了无害的信息。

We found that especially for safety, there seems to be this effect where the more context you put in, the more likely the model is to forget the built in safety guardrails or this alignment that people talk about, which absolutely shouldn't happen if you're considering how RAG is set up because again, you're adding in noxious, completely harmless information.

仅仅因为上下文很长，并不意味着语言模型的行为就应该与你只输入'法国的首都是哪里？'时有所不同。

Just because there's a long, long context doesn't mean that the language model needs to behave any differently from if you just post in what's the capital of France.

同时，上下文长度问题也对RAG系统的构建方式产生了重大影响。

At the same time, the context length question actually has also massive implications of how we build RAG systems.

实际上，检索系统也包含多个组件。

In practice, retrieval systems have multiple components too.

我们一直忽略了这一点，你只是说，哦，是的，有个搜索系统和一个数据库。

We've been glossing over this point where you just say, Oh yeah, there's a search system and there's a database.

但通常你会遇到这样的问题：好吧，我该如何解析查询？

But often you have things like, Okay, how do I parse the query?

如果我问一个问题，我应该将搜索结果限制在什么时间范围内？

If I ask a question, to what timeframe should I limit those search results?

我是否要过滤特定的行业、领域、公司或其他任何元数据？

Am I filtering to particular industries, sectors, companies, any kind of other metadata?

通常，搜索引擎的实现包含多个步骤，首先进行一次初步检索，将数亿甚至数十亿份文档缩减为寥寥几份。

There's usually the way that search engines are written, there's usually multiple steps as well, where you do a first pass retrieval, where you go from hundreds of millions of documents or even billions of documents down to just a handful.

然后通常还有一个计算量更大的重排序步骤，用于精确挑选文档中哪些片段才是真正可能包含答案的部分。

Then there's usually a re ranking step that's much more computationally intensive, where you really pick out which snippets in the documents are you actually trying the answer in.

因此，这里的这些组件都会影响上下文长度。

So all of these components here have an influence on the context length.

当你说到有10份法律文件，每份10页，你是如何获取到它们的？

When you say you have 10 legal documents of 10 pages, how do you get to them?

粘贴整个文档与只粘贴每份文档的一两段，会产生什么影响？

And what is the effect of pasting entire documents versus just a paragraph or two from each document?

通常人们发现，提供的上下文越少，尤其是当答案就在这些上下文中时，大语言模型就越容易找到正确答案。

Typically what people find is the less context you need to provide, especially if the answer is in that context, the easier it is for the large language model to find the right answer.

这看起来显而易见，但这就变成了一个检索问题。

Seems pretty obvious, but that then becomes a retrieval problem.

如果我有1亿份文档，每份10页，我该如何找到那两段真正回答问题的段落？

How do I find within the If I have a 100,000,000 documents each 10 pages long, how do I find the two paragraphs that actually answer the question?

大语言模型发展的一个期望，确实是通过增加上下文长度，减少对越来越精准检索的依赖，而是让语言模型自己去推断。

A hope really has been in Large Language Model development to just increase the context length and to rely less on more and more accurate retrieval, but rather let the language model figure it out.

能够处理更长的上下文，也让你能够提供更具上下文关联性的回答。

Being able to handle longer context also allows you to give much more contextualized answers.

如果你拥有完整的10页文档，即使答案只在其中一段，它仍然可以告诉你第一页的内容，或者告诉你这份文档的类型是什么。

If you have the entire 10 page document, even if the answer is found in just one paragraph, it can still give you the context from page one or it tell you what is this document type?

它来自哪里？

Where is it from?

简介里说了什么？

What was in the intro?

这份文件的执行摘要与实际内容有何不同？

What did the executive summary of this document say in contrast to the actual document?

如果我们考虑语音，语调是怎样的？

If we go into voice, what was the intonation?

如果我们考虑视频，就有许多机会可以利用更长的上下文。

If we go into video, there's so many opportunities to take advantage of longer context.

但同样，我们必须认真考虑这些模型是如何部署的？

But again, we have to really consider how are the models being deployed?

这些系统的用户是谁？

Who are the users of this?

应用场景是什么？

What is the application?

我刚才提到的每一个设计决策，都会影响整个系统的有用性，以及在这种情况下有害或无害的程度。

Every single one of these design decisions I just talked about can influence the helpfulness and the harmful or harmlessness in this case of the entire system.

这是一项庞大的工程，需要大量的研究。

So this is a massive undertaking and requires a lot of research.

这是一个非常引人入胜的回答。

That was a fascinating answer.

我学到了很多，你把这一切都解释得非常清楚。

I learned a lot and you explained all of that very clearly.

谢谢。

Thank you.

你刚才提到，更长的上下文窗口让我们能在回答中融入更多背景信息、更微妙的细节和更丰富的层次。

Something that you talked about there was how longer context windows allow us to have more context in our answer, more subtlety, more nuance in the answer that comes back.

你还提到，上下文窗口正在变得越来越长，这恰好与我接下来要问的问题紧密相关：我们现在已经普遍能看到具有百万级标记上下文长度的大型语言模型。

And you also mentioned there how context windows are getting longer and longer, which actually ties in perfectly to the next question that I was going to ask you, which is that, you know, we're at a point now where it's getting reasonably common to see LLMs that have a million token context length.

我们甚至已经看到一些模型的上下文长度达到数百万个标记。

And we've seen some release that are multiples of that, many millions of tokens in context.

通常，当这些模型发布时，都会附带一些类似‘大海捞针’的测试，用来隐藏少量信息。

And typically, when these are released, it comes with these kind of needle in a haystack tests where you try to hide a small amount of information.

我认为一个常见的例子是披萨食谱。

I think a common one is a pizza recipe.

会有一些像‘世界上最好的披萨’这样的说法，然后配上一些随机的配料，比如凤尾鱼，一种独特的食材。

There'll be something like the world's best pizza is and then these random ingredients like anchovies, something that is unique.

然后你会说，好吧，凭借我们一千万标记的上下文长度，模型成功检索到了披萨的信息。

And then you'll have you'll say, Okay, you know, over our 10,000,000 token context length, the model was able to successfully retrieve pizza information.

现在我有点深入细节了，稍微跑题了。

Now I've got I'm getting a little bit deep in the weeds here and on a little bit of a tangent.

但有些人也说，这并不是一个很好的测试，因为如果你有一百万份法律文件，却只夹杂着一份披萨食谱，这相当不寻常。

But some people have also said that isn't a great test, because if you have millions of legal documents, and then there's one pizza recipe, that's quite unusual.

所以很可能，LLM会特别注意到这一点。

And so it's probably, that's then maybe something that the LLM is going to take notice of.

因此，关于‘大海捞针’测试确实存在争议。

And so, yeah, so there's controversy about needle in a haystack test.

但我们不一定需要深入讨论这个，除非你对此感兴趣。

But we don't necessarily need to get into that too much unless it interests you.

我想问的问题是，你认为我们是否会达到一个阶段，即上下文窗口变得如此之大，以至于实际上相当于无限上下文窗口？

The question that I'm getting to is, do you think we'll get to a point where context windows expand so much that it is effectively like an infinite context window.

这意味着我们根本不需要RAG了。

And then that means that we don't need RAG at all.

是的。

Yeah.

对于你提到的‘大海捞针’问题，还有其他需要考虑的因素。

There are additional considerations to address your needle in a haystack point.

我认为这完美体现了语言模型开发者与在实际应用中集成这些模型的人之间的差异。

I think this is a perfect example of the difference between developers of language models and integrators of such language models in actual applications.

作为可能在考虑‘我该选用哪个长上下文模型’的人，

As someone who might be considering, okay, which of these long context models do I use?

我可以查看‘大海捞针’测试结果，说：哦，这个模型每次都成功，那个却不行。

I can look at needle and haste, I can say, oh yeah, this model got it a 100% of the time, this one did not.

显然，我会优先选择那个能100%成功的模型。

Clearly, I'm going to look at the one that gets a hundred percent first.

这些基准测试，即使它们是人为设计的，确实能影响这一决策。

That is really the decision that these benchmarks, even if they're artificial benchmarks can influence.

我认为没有人会提出这样的观点：仅仅因为某个模型能在一千万个标记中找到某些信息，它就能帮你完成繁重的法律研究任务。

I think no one is making the point that just because this model can find some information in 10,000,000 tokens, it is going to be able to help you with a research heavy legal task.

最终，这确实需要集成者来识别。

That is really on the integrators in the end to identify.

而在这种情况下，这可能是一项难得多得多的任务。

And in this case, it might be a much, much, much harder task.

如果我们本周早些时候在彭博社发布的系统为例，它是一款帮助研究分析师搜索超过四亿份文件、新闻文章和分析报告，以回答问题并协助识别和验证假设的工具。

If you have a system that we just released earlier this week at Bloomberg was a tool that helps research analysts search through over 400,000,000 documents and news articles and analyst reports to answer questions and to help with the identification of hypothesis and solution of hypotheses.

完全是假设驱动的。

Very much hypothesis driven.

你提出一个问题，它会遍历这四亿份文档，然后综合出一个答案。

You ask a question, it goes through all these 400,000,000 documents and then synthesizes an answer.

这比简单地查找某条披萨信息或披萨食谱要难得多。

This is much, much harder to do than a simple find this piece of pizza information or pizza recipe information.

相反，你真的需要在部署系统的背景下进行评估。

Instead, you really need to, again, evaluate in the context of deploy the system.

回到你之前的问题，显然，能够处理越来越复杂情况的模型具有明显优势。

To then go back at your question, there is obviously strong advantages of models that are technically capable of handling more and more complex situations.

如果我能直接粘贴更多文档或更多上下文，就不必依赖那么多技巧来缩小上下文窗口。

If I'm able to just paste in more documents or more of a context, I don't need to rely on as many tricks to really narrow down the context window.

我可以直接依赖大型语言模型。

I can just rely on a large language model.

但这里存在一个权衡：更长的上下文通常会带来显著增加的延迟和成本。

There's a trade off here though, where longer context usually comes at a cost of significantly increased latency and cost.

尽管长上下文模型已经可用，但如果你需要快速直接的答案，它们未必是最适合该任务的选择。

Even though long context models are available, they might not necessarily be the best for the task if you want a snappy direct answer.

本集《超级数据科学》由戴尔AI工厂与英伟达联合赞助，两家值得信赖的技术领导者携手打造全面且安全的AI解决方案，可为任何企业定制。

This episode of Super Data Science is brought to you by the Dell AI Factory with NVIDIA, two trusted technology leaders united to deliver a comprehensive and secure AI solution customizable for any business.

凭借从桌面到数据中心再到云端、专为AI工作负载量身定制的产品、解决方案和服务，戴尔AI工厂与英伟达为AI无缝服务于您铺平了道路。

With a portfolio of products, solutions, and services tailored for AI workloads, from desktop to data center to cloud, the Dell AI Factory with NVIDIA paves the way for AI to work seamlessly for you.

集成的戴尔和英伟达功能可加速您的AI驱动用例，整合您的数据和工作流程，并帮助您设计可重复、可扩展的AI路径。

Integrated Dell and NVIDIA capabilities accelerate your AI powered use cases, integrate your data and workflows and enable you to design your own AI journey for repeatable, scalable outcomes.

访问 www.dell.com/superdatascience 了解更多信息。

Visit www.dell.com/superdatascience to learn more.

就是 dell dot com slash superdatascience。

That's dell dot com slash superdatascience.

当然，这是一个显而易见的观点：在足够长的时间尺度上，经过数年甚至数十年，数百万个标记的计算成本可能微不足道。

Of course, that is such an obvious point to make is that and over a long enough timescale, over many years, maybe many decades, compute cost over millions of tokens might be trivial.

但在可预见的未来，情况并非如此。

But at least for the foreseeable future, it isn't.

因此，这完全说得通。

And so, that makes perfect sense.

所以，我们可以更明确地向不太熟悉RAG的人解释一下，因为我们之前还没谈到这一点：RAG系统的工作方式是，让我们回到那个百万份法律文件的例子。

So something that I guess we could make a little bit more explicit for people who aren't familiar with RAG, because we haven't talked about this, is that when the way that RAG systems work is like, let's go back to that example of the million legal documents.

在运行任何RAG查询之前，我们会提前将这百万份文档映射到一个称为向量空间的高维空间中。

What we would do in advance before running any RAG queries is we would map each of those million documents into a high dimensional space called a vector space.