概述
缺点：成果转化系统没法落地。都是自己想象的空中楼阁，但是也许我可以开源到网上部署到服务器上，竞品https://www.1633.com/。登科总录和智能客服都是以落地为目标在不断迭代的，可以着重点名，不过两个都偏工程，可以提现技术栈。其中登科总录是Dify,智能客服是AI全流程。Ascend Lavis和无障碍量体都是科研项目，一个表现异构和优化，一个表现机器训练学习的科研能力。接下来再做一个偏硬件的优化性能提升。区块链放最后。主要是知识丰富。
embedding
Embedding 过程：123456789101112131415161718192021222324252627282930313233343536373839404142文本输入 │ ▼┌────────────────────────────────────────┐│ 1. Tokenization (分词) ││ "苹果手机屏幕碎了怎么办？" ││ → ["苹果", "手机", "屏幕", "碎", ...]│└────────────────┬───────────────────────┘ │ ▼┌────────────────────────────────────────┐│ 2. Token Embedding ││ 每个token转换为初始向量 ││ ...
Agentic RAG
超越扁平化文本分块，构建反映知识内在层次和关联的结构化索引 RAPTOP 树状关联图叶子细节，根总结 GraphRAG网络关联图实体，关系通过社区发现算法找出语义上关联的集群，生成摘要。 智能体RAG传统RAG是单向数据流，非智能智能体RAG把知识库检索封装为工具，Agent像ReAct一样，进行”思考，行动，观察“的循环。知道观察到判断已经收集充分的信息，才会综合所有检索的上下文，生成答案。
数据处理
面对企业里最常见的“表格数据”（Excel、数据库表），大模型（LLM）其实很难直接“理解”或“检索”它们。为了让大模型能用上这些数据，工程师们总结出了这两条完全不同的技术路线：一是将部分关键字段按照特定的文本模板拼成一个text段落，去构建文本知识库：这样可以模糊语义搜索，但是丢失精确性：你没法问“GPA 大于 3.5 的人有多少个？”这种数学问题 二是利用Text2SQL的技术，直接去查询结构化数据库表进行生成。不移动数据，而是教大模型写 SQL 语句，让它直接去指挥数据库干活。为了“精确统计”和“逻辑运算”。但是对于复杂表大模型写的SQL可能就会报错或者查不出数据。 检索时：用小切片（Chunk），因为它语义聚焦，更容易匹配到准确的锚点。 生成时：用扩展后的长文本（Context），因为它包含前因后果，LLM 读起来更连贯，幻觉更少。 在建立支持双层检索（Milvus +...
向量搜索前沿调研
Milvus 提供支持Milvus 是一个开源的向量检索中间件，支持常见的向量检索场景，具备以下特点： 支持基于 Python / Java / Go / C++ 的 SDK 和 RESTful API 支持 Annoy、Faiss、HNSW 等多种算法库 支持 CPU 和 GPU 运算 以 collection 为基本的管理单元，在 collection 中再划分 partition 为基准，支持粗粒度与细粒度的数据管理 支持原始向量存储与查询近似最近邻（ANN）向量搜索：有用过谷歌的 Vertex AI 向量搜索， 也试过用Apache Solr 的 ANN 向量搜索处理一些大数据集，还有在垂直扩展的边缘节点里部署 Facebook 的 FAISS 库，专门应对小数据集。 性能：月活11亿的Reddit ，怎么选向量数据库：Pgvector、Redis、Milvus、QdrantReddit的案例主要讲了选向量数据库从需求到评估到测试到选用的全过程： 需求：功能需求？向量和关键词搜索，标签检索，按非向量属性过滤非功能需求？存 10...
检索
本质上都是最近邻检索 Aproxingmate Nearest Neighbor. ES检索（关键字检索）通过paddle的实体抽取模型，从Query中抽取实体信息的关键字段，在ES检索的时候进行不同的加权，ES返回匹配的source文档集合，source可以认为是doc向量索引的parent_id。 向量检索向量查询本质上是将Query向量和collection中的所有向量进行相似度匹配，所以需要确定一个相似度指标，比如欧氏距离、Cosine相似度等。当向量都在单位球面上（即长度为1）时，直线距离（欧氏距离）越短，夹角（余弦相似度）就越小，两者是严格单调转换关系。两个方法严格成反比。 L2 归一化 (L2 Normalization)： 它的作用就是把所有长长短短的向量，全部“缩放”到这个单位球的表面上。无论原来的向量多长，归一化后，它们的模长（Length/Norm）都变成了 1。把向量投影到单位球面上（L2 归一化），实际上是会损失信息的。我们丢失了向量的“模长，但在现代深度学习（特别是 NLP 和 Embedding...
知识库构建
先进行数据收集和处理再向量化Embedding后建立索引，这样就构建好知识库了 Embedding的 dense索引给文本数据构建索引，首先要基于清洗好的数据切分成不同的chunk块，每个chunk块称作是一个doc，这是构建向量的最小单位，然后使用Embedding模型在doc上编码出向量，存储到Milvus中并建好向量索引，此时一个知识库就构建好了。 基于ES在每个知识库上构建倒排索引
ReAct工作流
12345678910111213while True: # 每个Agent都有一个自己的死循环 # 1. 阅读收件箱（如果有消息就用 user 身份插进 context 中作为打断提示） # 2. 调用大模型 API 思考 response = client.messages.create(...) # 3. 决定是否调用了工具 if response.stop_reason != "tool_use": break # （或者 return） # 4. 执行自己手里的工具箱并收集结果 for block in response.content: output = handler(...) results.append({"type":"tool_result", ... output}) # 5. 把结果还给 Context，进入下一轮 ...
skill
“用到什么知识, 临时加载什么知识” – 通过 tool_result 注入, 不塞 system prompt。第一层: 系统提示中放技能名称 (低成本)。第二层: tool_result 中按需放完整内容。 123456789SYSTEM = f"""You are a coding agent at {WORKDIR}.Skills available:{SKILL_LOADER.get_descriptions()}"""TOOL_HANDLERS = { # ...base tools... "load_skill": lambda **kw: SKILL_LOADER.get_content(kw["name"]),}TOOLS = [ {"name": "load_skill", "description":...
索引
索引方法如果没有索引，每次你在数据库中搜索“类似图片”或“相关文档”时，计算机必须进行暴力搜索（Flat Search / Brute Force），即把你的查询向量和库里的 1 亿个向量逐一对比计算距离。这在数据量大时是不可接受的 索引的作用，就是通过牺牲一点点精度（从 100% 降到 99%），换取几百倍甚至几千倍的搜索速度提升。 这被称为 ANN（Approximate Nearest Neighbor，近似最近邻搜索）。 Elasticsearch (文本的王者): 倒排索引 (Inverted Index) 原理： 就像书籍末尾的“索引页”。 存储方式： 它不存“文章 1 -> 关键词”，而是存“关键词 -> 出现在哪些文章里”。 例子： 单词 “Python” -> [Doc_1, Doc_5, Doc_9]。 优势： 它是为了精确匹配 (Exact Match) 设计的。查找包含特定单词的文档，速度是 O(1)...