임베딩은 과소평가되고 있음 (2024년)

• 임베딩은 최근 기술 글쓰기 분야에서 혁신적인 발전 가능성을 제공함
• 입력 텍스트의 크기와 상관없이 고정된 차원의 수치 배열을 반환하는 특징이 있음
• 이 수치 배열을 통해 임의의 텍스트 간의 수학적 비교가 가능해짐
• 임베딩은 다차원 공간에서 텍스트 의미에 따른 거리를 계산하며, 관계성 추천, 의미 분석 등 다양한 활용이 가능함
• 앞으로 기술 문서 사이트들이 임베딩 데이터를 공개함으로써 새로운 도구와 커뮤니티 활용 사례가 확대될 전망임

---

머신러닝 기반 임베딩 기술 개요

• 머신러닝 기술에서 텍스트 생성 모델과 달리 임베딩은 기술 글쓰기에 혁신적인 영향을 미칠 잠재력을 지님
• 최근 몇 년간 임베딩 사용이 훨씬 더 접근 가능함으로 변화됨
• 임베딩을 통해 기술 작가들은 다양한 텍스트 간의 의미적 비교 및 분석 수행이 가능해짐

임베딩에 대한 직관 쌓기

• 임베딩은 텍스트(단어, 문장, 여러 문서 등)를 입력하면 고정 크기의 수치 배열을 반환함
• 입력 텍스트의 길이와 무관하게 항상 동일한 크기의 배열 데이터가 생성됨
• 이로 인해 서로 다른 길이의 임의 텍스트 간에도 수학적 비교 가능성이 생김

임베딩 생성 방법

• 주요 서비스 제공자를 통해 코드 몇 줄만으로 임베딩을 생성할 수 있음
• 사용되는 모델에 따라 임베딩의 배열 크기가 다르며, Gemini의 경우 768개, Voyage AI의 경우 1024개의 수치가 반환됨
• 제공자나 모델에 따라 임베딩의 의미가 완전히 다르기 때문에 상호 호환성 결여됨

비용 및 환경 영향

• 임베딩 생성 자체는 비용이 크지 않음
• 생성 과정은 텍스트 생성 모델에 비해 연산 자원 소모가 낮음으로 추정되나, 환경 영향은 추후 더 많은 정보가 필요함

임베딩 모델 선택 기준

• 가장 적합한 모델은 대용량 입력 데이터 지원 가능성에 따라 달라짐
• Voyage AI의 voyage-3는 2024년 기준 가장 높은 입력 한도를 제공함
• 사용 목적 및 필요에 맞는 모델 선택이 중요함

다차원 공간 개념

• 임베딩 수치 배열의 각 값은 다차원 공간의 한 좌표에 해당하며, 이 공간의 의미적 위치로 텍스트 특징이 표현됨
• 예를 들어 ‘king’ - ‘man’ + ‘woman’ ≈ ‘queen’과 같은 연산이 의미적 관계 표현 가능성을 보여줌
• 임베딩 공간의 각 차원 특징은 대부분 불명확하며 추상적임
• 이 과정을 통해 기계의 의미 학습 및 텍스트 의미 추론이 가능해짐

임베딩 비교 및 저장

• 생성된 임베딩은 각 텍스트(예: 페이지 등)별로 데이터베이스 등에 저장함
• 두 임베딩 간 수학적 거리 계산(선형대수 이용)으로 의미적 유사성 판단이 가능함
• NumPy, scikit-learn 등 라이브러리 활용으로 복잡한 수식 구현 부담이 적음

임베딩의 응용 예시

• 기술 문서 사이트에서 관련 페이지 추천 기능에 임베딩이 효과적으로 활용됨
• 각 페이지별 임베딩 생성 후, 수치적 유사성이 높은 페이지끼리 의미적으로 연관된 문서 추천이 가능함
• 페이지 내용을 변경할 때마다 임베딩만 새로 고치면 되어 효율성이 뛰어남
• 실제 [Sphinx] 문서에 적용한 결과 긍정적인 성능 확인됨

커뮤니티 및 오픈 데이터 가능성

• 향후에는 문서 사이트가 REST API나 well-known URIs를 통해 임베딩 데이터를 제공할 수 있음
• 이를 통해 커뮤니티가 다양한 응용 도구와 서비스 개발이 가능함

