关注共识粉碎机，获取历史讨论会纪要

• 最关注的场景是代码补全，即在 IDE 里作为插件，在写代码的同时，会有一段灰色的ghost text 作为提示

• 大模型之前，很多 IDE 会有这样的功能，但是更多基于传统function signature的方式产生的提示

• 随着大模型能力变强，能够提示的内容越来越多，不只是单行的，会有一整段的代码来做提示；提示的准确率也会变高

• 这个功能是工程师在使用AI Coding 产品中应用最广泛，实际真正用起来，感知到价值的成熟场景。大家能够用的比较好，也在于使用方法并不是新产生的，以前大家就有这个习惯

• 虽然大模型给的答案并不是 100% 完全正确，但给出答案已经对工程师写代码比较有帮助，就会选择 accept 给出的建议，后续自己再做一些调整。这整个 workflow 对工程师非常自然，并没有额外负担

• 更宽泛的代码补全功能也会涉及到写注释，注释这一块因为大模型的能力除了代码能力，自然语言的能力也包含在其中，所以通过代码补全这个形式，也是能做注释事情，包括生成unit test等等

• 使用的比较多的是 chat 的场景，像是developer focus 的ChatGPT 的这种交互，在写代码的时候，基于代码规范，或者通常的惯例问题，以前会问Google，Stack Overflow 等，现在会问ChatGPT

• 但ChatGPT也不是developer specific的，包括一些企业也不希望开发人员把内部的代码或者问题expose 到GPT上。所以也会使用一些封闭的developer specific的chat

编程的流程里面还有很多其他场景，哪些场景是Copilot产品比较难做的？

• 程序员即使是使用同一个工具，不同的程序员使用的方法也会非常的不同

• 现在整体还在摸索的阶段，当把产品推出之后，会发现有几个人会是超级用户，他们的工作效率可以上升两、三倍，但大部分人可能只有20%-30%的上升，甚至有一部分人觉得使用AI 没有任何好处，甚至觉得会对工作效率有负面的影响。比如看到代码补全给出的建议，会觉得影响了思维流程

• 即便是超级用户，使用的补全方法也非常不同。现在还没有完全完成收集数据的阶段，还在试图了解这些使用上最有效果的人是如何使用的。先要搞清用的最好的这些人是怎么用的，然后再想办法怎么样把他们的经验去简化

• 很多产品都可以由代码补全衍生出来，不管是编辑还是自动实现的，比如a键之类，可以看作是补全的延伸。比如用代码补全和其他搜索来寻找代码里不懂的部分，不知道interface是什么样的，是不是已经有一些程序在做想要实现的功能？当需要一个新的辅助函数的时候，是重新编写一个，还是在现在的codebase里面去寻找？如果选择去找，应该在哪找？这些问题理论上来说都是可以通过代码补全来完成，也确实看到很多人是用代码补全去做这些事情。但有的人其实对这些就比较抵触，或者不愿意去摸索。所以产品侧还在了解哪些东西对大家帮助最大

• 代码补全对延迟还是有要求，所以对模型尺寸有一定的要求/限制。infrastructure 在相同的计算能力下，模型就只能用达到某一个尺寸的模型，不然再大的话，比如说超过 0.4-0.5 秒延迟之后，使用感就不好。模型需要理解正在更新的代码，需要了解上下文，最后是各种不同的模型的结合，对于不同任务调用不同的模型来实现

• 在部署环节产生的error信息，或者其他开发人员产生的debugging 的knowledge 等，如何让其他工程师写代码的时候，能够把这些的信息摄入到开发过程中

• 不仅仅需要模型能力更强，CICD 的工具里面，比如 Jira 的 issue ticket 等的信息都需要和模型的能力做融合。而且相关数据可能也并不是一个通用的大模型能做得很好，因为很多debugging 的信息， issue tracking 等，也是企业specific的

• 如何有一个安全又简易的方式，能够让企业把这些信息结合，是这类产品长期比较关注的。Github Copilot现在也比较重点做这一块，他们和Jfrog、Jira等做一些集成，类似于extension marketplace的一个方式，通过和这些公司来做这种partnership来做信息和功能的继承

用户侧处于被教育或者被训练的过程中，还是说因为AI Coding因为强交互、强 workflow，产品形态可能没定下来？

• 产品形态来说确实还没有完全定下来

• 代码补全是比较简单的交互形式，用补全的时候用户的自主性也比较高，比如想写注释来生成代码，或者有的人喜欢写代码来生成注释，用户有这个自由

• 但是一旦把这个补全升级成一个更加自动的功能，比如说用户写代码的时候AI Coding可能提示下一个地方应该在什么地方编辑，或者建议一下哪些地方的代码可能需要引用等。这些功能的限制就更多一些，和用户交互没有代码补全这么自由

• 所以现在产品主要还是靠代码补全，让用户自由的去做所有想做的事情，然后观察什么样的东西对用户最有帮助，去补充其他功能的产品形态

• 代码补全之外的产品尤其没有完全定型。用户需要chat，但是chat功能和用户交互是还没有解决的问题。如果只是和AI对话，像 ChatGPT 一样，回复一段代码，AI很多功能都被浪费掉了。用户很多时候需要在chat的过程中直接获取信息，或者直接进行action。那么这些 action 如何设置，现在的产品还没有完全的搞清楚怎么样做最好

• 对于chat, 有人希望用一段自然语言，然后Copilot生成一段代码，代码基本上可以跑通。还有一些人把chat做成像Google 一样，用户去问一个问题，去查一个Java，或者C++的一个特定用法，然后Copilot给出一些案例。还有的用户有一段代码，想让Copilot做一些简单的优化。比如变量名字从A变成B等等。总的来说对于Chat的用法非常多样

