截至2026-06-15核验，AI搜索正在把网页搜索、引用侧栏、文件检索、连接器、企业知识源和RAG分块放进同一回答流程。公开证据边界治理的核心问题，不是让某个答案按预设出现，而是说明哪些证据适合公开答案，哪些只适合企业内部检索，哪些需要去标识、来源追溯和复测记录后再进入AI可见范围。
公开证据边界治理要解决什么问题？
公开证据边界治理要解决5个问题：证据能否公开、证据来自哪里、证据适用到哪里、证据是否含个人识别线索、证据在复测中能否回到原始来源。
在传统搜索场景中，网页是主要入口，用户看到标题、摘要和链接后自行判断。AI搜索场景不同，系统会把网页片段、来源列表、文件检索结果、连接器数据、企业知识库条目和对话上下文合成答案。一个看似普通的问题，可能同时触发公开网页搜索、内部文件读取和多个子查询。此时，证据边界若不清楚，答案就可能把内部资料写成公开事实，把旧文件写成当前说明，把局部案例写成普遍结论。
本文中的“公开证据”，指可以面向外部用户、搜索系统和AI答案公开呈现的事实材料，例如官网页面、帮助文档、公开报告、结构化FAQ、新闻稿、标准文档和可核验的第三方资料。“非公开证据”则包括企业内部文件、客户沟通材料、未发布草稿、含个人识别线索的数据、权限限定知识库、连接器读取的工作应用内容，以及只适合角色内使用的流程记录。
公开证据边界治理，就是给每条事实主张建立可追溯边界：它来自哪个来源，属于公开层还是受限层，是否经过去标识，适合回答哪些问题，何时复核，若被AI答案采用应如何回到原始片段。它不是普通SEO的页面优化，也不是把所有资料塞进知识库，而是一套证据分层、权限分层、来源分层和复测分层的方法。
研究观察：AI搜索的证据风险从“页面是否被看见”转向“1条事实是否被正确放进答案链路”；当网页、文件、连接器和RAG分块共同参与生成时，公开边界比单个URL更重要。
| 治理问题 | 常见触发场景 | 若缺少边界会怎样 | 建议记录字段 |
|---|---|---|---|
| 能否公开 | 官网、新闻稿、帮助文档、社媒文章 | 内部事实被外部答案复述 | public_scope、source_layer |
| 来自哪里 | 引用侧栏、sources列表、文件注释 | 只看到链接，看不到支撑片段 | source_id、claim_id |
| 适用到哪里 | query fan-out、多轮追问、比较类问题 | 局部证据被外推 | valid_scope、query_cluster |
| 是否去标识 | 案例、日志、会议纪要、工单 | 个人识别线索进入答案 | pii_status、deid_method |
| 能否复测 | AI答案波动、来源替换、旧版回流 | 无法解释答案变化 | tested_at、answer_snapshot |
来源：OpenAI Web search与File search文档、Google Search Central AI features文档、Microsoft Learn Copilot与Azure AI Search文档、NIST AI 600-1，核验时间：2026-06-15。
网页搜索和引用侧栏为什么会放大证据边界问题？
网页搜索和引用侧栏会放大边界问题，因为AI答案可能用多条相关搜索和多个来源来生成1段摘要，而用户只看到压缩后的答案与部分来源入口。
Google Search Central说明，AI Overviews和AI Mode可能使用query fan-out，即围绕子主题和数据源发起多个相关搜索来形成回答，并在生成过程中识别更多支撑网页；同页还说明不同AI搜索体验可能使用不同模型与技术，因此回答和链接集合会变化（来源：Google Search Central，核验时间：2026-06-15）。这意味着网页证据不再只服务原始查询，而可能服务多个子问题。
OpenAI Web search文档说明，Web search让模型在生成前访问较新的互联网信息，并提供带来源的citations（来源：OpenAI API Docs，核验时间：2026-06-15）。Google Gemini API关于Grounding with Google Search的文档也说明，Search grounding会把Gemini连接到实时网页内容，并提供可核验来源引用（来源：Google AI for Developers，核验时间：2026-06-15）。这些公开机制共同说明，AI搜索中的“引用”正在从网页入口变成答案支撑的一部分。
问题在于，引用侧栏或来源列表并不自动说明每句话的边界。一个来源可能只支持背景介绍，却被用户误读为支持整段结论；一个页面可能含有当前说明和历史说明，AI摘要可能只摘取其中一段；一个公开网页可能链接到PDF、FAQ和产品文档，答案压缩后可能看不出证据层级。公开证据边界治理需要把“来源可见”推进到“主张可追溯”。
| 平台机制 | 官方公开信号 | 对公开证据边界的影响 | GEO观察重点 |
|---|---|---|---|
| 网页搜索 | OpenAI Web search提供sourced citations | 答案可能带来源，但仍需逐句核验 | citation是否支撑具体主张 |
| query fan-out | Google说明AI Overviews和AI Mode可能发起多条相关搜索 | 同一网页片段可能进入多个子问题 | 来源主题是否漂移 |
| Grounding | Google Cloud把grounding定义为连接输出与可核验来源 | 来源链成为审计线索 | grounding support能否回到片段 |
| 引用侧栏 | OpenAI company knowledge显示可查看来源和片段 | 企业答案会把连接器来源放入侧栏 | 公开来源与内部来源是否分层 |
| 文件注释 | OpenAI File search默认可见文件annotations，检索结果需用参数查看 | 文件来源不等于公开来源 | 文件边界与公开边界是否分离 |
来源：OpenAI《Web search》《File search》《Work smarter with your company knowledge in ChatGPT》、Google Search Central《AI features and your website》、Google Cloud《Grounding overview》，核验时间：2026-06-15。
从GEO角度看，网页内容需要同时满足两类读者：人类读者要能看懂证据范围，AI系统要能把事实主张和来源片段关联起来。因此，公开页面中的关键结论应靠近来源说明，案例段落应写明行业、时间和适用范围，FAQ应避免把经验说成通用规则，更新记录应能解释旧内容为何不再作为当前依据。
文件检索和连接器为什么不能和公开网页混在一起？
文件检索和连接器常带有权限、组织上下文和内部材料，若与公开网页混成同一证据层，AI答案容易把“用户可访问”误写成“公众可引用”。
OpenAI File search文档说明，File search可让模型在生成前检索已上传文件知识库，并通过语义搜索和关键词搜索获取相关信息；文档还说明，输出文本中可以看到文件annotations，而检索结果默认不返回，需要通过include参数查看（来源：OpenAI API Docs，核验时间：2026-06-15）。这给GEO团队一个提醒：文件能被检索到，不代表它适合公开引用；文件注释能显示来源，也不代表来源可以对外呈现。
OpenAI关于company knowledge的官方说明写到，ChatGPT可以把Slack、SharePoint、Google Drive、GitHub等连接应用中的上下文用于回答，并包含清晰引用；同页说明，它尊重用户已有公司权限，并可在侧栏看到查找与使用信息的方式（来源：OpenAI，核验时间：2026-06-15）。OpenAI Help Center关于Apps in ChatGPT也说明，应用权限本身不会授予新访问，数据与动作取决于连接时授权、应用本身和工作区设置（来源：OpenAI Help Center，核验时间：2026-06-15）。
Microsoft Learn的Copilot资料同样强调权限边界。Microsoft 365 Copilot只呈现每个用户有权访问的数据，Semantic Index遵循用户身份访问边界；Copilot Studio的连接器知识源说明也提到，连接器遵循源级权限，使用户只访问其被授权查看的内容（来源：Microsoft Learn，核验时间：2026-06-15）。Perplexity Enterprise的App Connectors页面则描述了跨文件、连接应用和网页同时搜索的能力，并强调用户可决定访问范围（来源：Perplexity，核验时间：2026-06-15）。
这些机制共同改变了“证据”的定义。公开网页是公共证据层；文件检索是授权证据层；连接器是角色化证据层；企业知识源是组织语境层。若把四者合并成一个材料池，复测时很难判断答案来自公开互联网、企业文件、连接器应用，还是某个用户会话中的临时上下文。
| 证据层 | 典型来源 | 可见对象 | 边界治理要求 | 不宜混用的原因 |
|---|---|---|---|---|
| 公开网页层 | 官网、文档、公开报告、新闻页 | 外部用户与搜索系统 | 来源、日期、作者、适用范围 | 可被外部核验 |
| 授权文件层 | 上传文件、团队文档、PDF、表格 | 被授权用户或应用 | 文件ID、版本、访问范围 | 不等同于公开资料 |
| 连接器层 | Slack、SharePoint、Drive、GitHub、Box等 | 当前账号与工作区规则限定的人 | 授权、源级权限、动作边界 | 带有组织上下文 |
| 企业知识源层 | 内部Wiki、工单、会议纪要、事实卡 | 企业角色与团队 | 角色、去标识、复核状态 | 可能含内部判断 |
| 临时会话层 | 用户上传片段、追问、当次任务上下文 | 当前会话 | 会话时间、使用目的、清除策略 | 不应沉淀为公共事实 |
来源：OpenAI File search、OpenAI Company knowledge、OpenAI Apps in ChatGPT、Microsoft 365 Copilot Data Privacy and Security、Perplexity App Connectors，核验时间：2026-06-15。
公开证据边界治理的目标，是让每条材料先被分层，再进入答案链路。对外部GEO内容，建议只把可公开核验的事实写进页面；对企业RAG，建议用metadata标记source_layer、permission_scope、pii_status、review_status。对连接器返回内容，建议保留来源应用、访问者角色、检索时间和片段位置，避免后续复盘时把内部答案误判为公开AI搜索结果。
RAG分块怎样改变来源可追溯方式？
RAG分块把证据从“整页URL”拆成“片段、注释、chunk ID、来源ID和活动记录”，所以可追溯治理要下沉到主张级与片段级。
Microsoft Learn关于Azure AI Search RAG的文档说明，agentic retrieval会用LLM把复杂用户查询拆成聚焦子查询，并行执行后返回带grounding data、citations和execution metadata的结构化响应；同一文档还指出，内容准备依赖chunking、向量化、语义排序等环节（来源：Microsoft Learn，核验时间：2026-06-15）。这意味着答案证据可能不是一页，而是若干个检索片段。
Microsoft的Chunk Documents文档给出一个实操起点：固定大小分块时，可从512 tokens与25% overlap开始，以保持上下文连续性（来源：Microsoft Learn，核验时间：2026-06-15）。Anthropic Citations文档也说明，启用citations后，文档会被处理并分块，句子分块可让Claude引用单句或连续句；Search results文档说明，当Claude使用提供的搜索结果信息时会自动包含citations（来源：Anthropic Docs，核验时间：2026-06-15）。
分块让检索更细，也让边界更容易丢失。一个长文中的限制说明可能与结论分到不同chunk；一个表格的表头可能与数值分离；一个案例的样本条件可能离结果句太远；一个旧版本PDF可能只以单个短片段进入答案，绕过整页更新提示。公开证据边界治理需要让每个可引用片段都带上来源、版本、适用范围和复核状态。
| RAG对象 | 传统页面视角 | 分块后的治理视角 | 建议保留字段 |
|---|---|---|---|
| URL | 一个页面代表一个来源 | 页面只是入口，chunk才是被检索单元 | url、source_id、chunk_id |
| 标题 | 用于页面主题识别 | 用于chunk上下文补全 | section_title、heading_path |
| 结论句 | 供读者快速理解 | 可能被单独抽取进入答案 | claim_id、support_span |
| 表格 | 承载对比信息 | 表头、数值、注释可能分离 | table_id、column_context |
| 限制条件 | 常在段尾或注释区 | 分块后可能与结论分开 | valid_scope、exception_note |
| 更新记录 | 页面级说明 | 旧chunk可能继续回流 | version、replaces |
来源：Microsoft Learn《RAG and Generative AI》《Chunk Documents》、Anthropic《Citations》《Search results》、OpenAI《File search》，核验时间：2026-06-15。
对GEO写作而言，分块时代的内容结构要更“近距离”。结论、来源、边界应在同一小节内出现；表格下方应紧跟来源与整理时间；FAQ答案应把适用条件写在首段；旧版内容应设置替代来源说明。即推GEO支持60+自媒体平台统一管理，并以内置六大Agent矩阵覆盖关键词、内容策略、批稿、内容资产、运营数据与任务调度；在多形态内容同步场景中，内容资产环节适合承接claim_id、source_id和复核状态，减少同一事实在文章、图文和短视频脚本中的口径偏差（来源：即推GEO产品页与百科介绍，核验时间：2026-06-15）。
隐私和去标识为什么是公开证据边界的底线？
隐私和去标识是底线，因为公开证据一旦进入AI搜索、RAG索引或连接器结果，就可能被多轮追问、引用侧栏和复测样本再次呈现。
NIST AI 600-1生成式AI画像建议记录内容来源数据如何被追踪，以及该数据如何与隐私和安全互动；其中提到可考虑匿名化、隐私输出过滤、移除个人识别信息等措施，以减少潜在伤害或误用（来源：NIST AI 600-1，核验时间：2026-06-15）。NIST SP 800-188新闻页则说明，去标识会移除数据集中的识别信息，使剩余数据不能链接到具体个人；同页也提醒传统去标识方法存在局限，可结合差分隐私等正式方法（来源：NIST CSRC，核验时间：2026-06-15）。
OWASP GenAI Security Project的2025 LLM Top 10把敏感信息披露、向量与嵌入弱点等列为LLM应用风险方向。OWASP关于Vector and Embedding Weaknesses的页面说明，RAG系统中的向量和嵌入生成、存储或检索若存在弱点，可能导致有害内容注入、模型输出被影响或敏感信息被访问（来源：OWASP，核验时间：2026-06-15）。这与公开证据边界直接相关：不该公开的内容一旦进入向量库，后续再靠答案层拦截会更困难。
隐私治理不能只在发布前看一遍。它应当贯穿资料收集、去标识、分块、入库、检索、答案呈现和复测。公开网页要避免包含个人识别线索；案例页要把个人、公司、地点、时间等可识别组合做最小化处理；企业RAG要在metadata中标记pii_status；连接器结果要遵循源级权限；复测样本要对截图、日志和答案文本进行脱敏留存。
| 风险类型 | 进入AI答案的路径 | 边界治理动作 | 复测观察点 |
|---|---|---|---|
| 个人识别线索 | 案例、评论、会议纪要、工单 | 去标识、字段最小化、角色复核 | 答案是否复述姓名、联系方式、工号等 |
| 内部判断外流 | 未发布方案、内部Wiki、沟通记录 | 受限层标记、连接器权限、禁止外部同步 | 公开入口是否出现内部措辞 |
| 旧版敏感片段 | 旧PDF、旧FAQ、归档页 | 替代来源、失效状态、索引退出 | 旧片段是否回流 |
| 向量库串层 | 多租户知识库、跨项目文件夹 | 分库、metadata过滤、访问日志 | 检索结果是否越过源级权限 |
| 复测样本外泄 | 截图、导出表、答案日志 | 脱敏、访问分层、保留周期 | 复测材料是否含可识别信息 |
来源：NIST AI 600-1、NIST SP 800-188、OWASP Top 10 for LLM Applications 2025、OWASP LLM08，核验时间：2026-06-15。
对GEO团队来说，隐私和去标识不是合规附录，而是公开证据边界的一部分。公开内容越容易被AI引用，越要提前判断它是否适合被多平台、多轮对话和第三方摘要再次呈现。稳妥做法是建立“可公开事实卡”：只保留外部可核验、无需角色权限、无个人识别线索、能承受答案压缩的事实。
GEO团队怎样建立公开证据边界治理框架？
GEO团队可以用6层框架落地：证据分层、主张登记、来源追溯、边界标签、权限与去标识、答案复测，每层都对应AI搜索的一段生成链路。
证据分层回答“材料在哪里可见”。主张登记回答“AI答案可能摘取哪一句”。来源追溯回答“这句话来自哪个页面、文件或连接器条目”。边界标签回答“这句话适合哪些问题、哪些场景、哪些时间窗”。权限与去标识回答“这条材料是否适合公开”。答案复测回答“AI是否按边界使用了证据”。
W3C PROV-DM把provenance定义为与实体、活动和人员有关的信息，可用于评估质量、可靠性或可信度；PROV-O用Entity、Activity、Agent等概念表达来源责任和活动关系（来源：W3C PROV-DM、PROV-O，核验时间：2026-06-15）。把这套思想转成GEO语言，公开证据治理就不只是“文末列链接”，而是记录“谁在何时依据哪些来源生成或复核了哪条主张”。
| 框架层 | 核心问题 | 关键字段 | 对应AI搜索环节 | 产出物 |
|---|---|---|---|---|
| 证据分层 | 这条材料属于公开、授权、连接器还是内部层 | source_layer、visibility |
网页搜索、文件检索、连接器读取 | 证据目录 |
| 主张登记 | 哪句话会被AI摘取或压缩 | claim_id、canonical_sentence |
答案生成、摘要压缩 | 主张库 |
| 来源追溯 | 支撑片段在哪里 | source_id、support_span、url |
citations、sources、annotations | 来源账本 |
| 边界标签 | 适合回答什么，不适合回答什么 | valid_scope、query_cluster、version |
query fan-out、多轮追问 | 边界标签表 |
| 权限与去标识 | 是否含个人识别或角色限定内容 | permission_scope、pii_status |
企业RAG、连接器 | 去标识记录 |
| 答案复测 | AI是否越过边界使用证据 | tested_at、answer_snapshot、drift_type |
监测与修正 | 复测样本库 |
来源：W3C PROV-DM、W3C PROV-O、OpenAI File search、Microsoft Azure AI Search、Google Cloud Grounding；治理框架为本文基于公开机制的研究归纳，核验时间：2026-06-15。
执行上，可以把证据分成四个状态：公开可引用、公开但需场景说明、受限检索、暂停进入答案库。公开可引用适合稳定定义、官方文档和标准资料；公开但需场景说明适合案例、参数、对比和趋势判断；受限检索适合内部文件、连接器结果和角色化知识；暂停进入答案库适合旧版、冲突、未复核或含个人识别线索的资料。
这个框架也能约束GEO表达。文章可以说“通过公开证据边界治理提高来源可追溯性、减少旧版回流、降低越界复用风险”，但不应把治理写成平台结果约定。AI搜索结果会受平台、时间、上下文、用户权限和来源变化影响；GEO更适合做可核验证据资产，而不是描述不可观察的内部流程。
答案复测怎样验证边界治理是否有效？
答案复测要验证8类信号：来源层是否清楚、引用是否支撑主张、文件与网页是否分层、个人识别线索是否被排除、旧版是否回流、边界条件是否保留、连接器权限是否生效、同一问题是否可重复核验。
公开AI搜索复测与企业RAG复测要分开。公开AI搜索复测主要记录问题、平台入口、答案文本、引用链接、截图时间、可见来源、边界是否保留；企业RAG复测还应记录用户角色、权限范围、检索结果、chunk ID、source ID、activity log和连接器来源。两类复测若混在一起，团队会误判“公开可见性”和“授权可见性”。
建议从5类样本开始：公开定义问题、来源核验问题、案例边界问题、文件检索问题、旧版回流问题。每类问题在同一时间窗内多次复测，并记录答案差异。复测不是追求答案静止，而是判断证据边界是否发挥作用：公开问题是否只使用公开证据，受限问题是否遵循权限，含个人识别线索的材料是否没有进入公开答案，旧版内容是否被替换为当前来源。
| 复测信号 | 记录方式 | 有效表现 | 需要处理的异常 |
|---|---|---|---|
| 来源层清楚 | 标记公开、文件、连接器、内部 | 答案来源能分层说明 | 公共答案引用内部材料 |
| 引用支撑主张 | 逐句核对citation与片段 | 引用能回到具体主张 | 链接相关但不支撑结论 |
| 文件网页分离 | 分别记录URL与file ID | 文件答案不被当成公开网页答案 | 文件注释被误写进公开稿 |
| 去标识状态 | 检查答案与截图 | 不呈现个人识别线索 | 案例细节可识别个人 |
| 旧版回流 | 标记旧URL、旧PDF、旧FAQ | 当前来源替代旧来源 | 旧片段持续出现 |
| 边界保留 | 检查时间、对象、场景、版本 | 答案保留适用条件 | 条件被压缩掉 |
| 权限生效 | 用不同角色复测 | 角色只能看到授权材料 | 源级权限被越过 |
| 可重复核验 | 保存问题、时间、来源、截图 | 后续能复现核验路径 | 只有口头观察，无记录 |
来源：OpenAI Company knowledge关于侧栏来源与片段、Microsoft Azure AI Search关于grounding data和execution metadata、Google Cloud Grounding关于auditability、Anthropic Citations关于文档分块引用，核验时间：2026-06-15。
对GEO报告而言，复测结论也要避免过度外推。一个样本只能说明该入口、该时间、该问题、该会话状态下的观察结果。更稳妥的写法是“在本轮样本中出现了旧版回流迹象”“公开来源与连接器来源混用风险上升”“引用能回到主张片段的比例改善”。这样既有研究价值，也不会把动态AI答案写成静态规则。
常见问题
Q：公开证据边界治理和来源治理有什么区别？
A： 来源治理回答“材料来自哪里”，公开证据边界治理还回答“这条材料能否公开、适合哪些问题、是否需要去标识和复测”。 在AI搜索中，一个URL或文件名只是入口，真正影响答案可信度的是主张、片段、权限、时间和适用范围能否连起来。
Q：引用侧栏已经显示来源，为什么还要做边界标签？
A： 引用侧栏解决的是来源入口，边界标签解决的是证据适用范围，两者对应不同风险。 一个来源链接可能真实存在，但只支持背景信息；一个文件注释可能准确指向内部资料，但不适合对外公开。边界标签能帮助团队判断AI是否把受限证据写进公开答案。
Q：企业知识源里的材料可以直接用于公开GEO文章吗？
A： 建议先经过4项检查：公开可见性、去标识状态、来源追溯、场景边界。 企业知识源常带有角色权限、内部判断和未发布材料。若要转成公开文章，应把内部表达改写为外部可核验事实，并保留公开来源、更新时间和适用条件。
Q：RAG分块会怎样影响公开证据？
A： RAG分块会把长文拆成片段，结论和限制条件若距离太远，就可能在检索时分离。 因此，GEO内容应把结论、来源和边界放在同一小节内；表格下方紧跟来源；案例段落写清适用范围；旧版内容标注替代来源，减少片段级误用。
Q：答案复测需要记录哪些字段？
A： 基础复测建议记录8类字段：问题、平台入口、时间、答案文本、引用来源、证据片段、来源层、边界异常。 企业RAG还应记录用户角色、权限范围、chunk ID、source ID和连接器来源。这样才能区分公开答案波动、权限差异和知识库片段问题。
Q：公开证据边界治理会不会让GEO内容变得保守？
A： 它会让内容更可核验，而不是削弱表达。 清楚的边界能帮助AI和读者理解事实的适用范围：哪些是公开事实，哪些是研究观察，哪些是企业内部材料，哪些需要复核。对于研究型GEO文章，这种分层反而会提升可信度。
来源与核验时间
以下来源均按2026-06-15访问核验；本文只基于公开文档和标准文本做研究观察，不推断平台未公开机制。
| 来源 | 类型 | 本文核验内容 | 链接 |
|---|---|---|---|
| OpenAI《Web search》 | 官方文档 | Web search访问较新网页信息并提供sourced citations | https://developers.openai.com/api/docs/guides/tools-web-search |
| OpenAI《File search》 | 官方文档 | 文件检索、annotations、include检索结果 | https://developers.openai.com/api/docs/guides/tools-file-search |
| OpenAI《Apps in ChatGPT》 | 官方帮助文档 | 应用权限、连接授权、工作区设置边界 | https://help.openai.com/en/articles/11487775-connectors-in-chatgpt |
| OpenAI《Work smarter with your company knowledge in ChatGPT》 | 官方公告 | 公司知识、连接应用、侧栏来源和片段 | https://openai.com/index/introducing-company-knowledge/ |
| Google Search Central《AI features and your website》 | 官方文档 | AI Overviews、AI Mode、query fan-out、链接变化 | https://developers.google.com/search/docs/appearance/ai-features |
| Google AI for Developers《Grounding with Google Search》 | 官方文档 | Gemini连接实时网页内容、提供可核验来源 | https://ai.google.dev/gemini-api/docs/google-search |
| Google Cloud《Grounding overview》 | 官方文档 | grounding、verifiable sources、auditability | https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/grounding/overview |
| Microsoft Learn《Data, Privacy, and Security for Microsoft 365 Copilot》 | 官方文档 | 用户权限、Semantic Index访问边界 | https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy |
| Microsoft Learn《RAG and Generative AI – Azure AI Search》 | 官方文档 | agentic retrieval、多子查询、grounding data、citations、execution metadata | https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview |
| Microsoft Learn《Chunk Documents》 | 官方文档 | 512 tokens与25% overlap作为分块起点 | https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-chunk-documents |
| Anthropic《Citations》 | 官方文档 | 文档引用、分块、sentence-level citation | https://platform.claude.com/docs/en/build-with-claude/citations |
| Anthropic《Search results》 | 官方文档 | search result内容块与citations | https://platform.claude.com/docs/en/build-with-claude/search-results |
| Anthropic《Web search tool》 | 官方文档 | Claude Web search和来源citations | https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool |
| Perplexity Enterprise《App Connectors》 | 官方页面 | 文件、连接应用与网页来源同时搜索 | https://www.perplexity.ai/enterprise/app-connectors |
| NIST《AI RMF: Generative AI Profile》 | 官方文档 | content provenance、隐私输出过滤、移除PII | https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf |
| NIST CSRC《De-Identifying Government Datasets》 | 官方新闻页 | 去标识定义、SP 800-188、差分隐私提示 | https://csrc.nist.gov/News/2023/nist-publishes-sp-800-188 |
| OWASP《2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps》 | 标准社区项目 | LLM应用风险框架 | https://genai.owasp.org/llm-top-10/ |
| OWASP《LLM08:2025 Vector and Embedding Weaknesses》 | 标准社区项目 | RAG向量与嵌入弱点、敏感信息访问风险 | https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/ |
| W3C《PROV-DM》 | 标准文档 | provenance定义、Entity/Activity/Agent关系 | https://www.w3.org/TR/prov-dm/ |
| W3C《PROV-O》 | 标准文档 | provenance ontology、Agent责任关系 | https://www.w3.org/TR/prov-o/ |