맺음말

• 수백 차원 공간 개념을 일상 업무와 연결해볼 계기가 되어 흥미로움
• 임베딩 도입으로 문서 유지보수 및 기능 확장 등에서 획기적인 발전 가능성을 기대할 수 있음

[GN⁺]

Hacker News 의견들

• 이 글을 쓴 사람임. 읽어줘서 고마움
  이 글은 6개월 전에도 논의됐음: https://news.ycombinator.com/item?id=42013762
  분명히 하자면, 임베딩이 과소평가된다고 한 건 동료 기술 문서 작성자들이 문서 작성 도구함에 들어온 매우 유용한 새 도구에 충분히 주목하지 않는다는 뜻이었음. 머신러닝 실무자들은 임베딩을 전혀 과소평가하지 않는다는 것도 알고 있음
  기술 문서 작성에서 임베딩을 정확히 어떻게 적용하는지 세부사항이 부족한 것도 알고 있고, 관련 프로젝트와 글을 준비 중임. 길게 말하면, 임베딩은 기술 문서 작성의 다루기 어려운 3가지 과제에서 진전을 만들 수 있기 때문에 중요함: https://technicalwriting.dev/strategy/challenges.html

  • 글을 머신러닝 전문가보다 기술 문서 작성자에게 더 매력적으로 보이게 만들면 대상 독자에게 더 잘 닿을 수 있을 듯함
    예를 들어 “이전에는 불가능했던 규모로 텍스트 간 연결을 발견하는 능력”을 더 풀어쓰면 좋겠음. 응용 섹션이 있긴 하지만 놓치기 쉬우니, 기술 문서 작성자에게 주는 가치를 예시와 함께 앞쪽에 배치하는 게 좋아 보임
  • 첫 6~8문단을 읽고도 임베딩이 무엇인지 여전히 감이 안 옴
    3번째 문단에는 “임베딩을 어떻게 쓰고 어떻게 동작하는지 개요를 보자”라고 되어 있지만, 임베딩이 무엇인지는 설명하지 않음. 아마 글 훨씬 뒤쪽에 묻혀 있을 수도 있겠지만
  • “필요한 콘텐츠가 존재하더라도 사용자가 찾는다는 보장이 어렵다”는 부분과 관련해서, 공개적으로 둘러볼 수 있도록 임베딩 위에 얹은 UX 계층을 어떻게 볼지 궁금함
    정확히 검색은 아니고 /를 트리처럼 써서 클러스터를 이동하는 방식이라 “의미 기반 스크롤링”이라고 부르고 있음
    [1]은 단일 시작점이고 애니메이션 화살표를 누르면 “위키 구멍”처럼 들어감. [2]는 책, 영화, 음악, 애니메이션 등을 포함한 전체 컬렉션임
    [1] - https://www.sharecommonbase.com/synthesize/1009?id=1009
    [2] - https://www.sharecommonbase.com/
  • 작은 트집을 잡자면, 입문 글이라는 건 이해하지만 너무 입문적임
    다음 글을 읽고 싶어지도록 임베딩의 “킬러 앱”을 최소한 미리 보여줘야 함. 글 전체를 읽었지만 이전에 몰랐던 유용하거나 통찰 있는 내용을 배운 느낌이 별로 없었음. 너무 아낀 느낌이지만 공유해준 건 고마움
  • 기술 문서 작성에서 임베딩을 직접 적용하는 예로는 이것도 참고할 만함: https://www.tdcommons.org/dpubs_series/8057/