• 从产品形态上也有几种，如说像Phind，有点像Perplexity to Developer 的产品界面。还有一些会把chat做到 IDE 里面， 作为IDE的side panel，然后在其中问一些问题，还有比如想对代码做优化，会把这个功能做到IDE的 inline chat 里面，选中一段代码，然后针对这段代码来问答
• 这些形态一定程度上叫Feature Market Fit，就这些 feature 其实用户的使用方法是这个样子，那其实它都是有很大帮助的。总的来说就是针对CHAT这一种形式产品的形态，大家都有不同的探索，还没有一个产品已经把这个产品定义的非常清晰，或者绝对领先

从3年的时间长度看，AI Coding产品会进化到一个什么程度？比如说三年后（目前觉得这些Copilot大概提升了开发者20-30%的效率）

• 在衡量智能编程助手如Copilot对开发效率提升的影响时，面临一些挑战

• 首先，衡量这些工具带来的效率提升是一个主观且复杂的任务。业界普遍关注的一个具体指标是接受率（acceptance rate），即智能助手提供的代码补全建议中有多少最终被开发者采纳。这是一个被广泛关注的指标，但随后也有提出其他新的指标，例如AI生成的代码有多少真正被合并到代码库的Pull Request中。这些尝试都是为了更客观地量化智能编程助手的效果。然而，即使有了这些指标，衡量这些工具是否真正提高了工程师的工作效率仍然是一个挑战。例如，平均接受率可能达到30%或略高，这被视为一个合理的基准。但这个接受率是否真正代表了工程师效率的提升，还存在一定的差距
• 从企业的角度来看，他们可能更关注经济效益，即投资于这些产品后，工程师的效率提升能带来多少实际的经济回报。这可能是一个更难以量化的点。因此，如何更好地量化智能编程助手的效果，是一个具有相当挑战性的问题
• 随着模型能力的不断增强和硬件推理成本的降低，这些因素都将极大地推动智能编程助手产品的采用。未来，随着技术的进步，可以期待接受率可能达到40%或50%，这将是一个积极的趋势。总的来说，智能编程助手的未来发展和它们对开发效率的实际影响，需要我们持续关注和深入研究

• 从对实际用户的观察来看，确实一旦有人开始习惯用这个编程助手，他的编程方式就会慢慢改变。有些流程和习惯一旦变了，再想不用它就难了。就像有时候，虽然说不出具体提速了多少，但如果助手突然不能用了，比如出现了服务中断，那些自动补全和其他功能都没了，用户可能就会选择休息，甚至直接回家了。因为以前都是助手帮忙做的，现在得自己来，心里就有点抗拒。所以随着时间的推移，会有更多人开始习惯用编程助手。一旦习惯了，想回到不用的状态就不容易了。当然，每个人情况不一样。有些人很快就能适应，用起来得心应手。但也有人用了几次就觉得效果没那么明显，没有让他们的编程体验大幅提升。现在我们还不太明白为什么这些人会有这样的差别，这确实是有意思的问题
• 在海外企业中，普遍存在这样一种心态：如果公司不采用人工智能编程系统工具，那么它可能会被视为缺乏创新精神的企业。这种担忧源于企业对自身作为前沿科技公司的形象维护，它们倾向于使用创新的工具来保持先进性。这种观点在实际商业环境中经常被提及，并且在与市场推广方向的专业人士交流时，这也是他们品牌建设的一个关键点。然而，尽管这些工具在品牌形象和市场推广中具有重要价值，但要具体量化它们带来的实际效益确实相当困难。尽管如此，这些价值实际上对智能编程助手等产品的采用起到了积极的推动作用。企业意识到，采用这类工具不仅能够提升工作效率，还能够在竞争激烈的市场中树立创新的形象，这对于吸引优秀人才和保持行业领先地位至关重要。

2 AI Coding Copilot产品的技术细节

代码优化，该功能需要对系统上下文做关联，代码优化目前能做到什么样的程度？

• 在进行代码迁移或翻译的过程中，涉及到对多种编程语言的深入理解以及对上下文和系统实现的全面把握。面对复杂的任务，需要开发者具备高度的理解能力和对代码逻辑的深刻洞察。然而，这种类型的代码操作在当前阶段仍然极具挑战性，尤其是在处理大规模代码段时，对开发者的逻辑理解能力提出了更高的要求
• 在实际开发过程中，注意到一些看似微不足道，但实际上对工程师日常工作影响深远的琐碎问题。这些问题，虽然繁杂，却非常适合利用人工智能技术进行自动化处理
• 例如，开发者在编写函数时可能需要将函数名从snake_case（下划线命名法）转换为camelCase（驼峰命名法），或者进行大小写的优化调整。此外，代码的缩进调整也是一个常见的需求，开发者可能希望对特定代码段进行更合理的缩进以提高可读性。在传统开发环境中，这些任务通常需要手动设置IDE快捷键来完成。但现在，借助人工智能的能力，这些优化任务可以被自动化，从而显著提升代码质量和开发效率

AI Coding这个领域需要多大的模型？

• 在代码补全领域，业界普遍认为模型规模越大，其补全效果往往越好。然而，随之而来的是部署成本的显著增加，这种成本的增长有时甚至是指数级的
• 在实际评估逻辑中，会通过一些类似Tabby的排行榜（leaderboard）进行评估，发现在成本效益方面表现较为理想的模型参数规模大约在70亿到100亿之间。在这个参数规模范围内，客户在成本考量和整体效果上取得了较好的平衡
• 此外，值得一提的是，尽管有些公司可能不会从头到尾训练自己的基础模型（foundation model），但像Tabby会支持客户在现有模型基础上进行微调（fine-tuning）。目前，Tabby也在探讨一些新的方法，如知识蒸馏（knowledge distillation）等技术，这些方法能够帮助企业将其内部代码库的知识和能力与模型更好地结合

