人工智能应用与知识

RAG开发

语言模型的好坏,取决于您把什么摆在它面前。多数令人失望的人工智能回答,其实是披着模型外衣的检索失败:正确的段落本来就在,只是从未被取出来。我们构建并调优检索层,然后加以衡量,让模型基于正确的证据展开论述。

业务问题

演示能成,是因为语料很小

朴素的向量检索在几百份文档上表现良好,超过几十万份就会明显劣化。切块会把表格和它的标题拆开。语义相近的段落挤掉了真正具有权威性的那一段。时效性输给了相关性,于是已被取代的旧政策排在了现行版本前面。这些在没有度量的情况下都看不见,于是团队上线、得到看似合理的答案,直到有人照着一个错误答案行动,才发现错误率有多高。

我们做什么

先把检索建好,再证明它有效

我们先用真实问题与已知正确来源构建评测集,因为无法打分就无法调优。然后我们打磨整条管道:尊重文档结构的切块、结合关键词与向量的混合检索、面向时效性与权威性的元数据过滤,以及对候选清单的重排序。当实体之间的关系比段落相似度更重要时,我们使用图结构,而不是假装向量就够了。每一次改动都对照同一个评测集打分,因此改进是被证明出来的,不是被声称出来的。

RAG开发

能力

  • 企业级RAG

  • 进阶RAG

  • GraphRAG

  • 混合检索

  • 向量检索

  • 检索优化

  • RAG评测

常见应用场景

常见应用场景

  • 为面向客户的助手建立依据,使它提出的每一项论断都能追溯到一份已发布的文件。
  • 在众多合同之间检索,答案取决于哪份协议起支配作用,而不是措辞相似度。
  • 检索技术文档,其中正确的内容往往是一张表格或一段图注。
  • 重建一个回答听上去合理、但出错频率高到已经失去信任的助手。

我们如何交付

我们如何交付

  1. 定形

    把需求转化为规格:谁在使用、什么算正确答案、由谁拍板。

  2. 接入依据

    连接到承载答案的内容与系统,并尊重既有权限设置。

  3. 评测

    在任何外部人员看到之前,用取自您自身案例的标注数据集打分。

  4. 上线与运营

    分阶段发布,配合监控、成本控制与守住质量的回归测试套件。

技术

技术

  • OpenAI
  • Anthropic
  • Azure OpenAI
  • pgvector
  • Elasticsearch
  • Microsoft 365
  • SharePoint
  • Confluence
  • Salesforce

安全与治理

安全与治理

答案以您自己的内容为依据并附带引证,读者因此可以核对。检索会遵守源系统上已经设定的权限,也就是说用户绝不会通过应用看到自己本来看不到的内容。提示词、检索到的上下文与响应都会记录以备审计,评测持续进行,而不是上线时做一次就算。

合作模式

合作模式

人工智能项目

我们对既定人工智能方案的设计与交付承担责任。

专属人工智能团队

围绕您的技术栈与交付模式建立的长期专属工程力量。

托管式人工智能

我们运营、监控并持续改进生产环境中的人工智能系统。

为什么选择 TeamExtension.ai

先度量,再调优

多数检索工作靠直觉:改一下切块大小,读几条回答,觉得好像好一些了。我们先构建标注数据集,这活儿并不光鲜,却正是调优与猜测之间的全部差别。它还会给您留下一套回归测试,使半年后的模型升级不会在无人察觉的情况下悄悄拉低质量。

部分客户

常见问题

常见问题

你们如何衡量检索好不好?
用一组标注过的真实问题,配上真正能回答它们的段落。我们报告正确段落是否被检索到,以及它排在第几位。回答质量单独打分,因为出自错误来源的好答案仍然是失败。
我们需要向量数据库吗?
多数情况下不需要。在既有PostgreSQL实例里使用pgvector,足以应对大量企业负载,且无需额外运维基础设施。只有当规模或功能需求确实值得时,我们才建议专用向量库,而不是默认就用。
什么是GraphRAG,我们需要吗?
它在实体与关系构成的图上检索,而不是在孤立段落上检索。当答案取决于跨文档的关联,例如股权链条或依赖结构时,它增加的复杂度才值回票价。对于大多数基于文本的问答,混合检索加重排序用更少的力气就能取得更好效果。
你们能改进我们已经建好的系统吗?
可以,而且这很常见。我们先构建评测集,衡量您现有系统的表现。这通常能精准定位失败所在,而修复往往比重建窄得多。
内容变化时,如何保持准确?
索引按计划或按变更通知跟随源系统更新,评测集持续运行而不是只跑一次。检索质量像任何其他生产指标一样被监控。

探讨您的 AI 计划

以您自己的内容为依据的检索系统,带引证且准确率可度量。