• 임베딩과 임베딩 검색의 또 다른 멋진 특성은 자원을 적게 써서 클라이언트 측에서도 수행할 수 있다는 점임
  ONNX 모델은 transformer.js로 로드하고 실행 가능함: https://github.com/huggingface/transformers.js/
  임베딩용 hnsw 같은 색인도 빌드해서 정적 호스팅할 수 있음
  작은 오픈소스 데모를 만들어 봤음: https://jasonjmcghee.github.io/portable-hnsw/ 프로토타입이자 hnsw를 대충 흉내 낸 것이지만, 실제 구현도 가능함
  요약하면 색인을 질의 가능한 parquet 파일로 표현하고 duckdb로 질의하는 방식임. 호스팅 방식에 따라 무료이거나 거의 무료임. GitHub Pages를 써서 무료였고, Cloudflare R2를 쓰면 저장한 크기만큼만 비용이 들어 매우 저렴하며 송신 비용도 없음

  • 클라이언트 측 JS 기반 임베딩은 몰랐는데 멋짐. 문서 사이트에 적용할 수 있는 게 많이 열리겠음
    Parquet와 Polars는 이 글을 읽고 이미 눈여겨보고 있었음: https://minimaxir.com/2025/02/embeddings-parquet/
  • 이것이 궁금했음. 앱에 임베딩 기반 검색을 넣고 싶었지만, 초기 렌더링 때마다 검색이 임베딩 API 제공자의 지연 시간에 막히는 게 싫었음
    흔한 검색어는 임베딩을 캐시할 수 있겠지만, 임베딩 없이 먼저 렌더링하고 비동기로 임베딩을 만든 뒤 도착하면 결과 목록을 다시 구체화하는 것도 UX 관점에서 깔끔하게 하기 어려워 보임
    로컬에서 렌더링하려면 모델 접근이 필요할 텐데, 그런 임베딩이 의미 검색에서 OpenAI나 Google 등의 임베딩과 비교해 얼마나 좋을지 궁금함. 무료이고 즉시 동작한다는 점은 마음에 듦
  • 무슨 일이 일어나는지 더 설명해줄 수 있나? 결과가 잘 이해되지 않음

• 입력 텍스트가 크든 작든 항상 같은 개수의 숫자가 나온다고 해서, 임의의 두 텍스트를 수학적으로 비교할 방법이 생겼다는 부분은 좀 더 명확해야 함
  해시 함수도 입력 크기와 상관없이 같은 크기의 출력을 반환하지만, 두 해시를 수학적으로 비교하는 의미와 두 임베딩을 수학적으로 비교하는 의미는 크게 다름
  임베딩은 학습에 의존한다는 점을 강조하는 게 좋겠음. 비교 품질은 임베딩을 만든 학습의 품질과 종류에 달려 있음. 임의의 텍스트를 의미 있게 비교하게 해주는 단일한 “보편 임베딩” 같은 것은 없음

  • 피드백 고마움. Gecko [1], NV-Embed [2], Gemini Embedding [3] 같은 모델이 어떻게 만들어지는지 연구 논문을 읽으며 요지를 이해하기 시작했고, 이 부분을 더 정확하게 고칠 방법을 찾겠음
    [1] https://arxiv.org/abs/2403.20327
    [2] https://arxiv.org/abs/2405.17428
    [3] https://arxiv.org/abs/2503.07891

• 임베딩이 큰 입력을 일종의 “내용 주소화된 요약”으로 바꾼다는 점에서 해시와 대략 비슷하다면, 물론 해시는 불투명하고 임베딩은 내재적 의미가 있다는 큰 차이는 빼고, 이를 역으로 푸는 연구가 있었는지 궁금함
  즉 임베딩에서 시작해 의미적으로 가까운 텍스트를 거꾸로 생성하는 방식임
  LLM 추론 파이프라인에서 다음 토큰 순위에 목표 임베딩과의 유사도를 포함하거나, 해당 토큰을 추가했을 때 원하는 임베딩 쪽으로 가까워지거나 멀어지는 방향 변화를 반영할 수도 있을 듯함
  다르게 말하면 글쓴이가 든 embedding("king") - embedding("man") + embedding("woman") ≈ embedding("queen") 예시를 전체 텍스트 단위로 할 수 있다면 어떨까 싶음
  전체 문단, 글, 책에 대해 의미 대수를 할 수 있는 상상을 하게 됨. LLM에 “톤을 더 친근하게 바꿔줘”라고 프롬프트하는 대신, “친근함”이라는 핵심 개념이나 더 미묘한 변형을 기존 텍스트에 “더하는” 식임

  • 임베딩에서 시작해 의미적으로 가까운 텍스트를 거꾸로 생성하는 것은 임베딩 역변환이라고 부르는 듯함: Universal Zero-shot Embedding Inversion https://arxiv.org/abs/2504.00147
    변형을 줄 수단을 두고 목표에 점점 가까워지는 방식이 가장 일반적으로 보이며, 더 최적화된 방법도 많음. CLIP 임베딩을 쓰는 이미지 확산 같은 것도 어느 정도 관련 있음
  • 이 분야 전문가는 아니지만 관련 연구가 있었던 듯함. 추론 시 개입이라고 부름
    [1] "Steering Language Models With Activation Engineering", 2023, https://arxiv.org/abs/2308.10248
    [2] "Multi-Attribute Steering of Language Models via Targeted Intervention", 2025, https://arxiv.org/pdf/2502.12446
  • 임베딩은 대략 퍼지 해시에 해당함
  • 의미 대수 아이디어에서 이어지는 질문인데, 임베딩에서 시작해 의미적으로 비슷한 텍스트를 생성할 수 있다면 “텍스트 길이”도 임베딩이 포착하는 속성 중 하나라는 뜻인가?