AI Coding产品，从 Copilot 技术实现角度的话，接 API 和产品公司自己训练模型有什么区别？这种选择是由哪些因素决定的？

• 以Tabby为例，并不自行训练模型，也不属于模型开发公司。其主要优势在于能够与各种开源或私有的模型进行有效集成，无论是经过微调的企业模型还是通过API提供的服务
• 在技术实施方面，Tabby虽然不控制底层模型，但在模型之上构建了具有深度的自有技术层。许多人可能会认为，如果不开发模型，就仅仅是在现有API之上增加了一层包装，会不会技术壁垒比较低。然而，实际上Tabby在模型之上做了很多工作，拥有自己的核心技术
• 例如，在模型的解码层，Tabby采用了自主开发的技术。特别是在与代码相关的解码过程中，采用了一些更具特性的方法，将代码的语法规则和先验知识整合进来，以提升用户体验。这不仅提高了代码补全的准确性，也增强了与代码相关的特定功能
• 此外，在实际应用中，Tabby还关注如何将这些技术与用户的实际需求相结合，以提供更加个性化和高效的服务。通过这种方式，Tabby能够为用户提供超出基础模型功能的附加价值，即使Tabby自身并不直接参与模型的训练过程
• 在智能编程助手领域，即使是一些看似简单的问题，例如何时触发代码补全功能，何时不触发，实际上都蕴含着大量的优化空间。如果触发补全过于频繁，可能会干扰用户的工作流程；而如果触发太少，则产品可能失去其应有的效用。因此，如何结合用户的使用习惯等各方面因素，将这些细节做到尽善尽美，是Tabby团队非常关注的问题。此外，Tabby也关注不同集成开发环境（IDE）扩展的集成工作，以及模型层的优化，尽管并未直接开发模型，但我们看好开源模型和整体大模型能力的长期发展
• Tabby也发布了一个排行榜，展示不同编程模型在Tabby平台上的性能表现。关注了如DeepSeek的Coder模型，阿里团队最近发布的CodeQwen1.5模型，Mistral AI最新发布的Codestral等等，它们在整体效果上都比较出色
• 在补全场景中，使用大型模型是不现实的，这一应用对延迟等性能要求较高。目前，许多用户使用的模型，如DeepSeek的Coder模型和CodeQwen1.5模型，大约在70亿到100亿参数之间，这是一个成本效益比较高的模型规模。Tabby与这些团队进行了深入的交流，以实现更好的集成

• 总的来说，自行训练模型与不训练模型各有其优势与劣势。自行训练模型可以为组织带来独特的功能和能力，这些通常是现成模型所不具备的。如果希望模型展现出特定的行为特征，通常需要通过训练来实现。尽管可以通过工程手段来弥补某些功能，但这可能会使系统运行更为复杂，或者在实现时速度较慢
• 然而，自行训练模型也存在缺点。例如，如果一家公司投入大量资源训练了一个模型，而随后另一家公司开源了一个编程能力更强的模型，那么前者的投入就可能变得不再具有成本效益，因为这是一个相当大的开销。如果每个组织都去训练自己的大型模型，这显然不是最有效的方法。考虑到像Meta这样的公司已经在模型训练上投入了巨额资金，并且将其开源，如果不利用这些资源，就可能未能充分利用它们对社会的贡献

• 因此，组织在考虑是否自行训练模型时，需要权衡开发独特功能的需求与利用现有开源资源的优势，同时考虑到成本效益和对社会资源的合理利用。此外，从长远来看，拥有训练模型的能力可能在未来变得非常重要。尽管目前可能不是最关键的，但随着时间的推移，这种能力可能会变得至关重要
• 同时，即使某些模型在特定领域不是最优秀的，通过训练这些模型所获得的经验也是宝贵的。如果没有这种经验，当需要开发新功能时，组织可能不会那么方便。这就需要在开支和收入之间进行仔细的平衡，因为模型训练的成本非常高，而收入却不确定
• 例如，如果一个组织训练出了一个性能优越的模型，并且能够在市场上保持领先一年，那么这将带来显著的好处。然而，如果另一个组织训练了一个模型，但很快就有更优秀的模型被开源，那么前者的投入可能就没有带来任何商业利润。因此，这是一个复杂的问题，需要组织在战略层面上进行深思熟虑的决策

代码版权相关会有哪些风险及如何规避？

• 当前大型模型多基于开源代码库进行训练，其中一些项目虽开源但可能包含商业使用限制或其他特定许可要求。如果AI提示的代码直接来源于这些不允许商业用途的开源项目，可能会引发知识产权方面的问题。例如，微软的GitHub Copilot和Google的相关产品都承诺，如果用户在使用过程中遇到知识产权诉讼，他们将提供必要的支持和保障
• 为了在代码知识产权层面为企业提供保护，希望提升系统的提示和警告功能，以更好地管理和降低风险。关于生成代码的版权风险，尽管微软等公司提供了一定程度的兜底，但是否能够完全解除版权顾虑，这仍然是一个开放的问题。目前尚不清楚是否有关于代码风险的实际案例以及最终的裁定结果
• 此外，其他领域，如图像生成，也存在类似的版权争议，例如Getty Image、New York Times与OpenAI之间的纠纷。这些案例的进展和结果值得业界关注
• 在技术层面，使用RAG等技术可以降低版权风险。因为RAG通过检索和复现已有代码库中的代码，减少了直接使用第三方公共代码的可能性。如果AI生成的代码与用户自己的代码库高度相似，并且进行了适当的修改以适应特定的需求，那么版权问题就不太可能出现。只有当模型直接复制整个函数或代码段时，才可能引发严重的版权问题
• 通常采用的策略是使用相对较小、响应速度更快的模型，并通过RAG来增强其生成能力。这样，由于RAG中的代码来源于用户自己的代码库，版权问题的风险就会降低。同时，选择透明度高、使用无版权争议数据训练的开源模型，也是一种避免版权问题的策略。通过这些方法，我们可以更有效地管理和降低AI在代码生成过程中可能引发的版权风险