• “임베딩으로 기술 문서 작성의 최신 수준을 어떻게 끌어올릴 수 있을지 정확히 말해줄 수도 있지만, 그럼 무슨 재미가 있겠나?”라는 문장은 꽤 대담함
  이제 “좋은” 기술 문서에는 논제문이 더 이상 포함되지 않는 건가 싶었음
  진지하게 말하면, 이게 기술 문서 작성에 왜 유용한가? 비슷한 페이지 위젯 정도는 만들 수 있겠지만, 기술 문서를 읽을 때 그런 걸 원한 적도 거의 없고 작성할 때는 더더욱 없음

  • 논제는 두 번째 문단에 있음: “임베딩이 기술 문서 작성자에게 제공하는 것은 이전에는 불가능했던 규모로 텍스트 간 연결을 발견하는 능력이다”
    다만 이 글이 그 논제가 실제로 작동하는 구체적 예를 제공하지 않아 효과적이지 않다는 평가는 타당함. 변명하자면 이 글을 독립 글로 의도한 적은 없었는데, 좋은 의미로 삶이 끼어들었음: https://news.ycombinator.com/item?id=43964584
    기술 문서 작성에서 왜 유용한지에 대한 답은 마음에 들지 않을 것임. 역시 추상적이기 때문임. 기술 문서 작성에는 다루기 어려운 3가지 과제가 있고, 임베딩은 그 3가지 모두에서 진전을 도울 수 있음: https://technicalwriting.dev/strategy/challenges.html
    이것도 참고할 만함: https://www.tdcommons.org/dpubs_series/8057/
  • 관련 문서 추천을 빼더라도 기술 문서는 훌륭한 검색에서 큰 이익을 얻음
    임베딩은 더 나은 검색을 만드는 데 매우 유용한 도구임. 사용자가 기능 이름을 기억하지 못하고 “모든 데이터 열에 함수를 실행하게 해주는 그 기능”처럼 말하는 모호한 일치를 처리할 수 있음
    임베딩을 쓰면 키워드 검색과 벡터 유사도 검색을 섞는 하이브리드 접근을 구현할 수 있음. 키워드 검색은 여전히 필요함. 임베딩은 학습하지 않은 전문용어를 놓칠 수 있기 때문임
    좋은 예시를 보여줄 수 있으면 좋겠음