3 AI Coding Copilot产品客户落地实践中的考量

客户在接产品的时候，同时可以接多少个模型，以及客户会有一些反馈，比如说哪些场景适合用哪些模型，以及做 decoding layer， decoding layer 这个工作需要涉及到接什么模型以及跟客户 fine-tuning 这些相关吗？

• 对于解码（decode）这一环节，实际上它与特定模型的关联性并不强，或者可能会有一些细微的工作差异，但总体上并不需要额外的大量工作。至于能够接入的模型数量，这主要应从客户的角度来考虑：为什么他们需要接入多个模型？

• Tabby支持一种接近模型路由（model routing）的逻辑。例如，有客户表示，他们的企业内部实际上存在许多领域特定语言（Domain Specific Language, DSL），这些可能是外部不存在的自定义语言。基于GitHub上的开源代码训练的模型可能并不具备处理这些语言的能力，因此客户可能会选择针对自己的DSL进行微调（fine-tuning），生成一个专用模型。同时，他们内部也有进行通用编程工作的部分，如使用C++或Java等语言，这时客户可能希望在工程师使用领域特定语言工作时触发微调模型，而在进行通用编程任务时使用通用的开源模型
• 客户也可能会有这样的需求：在某些场景下，使用较小型的模型也能达到令人满意的效果。或者对于公司内的关键团队，可能会使用更大型的模型以获得更好的性能，而对于其他团队，则可能使用更小型的模型。他们希望能够灵活地实施这些逻辑
• 目前，Tabby能够很好地支持这种灵活性。允许客户根据自己的具体需求和不同团队的特点，选择最合适的模型，无论是微调的专用模型还是通用的开源模型，都能实现有效的集成和应用。这种灵活性不仅满足了客户多样化的需求，也使得Tabby的产品和服务能够更好地适应不同客户的个性化场景

目前尚不确定的是，实现这一设想的难度究竟有多大？因为许多企业的代码库可能非常庞大，这无疑会带来一系列精度问题。所以基于代码库应用现有的编程助手工具，并将上下文理解与系统级能力整合进来的难度究竟如何？是否有客户已经在这方面取得了良好的成果？此外，目前主要采用哪些方案来帮助客户进行这种相对定制化的工作？

• 企业使用Coding Assistant的需求与个人开发者使用时存在显著差异。个人开发者在处理小型项目时，可能对此类工具的需求并不大。然而，企业内部往往拥有许多私有代码库，他们希望将这些知识整合到工具中以实现更好的应用效果。Tabby团队目前非常关注这一点，已经实现了与GitHub、GitLab等的集成，并计划未来支持Bitbucket等其他平台。支持用户指定代码库，并能够将这些库中的信息索引到系统中

• 具体实现方式相对普遍，主要有两种：一是通过类似RAG的方式，对代码库进行本地索引，并在编写代码时根据当前上下文检索相似案例，供大型模型生成参考；二是通过微调（fine-tuning）的方式，在整个代码库上对模型进行微调，以适应企业内部代码与外部开源代码的差异。选择哪种方式取决于企业内部代码与外部的差异程度。如果企业拥有自己独特的领域特定语言（DSL），可能需要通过微调来整合这一能力。如果代码与外部开源代码差异不大，可能通过RAG等方式就能取得不错的效果

• 然而，在实际落地时，评估这些措施的效果提升及其成本效益比是一个难点。目前，评估指标的选择和科学测量方法存在挑战，许多客户可能仍依赖于直观感受来判断工具的效果。此外，部署方式的差异也带来了不同的考量。由于我们的产品采用云部署而非本地部署，客户只需安装插件即可使用，这简化了部署流程。但这也带来了数据上传、交互和隐私的问题，需要确保用户清楚哪些数据被上传到云端，以及谁可以访问这些数据。特别是，即使在同一个代码库工作，其他用户也不应看到未提交的代码
• 至于RAG的效果衡量，评估其优化效果的具体提升百分比可能较为困难。因为通常能做的优化只是小幅提升，但从无RAG到有RAG，或者从工作效果不佳的RAG到工作效果良好的RAG，差异是显著的，尤其是在模型大小有限的情况下
• Tabby与AugmentCode之间也存在差异，Tabby更强调自托管（self-host）场景，即企业自行部署在自己的私有云或本地环境中，而Augment更偏向于公有云。这是一个细分市场差异点。许多大型企业对云解决方案存在顾虑，希望完全控制自己的代码，尤其是当使用云端API进行大模型生成时，企业担心自己的代码可能存在潜在的信息泄露风险。Tabby作为一个开源项目，提供了更高的透明度和灵活性，允许企业更自然地将其集成到自己的代码pipeline中
• 与一些大型企业接触时发现，对安全性、透明度以及自托管场景有较高需求。这也是Tabby相对于许多纯云产品的一个差异性。此外，Tabby在市场推广策略上也有所不同，早期的一些策略与GitLab早期的策略有相似之处，GitLab最初也是基于开源和自托管方案起家，后来推出了自己的云产品，并与GitHub等竞争对手展开了直接竞争。Tabby也是从开源和自托管方案开始，奠定了基础后再进行拓展

有非常多这个企业自己去结合他们数据的方式，包括用RAG，然后也支持 fine tuning等等。从效果上来看，企业如果结合自己的 Codebase 以后会有质的差别吗？

• 一般来说，一个从无到有的过程，能够让用户感受到质的飞跃

• 以企业内部代码的整合为例，如果系统未能结合企业内部的代码库，当开发者需要复用同事刚刚提交的代码中的某个函数时，可能无法得到有效的提示。在这种情况下，即使系统提供了某些提示，这些提示也可能来自于外部的开源工具，而非企业内部实际使用的代码，这可能对用户并无实际帮助
• 然而，一旦系统增加了结合企业内部代码的能力，比如能够提示同事刚刚提交的代码中的函数名称，这将极大地提升用户体验。这种能力的提升，不仅能够增强代码复用性，还能促进团队协作，因为开发者能够快速地找到并应用适合的内部代码资源。这样的改进，无疑会给用户带来令人愉悦的惊喜时刻，显著提高开发效率和工作流程的连贯性

大部分的企业可以自己去做，RAG，context window，或者去 fine-tuning 吗？还是这些 Coding Copilot 产品在卖给客户的时候，还要提供比较重的 service 的服务，需要结合 service 的服务帮客户去做这些定制化的工作？

• 在这个领域，RAG的应用已成为一种标准化实践。用户仅需将其代码库的地址上传至管理员页面进行配置，即可实现知识的整合。此过程包括设置必要的权限，以规定哪些用户能够配置特定代码库的索引

• 通过集成GitHub、GitLab等平台，用户仅需复制并粘贴代码库地址，后续的索引和集成工作将自动启动，实现全自动化的流程。然而，微调过程目前尚未实现标准化和自动化。这是因为不同用户对微调的需求差异较大，且针对特定需求进行优化的方法也各不相同
• 例如，一些客户可能在其内部定义了独特的编程语言，需要特定的微调方案来适应这些语言。另一些客户可能因行业需求，对底层基础设施或核心代码进行了深度定制和优化，以适应特定的硬件环境。在这种情况下，他们希望模型能够提供针对其特定底层基础设施的代码提示，而非通用的开源库提示
• 基于这些特殊情况，微调模型的训练、优化和评估方法也会有所不同。因此，许多公司在微调方面采取的是案例化处理方式，这部分需要针对每个客户的具体需求进行个性化调整

另外RAG的实现形式本身也存在多样性。一种方法是采用向量化的方式，将代码转换为向量表示，以便于RAG处理；另一种可能的方式是采用更传统的搜索技术，类似于文档检索，来支持RAG的构建和查询。这些不同的方法可能会根据企业的具体需求和偏好而有所不同？

• 在配置相关功能时，必须对用户权限进行严格控制，包括明确告知用户配置后代码的可见性等信息。如果许多企业采用自托管（self-host）模式，企业在配置时可以拥有更高的权限，因为它们完全拥有和控制这些资源，从而减少了安全方面顾虑。因此，许多企业可能会选择将整个代码库导入Copilot，以便Copilot能够提供更全面的信息
• 接下来的问题涉及到嵌入检索（embedding retrieval）与基于关键字的搜索（keyword-based search）方向的检索技术。这些技术细节通常不需要向客户公开，供他们选择或配置，而是由产品侧进行内部持续进行优化
• 当然，这方面的优化既考虑了检索效果，也考虑了延迟（latency）。例如，嵌入检索可能在授权方面更慢一些，或者在整体上更昂贵，而基于关键字的搜索由于更接近传统的搜索方式，可以更快地执行，但在语义上可能不够精准。我们内部会进行大量的优化和迭代，而不需要在客户层面进行过多定制
• 此外，RAG不仅结合了企业代码库中的知识，还会结合工程师在使用过程中的一些信息，例如最近更新的文件、粘贴板中的内容，这些信息都可能与当前编写的代码高度相关，可以集成到RAG中，实现多方面的结合

• 关于RAG和长上下文（long context）问题，虽然现有模型可以处理很长的上下文，理论上可以将大量代码放入上下文中，但如果频繁调用，长上下文对显存的要求很高，这可能导致显存资源紧张，甚至单个GPU只能支持一个用户。因此，尽管越来越多的模型支持越来越长的上下文，但如何在较低成本下服务长上下文仍然是一个未解决的问题。在调用频率较低的场景中可以使用长上下文，但在高频调用场景中则较为困难
• 即使使用长上下文，其对代码的理解也不一定能达到完美水平。实际上，即使在长上下文的情况下，进行RAG等操作仍然有好处。而且，改变上下文长度对部署的影响也是显著的，因为它对显存使用和延迟有很大的影响，因此这不是一个容易调整的变量

Gemini刚出100万token 的context window，有一些讨论觉得可以把一整个企业所有的 Codebase 全扔去进去。但是这个基本上从成本考量基本上是不可能完成的？

• 在审视Google的代码系统时，可以观察到并不会采用极长的上下文（context）来处理代码。即便Google拥有庞大的代码库，其系统也不会使用长达一百万token的上下文。因为这样做不仅速度上难以实现，而且在技术层面上也面临诸多挑战。当上下文增长到一定程度后，系统可能需要重新处理大量的上下文信息，或者受限于显存的容量，导致上下文的减少
• 总体而言，这些挑战指向了一些在当前技术条件下难以克服的难题。尽管我们可以预期，随着技术的进步，未来几年内可能会出现更有效的处理长上下文的方法，但就目前而言，这一问题尚未得到解决。这种技术发展的局限性意味着在设计编程辅助系统时，我们必须在上下文的长度和系统性能之间寻找一个合理的折衷方案