• 2차원 지도 비유는 직관을 쌓는 발판으로 좋았지만, 임베딩은 수백~수천 차원에서 동작하므로 이제 버려야 한다는 부분에 대한 트집임
  king - man + woman ≈ queen 일화는 모델에 성별 개념을 담은 차원이 있다는 뜻이 아니라, 성별 개념을 담은 방향이 있다는 뜻에 가까움
  방향과 차원은 정의상 떼기 어려워 보이지만, 약간 느슨한 수학으로 보면 n차원 공간 안에서 거의 직교하는 방향의 수는 n에 대해 지수적으로 늘어남. 그래서 1천 차원 규모의 공간이 수십억 개 개념을 “담을” 수 있는 이유가 설명됨

  • 단어 임베딩에 남성형 단어 1000개를 넣었더니 여성형 단어 950개가 맞았다는 식의 arXiv 논문은 보기 어려움. 통계적으로는 우연보다 낫지만, 단어 임베딩은 그렇게 잘하지 못함
    https://nlp.stanford.edu/projects/glove/에는 약 N=20개 점이 “올바른 위치”에 있는 듯한 그래프가 여럿 있지만, 관련 차원이 많고 50차원만 있어도 20개 점이 원하는 위치에 정확히 놓이게 하는 투영을 찾을 수 있음. N>100 단어로 실험하면 끝없이 제자리만 돌며 사람들이 출판하지 않는 애매한 부정 결과가 나옴
    BERT류와 다른 트랜스포머 임베딩은 단어의 문맥을 고려할 수 있어서 단어 벡터보다 훨씬 뛰어남. 예를 들어 “red”가 형용사인지 알려주는 품사 분류기를 단어만 보고는 제대로 만들 수 없음. “red”는 명사이기도 하기 때문임. 하지만 문맥을 주면 가능함
    전체 텍스트 검색에서 동의어를 끌어들이는 건 양날의 검임. 한 단어가 2~3가지 의미를 가질 수 있고, 관련 없는 동의어는 결국 관련 없는 문서를 가져옴. 현대 임베딩은 문맥을 인식해 동의어를 가져올 뿐 아니라 다른 의미로 쓰인 단어 사용을 억제할 수 있음. 이는 정보 검색 분야가 약 50년간 풀려고 해온 문제임
  • 맞는 말이고, 내게는 작은 트집이 아니라 중요한 개념적 수정처럼 느껴짐
    글을 쓸 때 모델에 성별에 대응하는 차원이 있다고 표현하는 부분에서 뭔가 이상하다고 느끼며 멈췄음. 말한 대로 이 모델들이 범용이고 여러 영역에서 잘 작동하는 만큼, 개념과 차원이 1:1 대응할 리는 없음
    예전에는 코사인 유사도가 어떻게 동작하는지 잘 이해하지 못했는데, 이런 영상을 보고 더 잘 이해하게 되면서 코멘트가 더 와닿음: https://youtu.be/e9U0QAFbfLI
    언젠가 글을 업데이트해 이 부정확성을 고치겠음. 내 두뇌의 임베딩 개념 모델을 개선해줘서 고마움
  • 트집 속의 트집인데, “n차원 공간 안의 거의 직교하는 차원”이 아니라 “n차원 공간 안의 거의 직교하는 방향”이라고 쓰려던 것 같음
    본문에서 방향과 차원을 구분하고 있으니 중요한 부분임
  • 궁금한 사람을 위한 Johnson-Lindenstrauss 보조정리: https://en.wikipedia.org/wiki/Johnson%E2%80%93Lindenstrauss_lemma
    JL 변환으로 거리를 ε 비율 안에서 보존하려면 k>8(\ln N)/\varepsilon ^{2}로 매핑해야 함. 이것도 상수배까지는 타이트함
    늘 궁금했던 건, 10억 개 점 사이 거리를 10% 안에서 보존하려면 약 18k 차원이 필요하고 1%면 1.8m 차원이 필요하다는 뜻임. 점들이 잘 퍼져 있을 때 더 강한 버전의 보조정리가 있나? 아니면 임베딩은 거리 정밀도가 낮아도 그냥 괜찮은 건가?
  • 전혀 작은 트집이 아님. 차원 하나가 실제로 성별에 대응한다면 “king”과 “queen”은 거의 그 한 차원에서만 달라야 함
    더 일반적으로 각 차원이 인간에게 의미 있는 개념을 가리킨다면, 한 차원에서만 거의 다른 단어들을 살펴보는 것만으로 그 개념이 무엇인지 알아낼 수 있어야 함

• 글에서 기술 문서 작성자에게 직접 적용되는 내용이 있었는지 놓친 건가 싶음
  임베딩은 LLM이나 의미 검색 같은 것에 흥미롭고 매우 중요하지만, 글쓴이는 더 직접적인 효용을 암시하는 듯함

  • 기술 문서 작성자에게 직접 적용되는 내용은 없었음
    원래는 임베딩을 기술 문서 작성에 적용하는 여러 방식을 탐구하는 글과 프로젝트로 이어지는 예고 글이어야 했음. 하지만 삶이 끼어들었고, 이제 3개월 된 아기를 둔 자랑스러운 새 아빠가 됨
    관련 프로젝트와 임베딩 글은 준비 중임. 요약하면 임베딩은 여기서 말한 기술 문서 작성의 “다루기 어려운” 3가지 과제 모두에서 진전을 도울 수 있음: https://technicalwriting.dev/strategy/challenges.html
  • 의미 검색, 분류, 군집화가 있음. 검색에서는 10년쯤마다 정보 검색의 큰 돌파구가 나오니 얻을 수 있는 건 챙겨야 함
    TREC 자료를 읽으며 “검색 관련성을 높이는 뻔한 아이디어는 전부 안 통한다”는 결론만 보는 것 같아 우울했는데, 첫 10년 요약을 보고서야 그 10년 동안 유용한 결과가 하나, BM2.5였다는 걸 알았음
    분류에서는 텍스트를 임베딩으로 바꾼 뒤 그 임베딩을 https://scikit-learn.org/stable/supervised_learning.html의 전통적 머신러닝 알고리즘에 넣는 게 매우 실용적임
    이게 워낙 꾸준히 잘 통해서, 작업 중인 텍스트 분류 라이브러리에 단어 가방 분류기를 넣지 않을까 고민 중임. Huggingface 포럼에서 권위자처럼 말하는 사람들은 미세조정한 BERT가 더 낫다고 보는 경향이 있고, 더 나을 수 있다는 데는 동의하지만 학습 시간이 100배이고 실제로는 아닐 수도 있음
    20년 전에도 단어 가방 벡터를 만들어 https://scikit-learn.org/stable/modules/clustering.html의 군집화 알고리즘에 넣을 수 있었고 동작은 했지만 결과는 형편없었음. 임베딩을 쓰면 https://scikit-learn.org/stable/modules/clustering.html#k-means 같은 매우 단순하고 빠른 알고리즘으로도 훌륭한 군집을 얻을 수 있음
    가까운 벡터를 찾는 데 “많은 선형대수”가 필요하다는 부분에는 동의하지 않음. 내적으로 가능하니 “약간의 선형대수”라고 하겠음
  • 임베딩으로 문헌을 의미 검색할 수 있으면 좋겠음. 아는 사람 중 적어도 한 명은 arXiv 논문 전체의 벡터 데이터베이스를 만들려고 하고 있음
    큰 문제는 출처 표시와 인용임. 임베딩은 그냥 벡터라서 원본 자료, 수정일, 진본 인증서로 돌아가는 인용 정보를 담지 않음. 그래서 RAG에서 임베딩을 쓸 때는 특정 원본 페이지로 되돌아가는 링크 역할만 함
    임베딩을 링크로 쓰는 것은 기술 문서에서 인용과 출처 표시를 다루는 방식을 크게 바꾸지 않음. 여전히 논문 전체나 논문의 한 페이지를 인용하게 됨
    기술 문헌에서는 GraphRAG [1]를 기반으로 만드는 편이 더 유용하다고 봄. 그래프를 써서 학술 논문의 특정 페이지에 있는 특정 개념을 인용하고, 그 “인용”이 새 과학 담론과 오래된 과학 담론 사이의 양방향 링크처럼 작동하게 하는 방법들이 있음
    [1] https://microsoft.github.io/graphrag/
  • 임베딩을 이용한 의미 검색 RSS 집계기를 만들었음. 주요 용도는 임의로 만든 카테고리로 분류하는 것이었고, 그래서 임의 카테고리를 만들 수 있었음
    https://github.com/aws-samples/rss-aggregator-using-cohere-embeddings-bedrock
    안타깝게도 이제 AWS에서 일하지 않아서 실행 중이던 인프라는 내려간 상태임

• 며칠 전에 임베딩 설명 글을 썼으니 관심 있으면 볼 만함: https://sgnt.ai/p/embeddings-explainer/
  수학은 아주 적고 개가 많이 나옴

• 임베딩은 알파벳이나 숫자처럼 보편성으로의 새로운 도약임: https://thebeginningofinfinity.xyz/Jump%20to%20Universality

• 완전히 동의함. 온라인에서 읽은 잘 기억나지 않는 것들을 빠르게 다시 찾으려고 Recallify를 만들며 임베딩을 실험해왔음
  1024차원만으로도 정확한 키워드 기억이 아니라 순전히 의미적 유사도에 기반해 아이디어를 포착하고 떠올려주는 능력이 인상적임. 키워드를 정확히 기억하는 데는 내가 꽤 서툼
  흐릿한 머릿속 개념을 실행 가능한 통찰로 바꾸는 데 큰 변화가 되었음
  관심 있는 사람이 있으면 iOS 앱 베타 테스트 중임: https://recallify.app/