目前to Developer 可能现在是市场的产品的主要形式，但是如果要做大客户，可就要关注大客户效率提升的指标，即要有明确的ROI指标才能够去谈动一个大客户的单子，以及如果做大客户，商业模式和 Developer也可能不一样。不一定完全按照Seats收费，也可能按照RAG或者 context window的调用这种 consumption 的情况来收费？以及如果是去做这种大客户的话，还有哪些难点，及解决办法？

• 大企业对安全性和控制权有较高关注。有些大企业全球developer的团队规模都至少在500至800人以上。这些企业所关注的问题，包括评估指标和效果，都是比较重要的因素

• 然而，针对大型客户，他们关注的重点和选择开源自托管方案的原因可能各不相同。例如，即使所有企业都需要微调（fine-tuning），但微调的原因和需要解决的问题也各有差异。即便提供的解决方案类似，在每个大客户上更好地理解他们的需求，并使用他们熟悉的语言或针对他们的目标来解释方案，也有很多技巧要求

• 还有一点是大多数企业，特别是大型企业，并没有统一的软件采购要求。除非是像Google或微软这样的公司，可能会有明确的要求使用特定的代码系统。对于大多数大型企业而言，使用何种软件通常由团队自行决定，而非公司层面统一规定。因此，如果从团队层面入手，并不是特别困难。一旦某个团队采纳了产品，即使最初只有少数人使用，只要产品质量足够好，它会逐渐在企业内部传播，使用量会自然增长。企业内部的交流将促进这种增长。但前提是软件必须足够好用。如果软件的易用性达到了一定程度，就可以依赖其自然增长。一旦赢得了一个团队的青睐，那么在整个企业内的推广将变得更加容易

客户有把AI Coding 产品部署到PC上的需求，具体的情况是怎样的？

• 目前，这种需求似乎主要来自于一些具有极客精神的个人开发者。这类开发者通常拥有自己的个人电脑（PC），并且已经购置了GPU。他们倾向于亲力亲为，对技术充满热情，喜欢自己动手实践和折腾各种技术项目。如果他们拥有性能较强的GPU，那么自行部署和使用相关软件对他们而言是无需额外成本的。此外，即便在没有网络连接的环境中，他们也能够利用本地资源进行工作
• 虽然这些个人开发者的需求并非商业化重点关注的场景，但近期开始注意到，随着戴尔、微软、NVIDIA等大公司开始强调人工智能个人电脑（AI PC）的概念，这一领域正在逐渐受到关注。AI PC预示着未来的个人电脑将内置更强大的处理器，可能自带先进的AI能力。这意味着企业在采购时，为工程师配备的设备将具备更强的本地AI处理能力
• 一些企业已经开始探讨这一趋势的具体影响，包括何时这种设备将普及、成本效益如何，以及如果选择这种方案，是否只需采购具备AI能力的PC，就能实现本地化的AI应用，从而降低额外的软件服务成本。尽管这些讨论显示了企业对这一趋势的兴趣，但AI PC从概念到实际应用的落地还有一段距离。AI PC作为一个新兴话题，预计在未来将引发更多的讨论和探索
• 选择何种硬件配置取决于所需运行的模型规模。对于一些较小型的模型，例如一些1B、3B的模型，当前市场上的中高端MacBook已经具备足够的计算能力来运行这些模型。实际上，一些对性能要求不是特别高的开发者已经在使用MacBook进行开发工作
• 从GPU角度说，在MacBook上运行模型的情况下，如果需要处理更大规模的模型，目前市面上有许多选择，例如使用NVIDIA的T4 GPU，或者一些消费级的显卡，如RTX 20系列或30系列等。这些硬件都能够支持运行一些相当有用的大型模型，为用户提供了更偏向本地化的体验
• 对于企业用户而言，使用T4 GPU是一种常见的选择。对于一些对计算性能有更高要求的场景，也可能会采用H100等更高端的GPU来满足大量工程师的需求。随着硬件技术的进步和人工智能应用的普及，企业在部署这些资源时拥有了更多的灵活性和选择空间

会有企业从安全角度，或需要员工有离线编程能力，要求以后在 PC 层面上部署AI Coding产品吗？

• 企业在考虑私有化部署时，主要的决策因素之一是成本。企业会评估在自有服务器上部署或本地部署的成本效益，包括询问所需的PC配置以及相应的成本。如果选择在自己的私有云或服务器上部署，安全性方面的考虑与使用公有云产品相比并无太大差异
• 此外，部署方式的选择与企业的使用规模密切相关。例如，如果一个企业拥有数百名程序员，为每位程序员配备小型GPU可能成本较高。相比之下，购买少量高性能GPU，如H100，并允许员工进行批量请求，可能会提高GPU的使用率，从而降低整体成本。如果每位程序员单独购买GPU，这些设备大部分时间可能处于闲置状态，这在资源利用和成本效益上可能不是最优解
• 因此，从成本效益角度出发，企业可能会倾向于选择共用高性能GPU的部署方案，这在资源利用率和成本控制方面对企业更为有利。这种方案不仅能够提高硬件的利用效率，还能降低企业的总体拥有成本（Total Cost of Ownership, TCO）。随着企业对成本和资源管理认识的深入，这种灵活且高效的部署模式可能会越来越受到青睐

4 AI Coding Copilot产品差异点是什么及形成

如何形成和Github Copilot 的产品差异点，以及除了 Github Copilot 以外，像其他的Codebase，如GitLab 也在做Copilot产品，怎么去和这些 Codebase 的 Copilot 找差异点呢？

• 产品角度：专注于开源模式、支持私有化部署（self-hosting）的场景、产品架构上更加云原生是产品上的一些差异点

• 实际上，许多大型企业更倾向于能够自行部署产品，同时也重视产品的灵活性，如能够接入不同的模型或进行自定义的微调（fine-tuning）。此外，一定程度的透明度也是客户所关注的，比如模型在每一步使用了哪些数据，这些数据被谁访问等
• GitHub Copilot作为去年推出的产品，也开始关注企业最高级别的需求。但他们的方案在成本和部署难度上仍然较高。相比之下，一些其他致力于使部署过程更简单、更易操作。例如，利用MacBook上M1或M2芯片，仅需几条命令即可完成部署，提供出色的本地体验
• 此外，本地PC或Mac上的体验也是一个不容忽视的场景。随着NVIDIA、戴尔等公司提出AI个人电脑（AI PC）概念，以及微软的强劲LAK（Local AI Knowledge）概念，可以预见未来每个工程师的PC可能都配备有更强大的硬件，以支持更原生的本地AI功能。如果本地设备具备更强的能力，那么更多的编程工具或许可以在本地运行
• 而且尽管GitHub Copilot拥有广泛的用户基础，但仍有许多领域是它未能覆盖的。例如，有一部分用户出于安全考虑，需要将代码本地化，这是Copilot目前做不到的。此外，产品本身也存在一些缺陷，如补全速度不够快，质量参差不齐，有时甚至会产生错误的预测（hallucinate）。要与Copilot区分开来，其他产品需要在速度上超越它，提供更高质量的模型和对代码库更深入的理解
• GitHub的主要优势在于其与生态系统的紧密整合，这是初创公司难以追赶的部分。例如，作为微软的一部分，它能够控制哪些功能可以集成到VS Code中。要在这方面胜过它，其他产品需要在模型质量和对代码库的理解上做得更好

GitLab也在做自己的Copilot，听到一些讨论，从客户接受程度来看， GitLab 的产品比 GitHub 产品应该还是差了不少？

• Gitlab 在AI领域的进取程度不及GitHub，但他们确实推出了名为DUAL的产品

• Gitlab在产品定位上有几个显著特点。首先，他们将GitLab定位为一个深度集成开发周期（devcycle）的工具，不仅包括安全性和开发运维（DevOps）工具，如持续集成/持续部署（CI/CD）等，而且在整个生命周期中都有所涉及。DUAL产品更注重在这一长周期内集成各种AI能力，其中代码编写（coding）只是一小部分。他们的目标是在GitLab涉及的每个环节中都融入AI技术，以提升整体性能
• 从资源和优先级的角度来看，代码编写功能在Gitlab的AI版图中仅占一小部分。就他们的方案而言，在AI能力的整合方面，Gitlab的所做工作相对浅显。据了解，Gitlab采用了Google Cloud的Code API，并可能集成了其他一些服务。集成方式较为直接，主要是API的集成，对于AI能力的控制和管理则相对浅层。由于他们集成的是云API，因此无法提供纯自托管（self-hosted）或完全离线的环境体验，这可能是他们目前产品所无法实现一些点

5 AI Coding 产品对程序开发工作流和相关职能的影响

未来，如果智能助手被广泛采用，那么可能会对这些开发职能产生什么样的影响？例如，项目经理的角色可能会因为智能助手的介入而发生显著变化，其作用可能会有所减弱。同时，我们可能会看到，在传统的逐步使用各种软件栈的过程中，一些软件栈可能会合并，或者智能助手能够完成端到端的工作流程。可能对现有的工作流程和角色分配带来深远的影响？

• 将智能助手集成到企业工作流程中，以实现自动化和效率提升，是一个可以预见的发展方向。然而，在短期内实现这样的效果还面临许多实际挑战，这可能是一个更长远的发展趋势
• 目前，大多数智能助手产品主要针对开发者或工程师，旨在提高他们的工作效率。对于产品经理、项目经理等其他角色的优化，以及对整个工作流程可能产生的影响，这些产品的覆盖和深度相对有限
• 例如，像Jira这样的项目管理工具，看到了一些用户侧的集成创新的尝试。一些产品可能希望实现这样的场景：用户在GitLab或GitHub上提交一个问题(issue)，背后的智能代理(agent)能够自动编写代码并完成合并(merge)。减少工程师处理一些简单问题的工作量。然而，也观察到，这种自动化的成功率相对较低，而且在很多情况下，仍然需要工程师的参与，这可能导致时间成本并不划算
• 同时，也关注与GitLab、Linear等系统的集成。更关注如何将这些系统中的问题讨论、代码片段等信息，以及其中蕴含的知识，整合到新工程师的代码编写过程中。这类似于有一个经验丰富的开发者在旁边指导，提供有用的提示，比如建议编写某段代码，或者在处理问题时参考某个特定的issue
• 对于相对年轻的程序员来说，智能编程助手可以更容易地帮助他们熟悉之前并不熟悉的代码库。过去，新程序员可能需要不断地向资深开发者询问，以理解代码结构和定位所需的代码段。而现在，无论是通过代码片段的自动补全还是通过交互式的对话，智能助手都能显著降低新程序员的入门难度
• 然而目前智能模型的能力尚未达到能够促使公司真正改变其工作流程的程度。即便是像GPT-4这样的先进模型，或是任何其他开源模型，它们目前的性能还不足以支撑这种变革。要实现更深层次的集成，模型的性能需要进一步提升，并且可能在未来几年内需要经历一个相对缓慢但稳定的提升过程，才能真正达到更高的水平。可以观察到，即使在已经部署了智能编程助手的公司中，可能也只有10%到20%的程序员真正在日常工作中使用

• 那些尚未使用智能助手的程序员，主要原因是认为模型仍然存在错误。模型有时会提供令人惊喜的解决方案，有时则提供便利，但有时也可能导致烦恼和困难。因此，要提升模型的能力，无论是通过增加模型的上下文理解能力，还是通过更好地理解代码，或是整合更多的数据源，都需要在多个方向上进行大量的工作，以使编程助手变得更加有用。就目前而言，智能助手提供的帮助程度还不够充分

6 AI Coding Agent产品的发展走向及如何看Devin

Devin这类Agent产品的发展会是怎样的？

• Devin实际使用，非常有挑战

• 需要产品有非常强的reasoning 的能力。基于客户的具体业务场景和代码逻辑具体reasoning 能力，另外还需要对整个编程的 knowledge 广泛的理解，然后再把这两者做结合。在大模型的 reasoning 的能力到底能进化到什么程度大家还是有比较多的质疑和担忧
• Devin的产品形态虽然展示了创新性，融合了终端（Terminal）、代码以及搜索功能，形成了一个综合的解决方案。在该产品的操作过程中，用户期望执行的任务并非由单一的大型模型一次性完成，而是通过一系列决策链逐步实现。这意味着，为了达到最终结果，产品需要进行多步骤的决策过程，每一步都对最终输出起着关键作用。这种设计提高了操作的灵活性和精确度，可能为用户提供了更为细致和个性化的体验。但当多个步骤串联在一起时，即便每一步的准确率都是90%，最终的准确率将会是90%的连乘，结果会远低于单个步骤的准确率。这种累积的误差可能导致最终结果的准确度大大降低。如果准确率降低到一定程度，对于许多工程师而言，这样的工具可能不再是提高效率的工具，反而成为一种负担。工程师可能会发现，与其依赖这样的工具，不如自己手动编写代码来得更为高效和可靠。因此，目前看来，实现端到端（end-to-end）智能代理（Agent）在实际应用中仍然面临重大挑战
• 而且成本较高，主要因为它们对模型的要求非常高。即使是目前最先进的模型，如GPT-4，也只能勉强实现一些功能。为了达到这些功能，通常需要使用最大的模型，这无疑增加了成本。此外，每次智能代理与外部进行交流时，都需要重新设置请求（Request）。因此，如果运行一个任务，所需的请求数量会非常庞大，这不仅增加了成本，也降低了效率。这就要求产品去寻找那些可以容忍较长等待时间的应用场景。

• 如果要使用智能代理，至少在当前阶段，还需要采取非常严格的安全措施。必须确保，即使智能代理不小心执行了不当操作，或者在训练过程中出现了问题，也不会对系统造成影响，不会导致生产环境的崩溃或数据丢失等严重后果

• 虽然就目前模型的能力而言，智能代理的实用性仍然面临挑战。但智能代理是一个有潜力的产品。尽管目前还不够完美，但随着时间的推移，模型将变得更加强大，成本也将降低。预估在未来两到三年内，智能代理会变得更加实用和普及

下一代模型，比如GPT5,会对现在的这些 AI coding 产品有什么样的影响？对于Devin有什么样影响？

• 无论GPT-5是否发布，可以毫无疑问地说，一年后我们将使用的模型将在性能上大大超越现有的模型。这一预期基于当前技术发展趋势，即利用更多的数据来训练相对小型的模型，而这些模型的训练数据量正在逐步增加。因此，不仅是GPT-5，其他模型的性能也在迅速提升。一年后，许多当前难以实现的功能将变得更加容易实现，例如更智能的代理程序、对代码运行结果更准确的理解，或者解决更复杂的问题。这些进步将为编程和软件开发带来显著的变化
• 在未来三四年内，类似于Devin这样的自动化工具可能会变得更加普及和成熟。模型层面的发展肯定会朝着更高、更强、更快的方向发展。例如，Mistral公司最近推出了自己的编程模型，尽管其许可可能不如其他模型开放，但这也引发了业界的广泛讨论。整体来看，模型的迭代速度非常快

• 对于Devin这样的工具，如果要实现实际落地，可能会在特定的垂直场景中更加有效。与GitHub Copilot这样的通用产品不同，后者适用于各种编程人员，无论他们编写的是Java、数据分析还是C代码，Devin可能在特定的应用场景下更有价值，例如数据分析或前端UI调整。在这些领域，工具可以更深入地集成现有的知识库和规则，提供更专业的服务
• 如果Devin能够在这些具体场景中可靠地成为开发者日常使用的工具，那将是一个重大的成就。这不仅将提升开发效率，还可能改变特定领域的工作流程和方法。因此，专注于特定场景的深入开发和集成，将是实现这一目标的关键
• TabbyML是一个自托管的AI编程助手，旨在帮助开发人员更高效地编写、调试和优化机器学习代码。它提供了一个易于使用的界面，让用户能够快速创建和训练模型，同时提供了丰富的功能和工具，以支持各种机器学习任务

• 关于RAG for AI coding: https://tabby.tabbyml.com/blog/2023/10/16/repository-context-for-code-completion/
• 关于Decoding：https://tabby.tabbyml.com/blog/2023/10/21/incremental-decoding/
• 关于Coding Evaluation现在的一些问题和难点：https://tabby.tabbyml.com/blog/2023/11/13/model-evaluation/
• 关于Tabby coding leaderboard: https://leaderboard.tabbyml.com/

大模型未来三年的十个假设

Data Infra：大模型决战前夜